Why does DKIM verification fail even when your email looks correct?

You send an email that looks perfect in the preview. The subject, body, and sender match what you expect. But Gmail marks it as "Not verified" and Outlook quietly drops it into spam. Why?

Because DKIM signatures don’t care about how it looks — they care about how it’s delivered. Every byte matters. If your email’s body encoding changes during transit, even slightly, the signature fails.

DKIM signs the exact content—headers and body—as they exist at the moment of sending. Line endings, whitespace, encoding rules like UTF-8 vs. quoted-printable, or hidden formatting differences can cause the signature to no longer match. Gmail and Outlook enforce this strictly. A mismatch means rejection.

Key takeaways

  • Digital signatures like DKIM are sensitive to byte-level changes in email body and headers.
  • Even invisible differences—like CRLF vs LF line endings or encoding shifts—can break DKIM verification.
  • Gmail and Outlook validate DKIM signatures using the exact content received, not the original draft.

What is body encoding, and how does it affect DKIM?

Body encoding refers to how an email’s raw text is formatted during transmission—specifically how line breaks (CRLF vs LF), whitespace, and character sets like UTF-8 are handled. DKIM signs the original content before any encoding is applied, but if the receiving server alters line endings or normalizes whitespace during delivery, the hash no longer matches, causing verification to fail. This is a common issue in Gmail and Outlook when content isn’t preserved exactly as signed.

How encoding changes break DKIM

When you send an email, DKIM calculates a digital signature based on the exact byte sequence of the message body, including line endings and spacing. But mail servers like Gmail and Outlook often normalize text during routing—converting CRLF (Carriage Return Line Feed) to LF (Line Feed), trimming trailing whitespace, or folding long lines. These changes mean the content received differs from the signed version.

For example, if your server signs a message with lines ending in \r\n, but Gmail receives it with only \n, the hash mismatch causes DKIM to fail—even if the message content is otherwise unchanged. Even minor differences in whitespace or line folding can invalidate a perfectly valid signature. This is why some emails pass spam filtering but still fail DKIM checks.

Why Gmail and Outlook are strict about encoding

Both Gmail and Outlook treat message integrity as a high priority. They apply content normalization to reduce inconsistencies across devices and prevent obfuscation attempts. While this improves compatibility, it also raises the bar for valid DKIM signing. If your email infrastructure does not preserve the original text format, your DKIM will fail, even if your signing key is correct.

This behavior aligns with RFC 6376 (the DKIM standard), which specifies that the signed content must be preserved intact. The receiving server must apply the same transformations as the sending server during signing—but that’s rarely the case in practice due to differing server configurations. As a result, even legitimate email can be rejected if encoding isn't handled carefully.

Let’s be clear: you can’t just send an email and assume DKIM will work. If your mail server rewrites content during delivery, your signature will fail unless you normalize the content consistently across all steps. Tools like MailTester can help test how real mail providers interpret your messages—by checking both DKIM validity and how content is processed. Use our inbox-placement test to validate how your messages appear in Gmail and Outlook, including DKIM alignment.

How do Gmail and Outlook handle DKIM differently when encoding changes occur?

Gmail and Outlook validate DKIM signatures using different pre-signing content norms. Gmail checks signatures against the exact message body as sent, rejecting any deviation. Outlook enforces strict CRLF line endings and only normalizes them after signature verification—so if the body is sent with LF-only line feeds and signed before delivery, the signature fails. This can break DKIM in Outlook even if the message is valid in Gmail.

Why Gmail insists on exact content matching

Gmail treats the body and headers as a single, unaltered digest. Any change—like whitespace modification, line ending adjustment, or encoding difference—invalidates the signature. You can’t fix line endings after signing and expect Gmail to accept it. It verifies the exact content as sent, making pre-signage consistency critical.

Outlook’s stricter line-ending behavior

