DKIM Body Canonicalization Mismatch in Quoted-Printable to Base64 MIME Conversion

Why does DKIM fail when converting email MIME encodings?

You sent an email that looked perfect — text aligned, formatting intact. But DKIM verification failed. No error message, no clear reason. You’re not alone. This happens when MIME encoding changes during transit: between quoted-printable and base64, subtle shifts in line breaks or whitespace alter the email body’s canonical form.

DKIM signs a canonicalized version of the email body. Canonicalization is strict: it normalizes line endings, trims trailing whitespace, and treats certain characters consistently. If the body changes between signing and verification — even slightly — the signature fails. That’s why changing MIME encoding can break DKIM, even if the content looks identical.

Understanding how quoted-printable and base64 affect canonicalization explains why seemingly minor processing steps disrupt email authentication.

Key takeaways

• DKIM signatures are sensitive to any change in the canonicalized body, including those caused by MIME encoding conversion.
• Quoted-printable and base64 MIME encodings alter line breaks and whitespace, leading to different canonicalized body representations.
• Even small differences in line length or character interpretation during encoding conversion result in DKIM failures due to canonicalization mismatches.

What is body canonicalization in DKIM?

DKIM canonicalization ensures the email body is standardized before signing, so the signature remains valid regardless of minor formatting changes. It normalizes line breaks to CRLF, strips leading and trailing whitespace, and removes empty lines—all to create a consistent signing basis. If the receiving server applies different rules, the signature fails, even if the message content is unchanged.

The role of canonicalization in email integrity

When an email is signed with DKIM, the body is processed through a canonicalization algorithm. This step is crucial because even a single extra space or line break can cause the signature to fail validation. The standard process, defined in RFC 6376, applies two models: simple and relaxed. Relaxed canonicalization is common and allows some formatting flexibility while still maintaining consistency.

For example, two consecutive spaces become one, and line breaks are always converted to CRLF. The signing server applies this rule to the body before generating the signature. The receiving server must do the exact same thing to verify it. If either server deviates—say, one treats soft line breaks differently—the check fails.

Why quoted-printable and base64 conversions cause mismatches

When an email body uses quoted-printable encoding and is later converted to base64, the canonicalization process can introduce subtle differences. Quoted-printable preserves line breaks and whitespace more directly. Base64, in contrast, encodes everything as a continuous string, which can alter how line endings and trailing spaces are treated during transmission.

Most problems arise when the signing server canonicalizes using relaxed rules, but the receiving server doesn’t. You can prevent this by ensuring consistent handling across your email infrastructure. Using a tool like MailTester’s bulk verification helps you catch issues early—by testing how messages behave with different encodings and validating recipient infrastructure compatibility before sending.

For more details on how DKIM works, see the IETF’s official specification at RFC 6376. The canonicalization process is one of the most frequently overlooked sources of email deliverability issues, especially when sending through third-party services or using complex content workflows.

How do MIME encodings affect body canonicalization?

DKIM verifies email integrity by comparing the signed body of a message to the one received. When MIME content is encoded using quoted-printable or base64, the way line breaks and whitespace are represented changes. Converting between these encodings alters the body’s structure—especially line endings and padding—breaking the canonicalized version that DKIM expects, which leads to signature verification failure.

What happens during quoted-printable encoding?

Quoted-printable encoding represents non-ASCII characters using an equal sign (=) followed by two hexadecimal digits. It preserves readable text but allows soft line breaks at specific points. These line breaks are optional and not preserved during transmission, meaning even a minor rearrangement of lines or rewrapping of content can invalidate DKIM.

How base64 encoding changes the body representation

Base64 encodes binary data into 64-character chunks, splitting every 76 characters regardless of content. This creates consistent block boundaries but introduces strict, predictable line breaks. Unlike quoted-printable, which can vary in how line breaks are inserted, base64’s structure is rigid. When you convert from quoted-printable to base64—or back—the original line pattern is lost, and the canonicalized body no longer matches.

Let’s be clear: DKIM signs a specific sequence of characters, including line feeds and whitespace. Any change to that sequence—due to encoding conversion, rewrapping, or normalization—breaks the signature. This is why email systems that process MIME content (e.g., mailing software, gateways, or ESPs) must preserve the exact encoding during signing and verification.

According to RFC 6376, the canonicalization process defines how whitespace and line breaks are handled during signing. The body canonicalization method used in DKIM strips non-essential whitespace but relies on consistent line endings. When you switch between quoted-printable and base64, you introduce inconsistency, which leads to a mismatch even if the message content is identical.