Unlike most servers that normalize line feeds (LF) to CRLF during processing, Outlook performs this transformation only after DKIM verification. This means signatures must be calculated on the message with LF-only line endings if that’s how it’s delivered. If the message is signed on a system that already converts LF to CRLF, Outlook sees a mismatch and rejects the signature.

This behavior aligns with the requirements in RFC 2822, which defines CRLF as the standard line ending in email. But implementation varies—many mail servers normalize early, while Outlook waits. The result: DKIM can pass in one client and fail in another, even when the message body is unchanged.

Let’s say you sign a message before sending and use only LF line endings. Gmail will accept it if the rest of the body matches. Outlook will see the signature mismatch because of the LF-to-CRLF conversion it performs post-verification. The same message, different outcome—just due to how the server handles encoding after signing.

To prevent this, ensure your email stack preserves the exact body format used in signing. Tools like inbox placement testing can help simulate delivery conditions and catch these edge cases before a campaign launches.

What happens when your DKIM signature fails in Gmail or Outlook?

If your DKIM signature fails in Gmail or Outlook, the receiving server treats the email as potentially forged or tampered with. This can result in the message being marked as spam, rejected outright, or silently filtered into the junk folder. Persistent failures harm your sender reputation and degrade inbox placement over time. This isn't hypothetical: email providers like Google and Microsoft rely on DKIM validation as a core part of their anti-spoofing and spam detection systems, as outlined in RFC 6376 and detailed in reports from industry monitors like MxToolbox.

Real-world consequences of DKIM failure

  • The email might be rejected during SMTP handshake without a bounce message — you won’t know it failed.
  • Gmail and Outlook may apply stronger scrutiny to your later messages, increasing the risk of inbox placement drops.
  • If DKIM fails across multiple sends, your IP or domain may be flagged in blocklists maintained by Spamhaus or similar organizations.
  • Even if delivered, recipients may see warnings like “This message was not authenticated” in Gmail’s interface.
  • Repeated failures can reduce your sender reputation score — a metric that directly influences whether future emails reach inboxes.

Why encoding matters in the verification process

Body encoding — particularly how your email's body is folded or altered during transit — can break DKIM signatures. The DKIM algorithm expects a specific body representation: line breaks (CRLF) preserved, no reformatting, and minimal whitespace change. If your MTA or ESP rewrites the body (common in content sanitization or URL rewriting), the signature becomes invalid.

Let's be clear: Gmail and Outlook don't just reject messages with failed DKIM on a whim. This is by design. They validate each signature using the public key published in DNS. A mismatch means the server can’t confirm the email’s authenticity. This is not a minor glitch. It’s a core security mechanism.

Use inbox placement testing to verify how your messages land across Gmail, Outlook, and others — including whether DKIM checks pass under real-world delivery conditions.

How body encoding is affected by email service providers and transport tools

When you send email, service providers like Gmail and Outlook, or transport tools like SendGrid and Amazon SES, often normalize line endings (e.g. CRLF to LF) or trim trailing whitespace. If your DKIM signature is generated before these changes occur—say, on a custom SMTP server—the signed content diverges from the final delivered version. This mismatch invalidates the DKIM signature, even if the email is otherwise valid. The safest approach is to sign the body only after all normalization is complete, ideally in the final transport step before delivery.

Why preprocessing breaks DKIM

DKIM relies on hashing the exact body content delivered to the recipient. If your signing tool runs early—before your email is processed by a delivery service—even tiny changes like line endings or trailing spaces alter the hash. Gmail, for instance, enforces strict MIME compliance and performs normalization on incoming messages before storing or delivering them. If you sign on a raw, pre-normalized body, the final email will differ from the signed one, causing verification failure.

Sign at the end of the pipeline

Let’s say you’re using SendGrid or Amazon SES. They process the email after you send it—adjusting headers, rewriting line breaks, and applying content filtering. If you sign before that step, you’re signing an outdated version. The most reliable method is to generate the DKIM signature immediately before sending, after all normalization but before encryption. This ensures the hash matches exactly what Gmail and Outlook receive. According to RFC 6376, the signature must cover the final body that the receiving server evaluates, not a pre-processed version.

This is why many top-tier email platforms recommend signing during the final delivery handoff. If you’re building a custom system, ensure your signing happens after all transport-level modifications. A misconfigured signature pipeline is a common cause of rejected emails, even when authentication headers like SPF and DMARC are correct.

To avoid DKIM failures, test your email delivery in real conditions. You can check inbox placement and verify how your email is processed by tools like MailTester’s inbox placement tester, which simulates delivery through major providers and flags potential issues with body content, encoding, or signing timing.

The role of MIME structure in DKIM body canonicalization

DKIM signature verification in Gmail and Outlook depends heavily on MIME structure because both email clients apply different body canonicalization rules. Gmail uses relaxed canonicalization, which tolerates minor formatting differences like extra whitespace or line breaks. Outlook, however, applies simple canonicalization for some domains, requiring exact matching of formatting. This means even small changes in line endings or capitalization can break DKIM verification if the body isn’t normalized properly.

How canonicalization affects signature validation

When DKIM signs an email, it hashes the body using a consistent format. This is where canonicalization comes in—it defines how that hashing process handles variations. Relaxed canonicalization, used by Google, ignores differences in line endings (LF vs CRLF), normalizes whitespace, and folds case in headers. Simple canonicalization, used by Microsoft for certain domains, does not tolerate any change. Even a single extra space or repositioned line break can invalidate a signature.

Let’s say you’re sending a newsletter with embedded HTML. If the content manager adds extra line breaks during editing, Gmail (relaxed) will still accept the DKIM signature. But Outlook (simple) may reject it—especially if the sending domain relies on strict formatting. This mismatch is why some emails pass with Gmail and fail silently in Outlook, even if the content appears fine to users.

The problem isn’t just technical—it’s scalable. If you're sending to a large list without validating sender alignment, you're likely failing DKIM checks on a portion of your audience. Tools like MailTester’s bulk verification check actual delivery behavior, including DKIM alignment, before you send—helping you catch formatting issues that hurt inbox placement.

Why MIME structure matters more than you think

MIME structure defines how email bodies and headers are interpreted. A poorly formed MIME boundary or a misaligned Content-Type header can cause canonicalization to fail, even if the message content is otherwise correct. For example, a multipart message with mixed content types (HTML and plain text) must be processed in order—even a reordering of parts can alter the hash.

Industry standards like RFC 6376 define DKIM body canonicalization, but implementation varies. Google’s relaxed mode is more forgiving; Microsoft’s simple mode is stricter, especially in high-security environments like enterprise domains. A well-structured message ensures consistency across clients. But unless you’re testing real delivery, you won’t know if your DKIM is broken in Outlook until it’s too late.

While tools like MailTester’s inbox placement tester won’t fix your MIME structure, they do reveal whether DKIM verification passes in real client environments. You can’t assume what works in Gmail or a testing tool will work in Outlook—especially when simple canonicalization is in use.

Best practices to ensure DKIM signatures survive body encoding changes

If your DKIM signature fails in Gmail or Outlook, body encoding changes during transport are likely the culprit. You must sign the body after all processing—before any line ending normalization, whitespace modification, or MIME encoding. Use relaxed canonicalization (a, b) in your DKIM record, avoid altering the body after signing, and test actual inbox placement. This prevents common verification breaks caused by intermediary mail servers reformatting content.

Sign the body at the final stage of processing

  • Do not sign email content before adding headers, folding long lines, or applying MIME encoding. Let all transport-level transformations complete first.
  • Prefer to apply DKIM signing just before delivery—after all content transformations, including HTML whitespace cleanup and relaxed header canonicalization.
  • Letting mail servers modify content post-signing breaks verification. The signature must match the final delivered body.

Use relaxed canonicalization for Gmail and Outlook

  • Set your DKIM record to use relaxed canonicalization for both headers (h=b) and body (a=b). This allows small, legitimate transport changes without breaking the signature.
  • Gmail and Outlook both apply content changes during delivery—line endings, spacing, HTML formatting—so strict canonicalization will frequently fail, even with valid content.
  • Use RFC 6376 as the authoritative reference on DKIM and canonicalization methods.