Even minor changes—like a single line break inserted during a client-side email client’s reflow—can trigger a failure. This is especially common in forward or reply threads, where content may be reformatted differently in the MIME body, even when the underlying text is unchanged.

You can test this in practice by examining the raw headers and body of an email after it has been processed through multiple systems. Tools like inbound placement testers can help you see whether DKIM failures occur due to encoding inconsistencies, especially in bulk-sent campaigns where message content is transformed multiple times.

When does a DKIM mismatch occur during MIME conversion?

You get a DKIM mismatch when a message is signed using quoted-printable encoding but later converted to base64 by a relay server, or when line breaks are normalized inconsistently between signing and verification. Even if the final message looks identical to a human, the underlying byte sequence changes—especially in how line endings are handled—leading to a failed signature check. This mismatch often occurs in transit, especially through gateways that re-encode MIME bodies without preserving the original canonical form.

How encoding changes break DKIM validation

DKIM signs the message body using a specific canonicalization process. If the signing server uses strict line-break normalization (e.g., converting CRLF to LF only), but the receiving server applies different rules—allowing both CRLF and LF as line breaks—the computed hash will not match. The same logic applies to MIME encoding: a body signed as quoted-printable must stay that way until verified, or the byte stream changes, breaking the signature.

Let’s say a message is signed in quoted-printable with line breaks normalized to LF. A relay server later converts it to base64. Even though the content is logically the same, the MIME structure alters the canonical form. The verifier computes the hash on base64 data but compares it to a signature made on quoted-printable. The mismatch happens not because of content, but because of encoding transformation without consistent canonicalization.

Why normalization rules matter

The canonicalization of line breaks and whitespace is defined in RFC 6376, which specifies how to prepare a message for signing. But not all servers follow the same interpretation. Some apply "relaxed" rules, others "simple." When a signing server uses "simple" (strict) normalization and a receiving server defaults to "relaxed" with permissive line-end handling, signatures fail—even if the message content is unchanged.

Even if you validate the same message locally using tools like MXToolbox or RFC 6376, you might miss these issues if you don’t simulate real transit behavior. The root issue isn’t a broken email system—it’s the lack of consistency in how servers process quoted-printable vs. base64 and how they apply canonicalization rules across the email chain.

When validating your sending infrastructure, especially during setup or debugging, check that all stages—especially relays, gateways, and content filters—preserve the canonical form used during signature generation. Tools like inbox placement testing can help you evaluate deliverability across real inboxes, including how signatures behave under actual routing conditions.

How to prevent DKIM body canonicalization mismatches during MIME conversion

You prevent DKIM body canonicalization mismatches by ensuring consistent MIME handling from signing to delivery. Always sign and send using the same encoding (prefer base64), avoid converting between quoted-printable and base64 in transit, and validate the final delivered body against the signed version using a tool that checks both. This applies regardless of whether you're using an in-house system or third-party email service.

Apply consistent canonicalization rules across systems

• Use the same canonicalization method—either relaxed or simple—at every stage: signing, delivery, and verification. Changes between systems can break DKIM validation.
• Ensure all email platforms in your stack (SaaS, ESP, custom SMTP) follow the same rules defined in RFC 6376, Section 3.4. Even small deviations matter.
• Test the full chain: if you use a third-party sender like SendGrid or Mailchimp, confirm they apply the same canonicalization rules you expect.

Minimize MIME encoding conversions

• Never convert between quoted-printable and base64 unless absolutely required. Each conversion alters the body content and risks changing the canonicalized form.
• Prefer base64 for signing and delivery. It’s more predictable, widely supported, and less prone to line-breaking issues during transport. RFC 2047 defines the standard; base64 is the recommended encoding for signed headers and bodies.
• If you must convert, do it only once—late in the pipeline—and ensure the signing happens before any conversion takes place.

Even with correct signing, a mismatch happens if the body delivered to the recipient doesn’t match the one signed. Let’s be clear: DKIM only verifies what was signed, not what the user sees. If the body changed during delivery—due to encoding shifts—you’ll have a validation failure, even if the message is otherwise valid.

Use a testing tool that checks both the signed and delivered content. With MailTester’s inbox placement tester, you can validate how your email renders end-to-end, including the impact of MIME encoding, before sending to real users.