Don’t modify content after signing

  • Avoid inserting or removing whitespace, changing line endings (CRLF vs LF), or altering HTML layout after DKIM signing. Even small changes void the signature.
  • Some email services, especially in BCC or forward chains, rewrite content—leading to signature validation failures if you're not prepared.
  • Test for these changes using real inbox placement tools. A signature can pass validation in a test environment but fail in a live user inbox.

Validate your setup with real-world inbox testing. Use MailTester’s inbox placement tool to check if your DKIM-signed emails arrive with a valid signature in Gmail, Outlook, and other popular inboxes—before sending to your audience.

How to verify that your DKIM signature remains valid after delivery

You can verify DKIM signature validity after delivery by testing recipient addresses with MailTester’s real-time API or bulk verification, then using inbox placement testing to send messages through Gmail and Outlook environments. Monitor for 'unverified' or 'DKIM failure' flags in the results, retest with corrected signing methods, and use the in-app AI assistant to interpret mismatches and diagnose issues like body encoding changes that break signature alignment.

Step-by-step verification process

  1. Check recipient address validity first. Use MailTester’s email checker or bulk verification to confirm addresses are valid before sending. Invalid or catch-all addresses can cause DKIM to appear as failed even if the signature is technically correct.
  2. Send a test email via MailTester’s inbox placement test. Use the inbox placement tester to deliver a message through Gmail and Outlook’s actual mail servers. This simulates real-world delivery and captures how the recipient’s MTA handles DKIM verification.
  3. Analyze the report for DKIM verification status. The test result will show whether DKIM passed, failed, or was unverified. A failure doesn’t always mean your signing is broken—it could mean body encoding changes during delivery altered the signed content, especially if the message was reformatted post-delivery.
  4. Check for body encoding issues. Gmail and Outlook apply transformations to email content, including whitespace normalization, line-length adjustments, and MIME encoding tweaks. These changes can break DKIM signatures if the signing method doesn’t allow for such adjustments. This is especially common when using non-standard or misconfigured body signing.
  5. Diagnose with the in-app AI assistant. If DKIM fails, use the AI assistant to analyze the test report. It can identify whether the failure is due to body encoding mismatches, incorrect header selection, or signature expiration. The AI compares the original signed content with the received version and flags discrepancies.
  6. Correct the signing method and retest. Based on the AI’s feedback, adjust your signing process—ensure you're signing the correct body parts, use consistent line endings, and verify your signing includes all necessary headers. Retest with the inbox placement tool to confirm the fix.

Why body encoding matters in DKIM verification

Digital signatures like DKIM depend on the exact byte stream of the message. Even small changes—like converting line endings from CRLF to LF or trimming whitespace in the body—can alter the digest and cause verification failure. This is why Gmail and Outlook, which perform automated content normalization, often report DKIM failures when the signature was generated with strict or non-robust body encoding rules.

For full compliance, ensure the body is signed after applying expected transformations, or use an aligned canonicalization method like relaxed body canonicalization to account for minor formatting changes. This helps maintain signature validity across different client behaviors.

Why testing DKIM and body content is critical before large sends

You can’t rely on email systems to silently fix malformed line endings or body content that breaks DKIM signatures. Even one improperly encoded line break in a large campaign can trigger DKIM failures in Gmail and Outlook, leading to delivery drops, bounces, or spam filtering. Testing this rigorously beforehand prevents reputation damage and ensures your messages arrive intact.

Body encoding and DKIM: a fragile relationship

DKIM validates the integrity of the email's header and body as sent. If the body content is altered during transit—say, due to incorrect line endings like CRLF vs. LF, or encoding inconsistencies—signature verification fails, even if the message looks correct to the recipient. Gmail and Outlook enforce strict validation, and they will reject or flag messages with corrupted DKIM signatures.