Even if your email passes SPF and DKIM, a canonicalization mismatch will result in a failed signature—regardless of content quality or sender reputation.

Consistency in MIME handling isn’t optional. It’s a core requirement for reliable authentication. The best way to catch these issues early is to simulate delivery with tools that replicate real-world processing—especially when your email stack includes multiple systems with differing defaults.

How to test DKIM integrity after MIME encoding changes

When converting between quoted-printable and base64 MIME encoding, DKIM signatures can fail due to body canonicalization mismatches. You must validate that the signed body (as sent) is identical to the delivered body (as received), after both are processed with the same canonicalization rules. Use a test tool that lets you control encoding, inspect the raw signed body, and simulate real-world delivery paths to catch hidden issues.

Test the signed body against the delivered body

1. Send the email through a tool that gives you full control over MIME format—like a test harness or a verified email delivery platform. You need to specify whether the body uses quoted-printable or base64 encoding before signing. This step ensures you know exactly what was signed.
2. Extract the body that was used for the DKIM signature from your sending server (or via logging). This is the original, signed body—before delivery.
3. Retrieve the same email as delivered to a test receiver (using a tool like MxToolbox or a private SMTP hook). This is the received body—after all transport and decoding layers.
4. Apply the same canonicalization rules to both bodies: remove line breaks, normalize whitespace, and handle encoding as required by the DKIM specification. This is critical—DKIM relies on consistent body processing. For details, see RFC 6376, which defines both relaxed and simple canonicalization.
5. Compare the canonicalized versions. If they differ, the DKIM signature will fail, even if the content looks identical to a human. A mismatch indicates encoding or canonicalization drift.

Simulate real delivery to catch hidden problems

Encoding issues often surface only under non-ideal paths—like when intermediate gateways re-encode messages. Use a tool that can mimic multiple delivery scenarios (e.g., different ESPs, gateways, or header alterations).

• Run tests through email delivery simulators that preserve raw headers and MIME structure.
• Confirm that the canonicalized body remains consistent across each step, regardless of how the message is processed en route.
• Look for deviations introduced by automatic re-encoding, such as a quoted-printable header being stripped and replaced with base64 mid-flight.

Tools like Spamhaus and RFC 6376 list best practices for DKIM compliance and body canonicalization. If you’re verifying email infrastructure at scale, consider running inbox placement tests with real provider filters using MailTester’s inbox tester.

Does your email service provider support consistent MIME handling?

Not all email service providers handle MIME conversions consistently—some alter line breaks or whitespace during relay, even when content remains unchanged. This can trigger a DKIM body canonicalization mismatch, especially when converting between quoted-printable and base64 encoding. Always verify that the final delivered email body matches the original signed body to ensure DKIM integrity remains intact.

MIME conversion pitfalls in email delivery

When an email is sent, the body may be encoded using different MIME schemes—quoted-printable for readability, base64 for binary data. The problem arises because some ESPs apply inconsistent canonicalization rules during this conversion. Even simple changes, like normalizing line endings (CRLF vs LF), can break DKIM verification, despite the content being functionally identical.

For example, a system might convert line breaks during relay, or strip trailing whitespace, which doesn't affect display but alters the canonicalized body. This mismatch often appears as a DKIM failure in mail logs, even though the message was delivered intact. The root issue isn't malicious—it’s architectural, and it’s common across legacy or poorly configured mail systems.

According to RFC 6376 (the DKIM specification), canonicalization must be applied consistently across signing and verification. But not all providers implement this correctly. Some use relaxed rules during delivery, while others apply strict, exact rules.

RFC 6376 outlines the canonicalization process for DKIM, emphasizing that both sides must interpret the same rules. However, the reality is that implementation varies—especially across third-party email services and bulk senders.

How to validate MIME consistency

Let’s be practical: if you’re using an ESP, don’t assume they preserve MIME integrity. Always inspect a sample of your sent messages to confirm the body matches the one used in signing. Compare the raw message headers and body after delivery with the original—especially after conversion between quoted-printable and base64.

One way to test this is through inbox placement testing. Send a message to a known test mailbox, extract the full raw message, and validate the DKIM signature manually. If you find a body canonicalization mismatch, it’s proof your ESP is altering the message during relay.

When your DKIM signing works in theory but fails in practice, it’s often not your domain setup—it’s how the message is handled in transit. Use tools like inbox placement testing to simulate delivery and catch these issues early.

Can DKIM fail even if the message content is correct?