These systems don’t correct encoding issues on the fly. A single line ending that doesn’t follow the SMTP standard can break the signature chain. This isn’t theoretical—RFC 5322 defines the canonical format for email bodies, and any deviation during signing can invalidate the DMARC report. Major email providers treat signature mismatches as red flags, especially for senders with volume.

RFC 5322 specifies the standard format for email message bodies, including line ending requirements. When your content doesn’t conform, you invite rejection—even if the sender’s infrastructure appears correct.

Why verification prevents campaign failures

Without pre-sending validation, you’re sending blindly. A large campaign with thousands of emails may include a few addresses with malformed content—perhaps from a poorly formatted list or a template that adds extra line breaks. If DKIM fails on even 5% of messages, you risk triggering auto-blocks or spam filtering. Bounce rates spike, and your sender reputation drops fast.

MailTester’s bulk verification checks for these issues at scale. It evaluates both deliverability risks and content integrity, including how body encoding affects DKIM. With 98.9% accuracy, it flags invalid or poorly formatted addresses before you send—so you don’t waste bandwidth, breach provider policies, or damage your domain reputation.

Let’s be clear: DKIM is only as strong as the content it signs. Testing body encoding and signature readiness isn't optional for high-volume sends. It’s the difference between consistent inbox placement and an unexplained delivery failure rate.

Conclusion: Prevent DKIM failures by treating body encoding as part of the signing process

DKIM signatures depend on exact content match. Even small changes in body encoding—like CRLF vs LF line endings or extra whitespace—can break signature validation.

Gmail and Outlook perform strict checks on the signed content. If the body is altered during transit, the signature fails, leading to rejection or inbox filtering, even if the email is legitimate.

Use real-time verification and inbox placement testing to catch encoding-related DKIM failures before they impact deliverability. MailTester ensures your DKIM signature remains intact through every delivery step.

Sources

Keep reading

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

Frequently asked questions

Does Gmail allow relaxed DKIM canonicalization?

Yes, Gmail uses relaxed canonicalization, which tolerates minor formatting changes, but the signature still fails if the content deviates beyond the allowed norms.

Why does my DKIM pass in testing but fail in Gmail?

Testing may not replicate real delivery conditions. Line ending conversions, email filtering, or transport-layer modifications during delivery can break DKIM signatures.

Can whitespace in email body break DKIM?

Yes, if the canonicalization method is strict and the whitespace differs from the signed content, DKIM verification fails. Relaxed canonicalization reduces but does not eliminate this risk.

Does Outlook always use strict DKIM verification?

Outlook applies strict verification, especially using the simple canonicalization method. It checks the exact content byte-for-byte after delivery.

How can I test if my DKIM signature is valid in Gmail and Outlook?

Use MailTester’s inbox placement test tool to send emails through live Gmail and Outlook environments and verify DKIM status directly.

What is the safest time to apply DKIM signing?

Apply DKIM signing after all transport processing—just before delivery—so the signed content matches what the recipient receives.

Can I fix DKIM failures after they happen?

Only by correcting the signing process. Re-signing emails after delivery is not possible. Prevention via testing is essential.

Do MIME encoding changes affect DKIM?

Yes. MIME structure variations during encoding can alter the body content in ways that break DKIM if not accounted for in the canonicalization process.

Does MailTester test DKIM signature validity?

Yes, MailTester’s inbox placement test simulates delivery to Gmail and Outlook, verifying DKIM signature status in real environments.

How does body encoding relate to sender reputation?

Repeated DKIM failures due to encoding issues harm sender reputation and increase the risk of inbox filtering or blacklisting.

Can using SendGrid or Mailchimp impact DKIM verification?

Yes, if these services apply encoding changes after DKIM signing, the signature may fail. Ensure signing occurs after transport processing.

Is there a universal encoding standard for DKIM?

No. DKIM relies on strict alignment between signed and received content, with canonicalization methods defining acceptance rules. There is no universal standard.