Yes — DKIM can fail even when the message content is perfectly accurate. The signature validation depends on the canonicalized body matching the original. If the email client or server alters line breaks or encoding during delivery — like when converting between quoted-printable and base64 — the body’s canonical form changes, causing a mismatch even if the human-readable content is identical.

DKIM isn’t about content — it’s about exact byte-for-byte consistency

DKIM signs the canonicalized version of the message body, not the raw text. The canonicalization process normalizes line endings and folding, but if the encoding transformation isn’t handled identically at signing and verification, the result differs. This is a common point of failure when systems use different MIME processors.

For example: a message sent in quoted-printable with soft line breaks might be re-encoded to base64 by an intermediate relay. If the re-encoding changes how whitespace or line breaks are preserved, the canonical body differs — even if the message displays the same way to users.

This failure isn’t a content issue. It’s a technical mismatch in how encoding and line handling are processed. The signature is valid for the original canonical form, but that form no longer matches after transformation.

Why this matters for deliverability

Even with correct DNS records, valid SPF, and clean sender reputation, DKIM validation can still fail due to subtle MIME processing differences across servers. This often leads to false positives — messages that aren’t spam, but get flagged or rejected.

According to RFC 6376, the canonicalization algorithm must be applied consistently at signing and verification to preserve integrity. Any deviation breaks the chain of trust. Major providers like Gmail and Outlook enforce this rigorously. You can find the full specification in the official DKIM specification (RFC 6376). Tools that test full message parsing — including MIME and encoding behavior — can help catch these edge cases early.

When verifying email lists or testing inbox placement, it’s useful to simulate real-world delivery conditions. MailTester’s inbox placement tests include checks for authentication failures, including DKIM signature mismatches, which helps you spot issues before sending to real users.

How MailTester helps test and prevent DKIM issues

DKIM body canonicalization mismatches can break email authentication when MIME encoding changes during transit—especially when switching between quoted-printable and base64. MailTester detects these mismatches by simulating real-world delivery paths and comparing the expected canonical body with what arrives. It verifies that your DKIM signatures remain valid after encoding conversions, relay, and inbox placement, helping you catch issues before they impact deliverability.

How MailTester tests DKIM integrity across delivery scenarios

• Run inbox-placement tests to simulate different SMTP paths, including variations in MIME encoding and header normalization.
• Check whether DKIM signatures remain intact after email conversion between quoted-printable and base64 MIME formats during relay.
• Compare the canonicalized body expected by the DKIM verifier against the actual body delivered—pinpointing mismatches caused by improper encoding handling.
• Validate email templates across multiple delivery chains, including third-party ESPs, to ensure consistent DKIM results regardless of outbound processing.
• Expose issues in your sender infrastructure, such as incorrect canonicalization settings in your email client, rendering engine, or ESP configuration.

Prevent DKIM failures before sending

Let’s be clear: DKIM breaks silently. A mismatch in body canonicalization often results in a failed signature with no clear error—only a bounce or inbox placement failure. MailTester helps you catch this before it happens.

Most email infrastructure assumes quoted-printable and base64 are interchangeable in body canonicalization, but they aren’t—especially when line breaks, whitespace, or MIME boundary handling is inconsistent. The RFC 6376 specification defines the rules for canonicalization, but implementation varies across platforms. Testing your message in real delivery paths is the only way to catch discrepancies. MailTester does that for you.

Whether you’re deploying a new template, changing an ESP, or onboarding a new integrator, use MailTester’s inbox-placement test to audit for DKIM integrity under real conditions. It’s built for teams that can’t afford to lose messages to authentication failures.

Test your senders, validate your infrastructure, and ensure consistent delivery—even when MIME encoding changes happen mid-flight. Start with a free test at MailTester’s inbox placement tester.

What happens when DKIM fails due to MIME conversion?

When a DKIM signature is broken by improper handling of MIME encoding—like converting between quoted-printable and base64 during transit—the receiving server detects a signature mismatch and may reject the message or flag it as suspicious. This breaks authentication, harms delivery, and can erode sender reputation over time, especially if the issue affects multiple messages.

How DKIM failure impacts deliverability

DKIM isn’t just a technical detail—it’s a trust signal. When a server sees a failed signature, it treats the message as unverified, increasing the odds it’ll be filtered as spam or delayed. The more frequently this happens, the more likely your domain will be flagged by filtering services.

Reputation systems track consistency. A pattern of failed DKIM checks, even if transient, can trigger rate limits or domain-level blocks—even if your content is legitimate. This is especially true for ISPs with strict alignment policies, like Gmail or Outlook.

Why MIME conversion causes this issue

DKIM signs the canonicalized form of the message body. If the body is converted from quoted-printable to base64 (or vice versa) without proper re-canonicalization, the content changes. This mismatch means the receiver’s DKIM verification process recalculates the signed data and finds a different hash than the one in the signature.

For example, a space or line break encoded as =20 in quoted-printable becomes a literal space in base64. Because these variations alter the digest, the signature fails even if the message content is logically identical. The issue isn’t the encoding choice—it’s the lack of proper re-canonicalization after conversion.

Many email clients and mailing systems handle encoding changes automatically, but not all preserve alignment. This is common in automated campaigns using tools that modify MIME structures without preserving the canonical format. The RFC 6376 (the standard for DKIM) explicitly defines how to canonicalize content; failure to apply the same rules at both signing and verification stages leads to failure.

For deeper insight into how email systems handle signing and encoding, refer to RFC 6376, which outlines the canonicalization process. A mismatch here is not a minor glitch—it’s a core break in the trust chain.

If you’re managing sender reputation, it’s worth checking whether your email service provider applies proper MIME canonicalization during relay. Tools like MailTester’s bulk verification can help identify lists with misconfigured or suspiciously formatted emails before send, reducing the risk of consistent DKIM failures.

Summary: Ensuring consistent DKIM behavior across MIME encodings

DKIM signatures depend on exact body canonicalization. Any change in line breaks, whitespace, or encoding during transit invalidates the signature, even if content appears unchanged.

Why encoding matters

Converting between quoted-printable and base64 alters line endings and whitespace. These changes, though invisible to users, break DKIM’s strict body normalization process.

Even small differences in how email clients or servers handle MIME encoding can cause verification failures. This affects inbox placement and sender reputation over time.

How to prevent issues

• Use consistent MIME encoding throughout your email pipeline — avoid unnecessary conversions.
• Validate delivery chains from sending to receiving systems to catch mismatches early.
• Test real-world deliverability using tools like MailTester to identify canonicalization mismatches before sending at scale.

Sources

• DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• DNS TXT Record Resolution Latency Causing DKIM Signing Delays
• Email Verification Platforms with DKIM Body Canonicalization Analysis in 2026
• How Do Inbox Providers Like AOL and Gmail Interpret DMARC Policy Failures Differently?
• Why Using Same DKIM Key Across Domains Breaks Alignment

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is body canonicalization in DKIM?

DKIM uses a strict process to normalize an email’s body — trimming whitespace, standardizing line breaks to CRLF, and removing trailing spaces — before signing. Both signing and verification servers must apply the same rules for validation to pass.

Why does converting between quoted-printable and base64 break DKIM?

Each encoding format handles line breaks and character representation differently. Converting alters the body’s structure, leading to a different canonicalized form than what was signed.

Can a DKIM failure happen even if the email content is unchanged?

Yes — if the encoding or line break handling differs during transit, the canonicalized body changes even if the message text appears identical.

How can I test DKIM integrity after MIME changes?

Use a tool that allows you to send and inspect emails with controlled MIME formatting. Compare the signed body with the delivered body after canonicalization.

Does MailTester detect DKIM body canonicalization mismatches?

Yes — MailTester’s inbox-placement testing validates DKIM signature integrity by comparing signed and delivered body content after canonicalization, flagging mismatches.

Is base64 more reliable than quoted-printable for DKIM?

Base64 is more predictable in handling line lengths and reduces the risk of canonicalization changes during relay, making it a more stable choice for DKIM-protected emails.

Can intermediate email servers cause DKIM failures during encoding conversion?

Yes — relay servers that re-encode or reformat messages without preserving canonicalization rules can invalidate DKIM signatures.

What’s the impact of repeated MIME conversions on email deliverability?

Each conversion increases the risk of canonicalization mismatches, leading to DKIM failures that degrade sender reputation and reduce inbox placement.

How often should I test for DKIM integrity?

Test every time you modify email templates, change sending infrastructure, or introduce new email service providers to catch encoding issues before they affect deliverability.

How does MailTester improve deliverability with DKIM testing?

MailTester sends test emails through real inbox environments and validates DKIM signatures against the delivered body, detecting canonicalization mismatches before they impact your sender reputation.