Why is your DKIM signature failing even though the keys are correct?

You've double-checked the DKIM selector, the public key, and the signing algorithm. The code looks right. Yet, verification tools report a signature failure — despite everything appearing correct on the surface.

This isn’t a misconfiguration in your DNS or a flawed key. It’s likely something far more subtle: how your email headers were canonicalized before signing. Even tiny, invisible differences in line endings, spacing, or capitalization during the MIME header normalization process can break the signature match during verification.

DKIM depends on exact header alignment between signing and verification. One extra space, a different line ending, or inconsistent capitalization in a header field can cause a valid signature to fail. This is not a bug — it’s the protocol working as designed.

Key takeaways

  • MIME header canonicalization must exactly match between signing and verification — any deviation breaks DKIM.
  • Line endings (CRLF vs LF), header spacing, and capitalization in field names are common sources of canonicalization mismatches.
  • Different email servers and signing libraries may apply canonicalization rules slightly differently, leading to unpredictable verification outcomes.

What exactly is MIME header canonicalization in DKIM?

DKIM signature failure often stems from MIME header canonicalization errors—when the headers used in signing don’t match the headers the verifier processes. DKIM requires all signed headers to be normalized to lowercase, with whitespace collapsed and line breaks standardized to CRLF before hashing. If the signing and verification systems handle this step differently, the hash won’t match, causing failure—even if the email content is correct.

How canonicalization affects DKIM validation

Let’s say you sign an email with a header like Subject: Re: Meeting Tomorrow. DKIM doesn’t hash it as-is. Instead, it converts it to lowercase, reduces multiple spaces to one, and changes line breaks to CRLF. The final form is subject: re: meeting tomorrow, and this exact version must be used during verification. Any difference—like using LF or preserving mixed case—breaks the signature.

This normalization process is governed by RFC 6376, the official DKIM specification. It ensures that minor formatting differences—common in email transport—don’t invalidate a valid signature. You can review the full standard at IETF RFC 6376. The specification defines two canonicalization modes: relaxed (more forgiving) and simple (strict), but both require consistent processing between sender and recipient.

Why mismatches happen in real-world setups

Even small implementation quirks can cause issues. Forwarding services, content filters, or email clients that reformat headers without preserving the original syntax can alter the canonicalized version. For example, a header wrapped across multiple lines without proper CRLF will hash differently. If you use a mail relay that adds or reorders headers before sending, your signature may fail even if the message content is unchanged.

Most DKIM failures related to canonicalization aren’t due to malicious intent—just inconsistencies in how header data flows through the email pipeline. The good news: these are fixable. If you’re seeing DKIM failures, check your mail server logs to see if your headers are being altered during transit. Tools like MailTester’s inbox placement tester can help simulate real recipient validation and catch such issues before they impact your sender reputation.

How do non-standard line endings cause DKIM failure?

DKIM signatures rely on consistent line endings—specifically CRLF (Carriage Return + Line Feed)—to generate the same hash during signing and verification. If your mail server uses LF-only or CR-only line breaks, the resulting hash will differ from what the receiving server expects, causing even a legitimate signature to fail. This is a common, often invisible issue that leads to false negatives, even when the message content is correct.

The role of canonicalization in DKIM

DKIM uses a canonicalization process to standardize how headers and body content are formatted before hashing. This ensures that equivalent messages produce the same signature. The header canonicalization algorithm expects CRLF line endings. If your server sends headers with LF-only line breaks—common when using Linux-based systems or certain email libraries—the hash will not match the signed version.

Even small differences, like a single LF instead of CRLF, can alter the message’s canonicalized form. Since the verification process uses the exact same algorithm, any mismatch results in signature rejection. This isn't a flaw in the message, but a mismatch in formatting expectations.

Why this matters in practice

Many modern systems default to LF-only line breaks—especially those built with Unix/Linux underpinnings. If your email software or library doesn’t explicitly enforce CRLF, you may unknowingly sign messages with a different line ending than what the receiving server expects. This is especially common in automated systems or APIs that don’t handle MIME formatting consistently.

The Internet Engineering Task Force (IETF) specifies these requirements in RFC 6376, the core DKIM standard. According to RFC 6376, line breaks in headers must be CRLF. You can find the full specification at IETF RFC 6376. If your system deviates from that—especially in production environments—it’s likely to cause delivery failures.

Even if your DKIM implementation is technically correct, line ending inconsistencies can still break verification. This makes it harder to diagnose, since the signature is valid in isolation—until tested in context. Tools that validate email structures and test deliverability can help surface these issues early.

If you're sending bulk emails or managing a high-volume workflow, you can use MailTester’s bulk verification tool to check for structural issues in your email sends—including header canonicalization risks—before they impact deliverability.

Why does header field ordering matter in DKIM canonicalization?

DKIM canonicalization treats email headers as an ordered list — even if two headers have identical field names and values, changing their position can produce a different hash. If your email client or server reorders headers during delivery, and the receiving system uses a different canonicalization mode, the signature will fail. This mismatch is a common but often overlooked cause of DKIM verification failure.

The Two Canonicalization Modes: Simple vs. Relaxed

DKIM defines two ways to process headers: simple and relaxed. Simple mode uses the exact header order as sent. Relaxed mode ignores order and normalizes fields by sorting them alphabetically, then merging repeated headers. Some systems use relaxed by default; others use simple. If your mailer sends using simple but the receiver expects relaxed (or vice versa), the computed signature won’t match.

For example, if your message includes Received: headers in a different order than the receiving server expects, or if a transport agent inserts a Resent- header mid-stream, the canonicalized header string changes. This breaks the signature even if the content is identical.

Why Mismatches Happen and How to Fix Them

Many third-party mailing platforms, especially older ones, apply strict simple canonicalization without checking if the recipient expects relaxed. This inconsistency leads to signature failures, especially in automated systems or when routing through multiple servers. It's also common in email clients or frameworks that reorder headers on the fly, like some legacy MTA (Mail Transfer Agent) setups.

According to the RFC 6376 specification (the standard for DKIM), the sending side must use a consistent method, and the receiver must use the same. If they don’t, verification fails — no ambiguity allowed. This means alignment with your provider’s DKIM implementation is critical.

Even small changes — like an added Content-Type: header from a template engine, or a header reordering by an intermediate gateway — can make the difference between a passing and failing signature. This is why testing with real inbox placement tools matters.

Use tools that simulate real email delivery to spot these issues before you send at scale. MailTester’s inbox placement testing helps validate not just deliverability, but how your DKIM signature holds up across major inboxes — including when header ordering might trip up verification.

How do extra spaces or tabs affect DKIM header processing?

Extra spaces or tabs in DKIM-signed headers can break signature validation because DKIM mandates that multiple whitespace characters between header values be reduced to a single space. If your sending system inserts inconsistent spacing — like tabs, multiple spaces, or trailing whitespace — and the verifier doesn’t normalize it the same way, the canonicalized header won’t match, causing signature failure.

Why whitespace normalization matters in DKIM

DKIM uses a strict canonicalization process to ensure that header values are processed the same way by both sender and receiver. According to RFC 6376, the "relaxed" canonicalization mode collapses sequences of whitespace into a single space, but this only works if both ends interpret the rules identically.

Let’s say your email client or template engine adds two spaces before a header value like From: [email protected]. If your DKIM signing tool collapses these to one space, but the receiving server doesn’t, the computed digest won’t match the signature. Tabs are even trickier — some systems treat them as equivalent to spaces, others don’t, leading to silent failures.

Where this goes wrong in practice

This problem commonly surfaces in automated email systems using third-party or poorly configured templates. For instance, a marketing platform might prepend headers with inconsistent indentation, or a custom script might concatenate fields with hardcoded spacing that varies by environment. These small inconsistencies aren’t obvious in raw email, but they corrupt the DKIM verification chain.

Even minor discrepancies — like a trailing space after a header value — can break the signature without any visible error message from the sender. This is why some domains experience sporadic DKIM failures even when all other settings are correct. Tools that validate the full signing process, including header canonicalization, can catch this before sending.

MailTester’s inbox placement testing and bulk verification tools help identify such issues by simulating real-world delivery and flagging headers with abnormal whitespace or signature anomalies. You can test your email templates and configurations against these edge cases before they hit inboxes.

As a general rule, avoid manual editing of header fields, and ensure your email generation pipeline enforces consistent whitespace. Follow the standards laid out in RFC 6376, especially the relaxed canonicalization rules, to maintain integrity across systems.

What happens when header names are case-sensitive in non-canonical forms?

DKIM requires all header names to be lowercase in the canonicalized form before signing. If your email system signs headers using mixed case—like From: instead of from:—the resulting signature will not match when the receiving server validates it, even if the content is correct. This mismatch causes DKIM failure, often leading to messages marked as suspicious or rejected, especially when sending at scale.

Why the signing process must match canonical formatting

Even though DKIM’s canonicalization rule says: “convert all header names to lowercase,” the signing process itself must apply that rule before hashing. If your email library or script skips this step—maybe due to an old implementation or custom code—your signature gets calculated over improperly cased headers. The receiving server canonicalizes the headers exactly as defined in the RFC, so any deviation breaks the match.

Let’s say your system sends a header as X-Recipient: [email protected], but canonicalization expects x-recipient:. If the signature is generated using the original case, the hash won’t align with the one the receiver computes. RFC 6376 (the current DKIM specification) is very clear on this: the signed headers must be in lowercase before the hash is computed.

Where this error typically shows up

This issue is common in custom email builders or legacy email scripts that weren't updated to follow modern standards. Tools that generate raw MIME messages without validating canonicalization can introduce subtle errors. Even small inconsistencies, like capitalizing "To:" or "Subject:", can trigger failure if not handled during signing.

Many modern platforms handle this automatically, which is why newer systems rarely fail here. But if you’re using a framework or library that gives you low-level access to headers—like some PHP or Node.js email modules—you need to ensure lowercase conversion happens before signing.

For example, the DKIM specification (Section 3.4) states that "header names are converted to lowercase during canonicalization." This isn’t optional. It’s how the algorithm ensures consistency across systems that may vary in how they parse headers.

Testing these issues early can save days of troubleshooting. You can use tools like MailTester’s inbox placement checker to see how your messages are processed by real inboxes, including verification of DKIM signatures. Running this test on a sample of your email sends helps catch canonicalization problems before they impact deliverability.

How can you validate DKIM header canonicalization in practice?

You can validate DKIM header canonicalization by testing your messages through a real-time email verification service that checks DKIM signatures and provides diagnostic feedback on the canonicalization process. Let's use MailTester’s inbox-placement and deliverability tools to see exactly how your headers were normalized and where signing might have gone wrong.

Test with real-time diagnostics

  • Use MailTester’s inbox-placement testing to send your message through real mail servers and see whether the DKIM signature was verified.
  • Check the detailed result output: it shows whether the signature passed or failed, and lists the exact reason — including if header canonicalization was incorrect during signing.
  • Look for messages like “Header canonicalization failed” or “Signed headers don’t match expected format” — these point directly to MIME header normalization issues.

Inspect header normalization in action

  • Use MailTester’s email checker to test individual addresses and examine the headers as they’re processed during verification.
  • Pay attention to how field names are folded or normalized — DKIM requires lowercase field names and strict line folding using CRLF, which differs from general MIME standards.
  • Verify that header fields (like From, To, Subject) are in the correct order and that whitespace between them is normalized per RFC 6376 — even one extra space can cause a signature to fail.
  • If you’re sending bulk mail, run a bulk verification to catch repeated canonicalization errors across multiple messages.

DKIM’s canonicalization rules are strict. Even small changes in header formatting — like extra spaces, mixed case, or incorrect line breaks — can invalidate a signature. These errors often go unnoticed in testing unless the tool explicitly reports on header normalization. The best way to catch them is by inspecting the raw signature verification logs, as done in production-grade deliverability testing.

How does MailTester help catch MIME canonicalization errors before they impact deliverability?

You can prevent DKIM signature failures caused by MIME header canonicalization errors by testing your emails in real time with MailTester’s API. It checks both the final DKIM signature and the exact formatting used during signing—spotting mistakes like inconsistent line endings, misaligned whitespace, or uppercased header names before they hit inboxes. This reduces bounces and protects sender reputation.

Real-time verification catches formatting issues early

DKIM relies on consistent header formatting—what's signed must be exactly what the receiver checks. Even a single space or CRLF mismatch breaks the signature. MailTester’s real-time verification API simulates the full email submission process, comparing your headers against the canonicalization rules defined in RFC 6376.

It doesn't just validate the signature— it verifies the entire signing path. If your email client or mail server adds extra spaces before a header or uses Windows-style CRLF endings, MailTester detects and flags it. These are common issues when moving between systems or migrating email software.

What the API checks for (and why it matters)

The tool checks that:

  • Header names are in lowercase—per RFC 6376, this is mandatory.
  • Each header is followed by a single, correct CRLF (CR LF, not LF alone).
  • Whitespace between headers and content is consistent and RFC-compliant.
  • The order and structure of headers match what was used during signing.

MailTester doesn’t guess. It verifies your output against the standard, using the same logic that email receivers apply. This means you catch problems before they trigger a hard bounce or trigger spam filters.

For example, a mismatch in line endings—common when emails are processed on systems using different OS conventions (Windows vs. Unix)—can completely invalidate a DKIM signature even if the rest of the email passes validation.

You can test this in real time at the MailTester API. It’s built for developers and marketing teams who need to maintain high deliverability across large campaigns. Each verification returns a clear result, including any header canonicalization discrepancies that might cause DKIM failure.

For teams using platforms like SendGrid, HubSpot, or Klaviyo, integration with MailTester’s API ensures that every outbound email meets RFC standards before sending. It’s not just about catching invalid addresses—it’s about ensuring every technical element works as intended.

What’s the difference between relaxed and simple canonicalization in DKIM?

Relaxed canonicalization allows minor differences in whitespace and case within headers—like extra spaces or mixed uppercase/lowercase—while simple canonicalization requires every character, including spaces and letter case, to match exactly. If your email’s header formatting doesn’t align with the signing domain’s canonicalization mode, DKIM verification fails, even if the content is otherwise valid.

Why relaxed mode is common (and why it matters)

Most domains use relaxed canonicalization because it’s more forgiving of small formatting changes that happen during email transit—like line breaks or header reordering. This mode is standardized in RFC 6376, the definitive specification for DKIM. It’s designed to tolerate natural variations in how email clients or gateways reformat messages without breaking the signature.

When simple mode causes problems

Simple canonicalization, by contrast, demands pixel-perfect header consistency. A single extra space, a capitalization change, or a different line ending breaks the signature. This mode is less common but still used by some domains, especially those with strict internal signing policies. If your email is signed with simple mode but your relay server modifies whitespace, DKIM fails during verification—even if the message content is correct.

Here’s where things get tricky: the recipient’s email server checks the headers against the canonicalization mode recorded in the DKIM signature’s d= domain and c= tag. If the signing domain uses relaxed but the receiver checks with simple, or vice versa, verification fails. This mismatch is a frequent cause of DKIM signature failures, especially in environments with third-party senders or bulk email platforms.

Let’s say your email service provider signs messages with relaxed mode, but the receiving server applies simple mode. Even a small variation—like a line break that gets converted to a space—will invalidate the signature. This isn’t about spam or content; it’s about how headers are presented during transport.

You can avoid these issues by validating your DKIM setup end-to-end. Use tools like inbox placement testing to verify how your messages are received across top inboxes, and ensure your email client or platform maintains header fidelity during delivery. For bulk lists, bulk verification can also help spot invalid or poorly structured addresses before they hit your sender reputation.

Can a correctly configured DKIM still fail due to server-side processing?

Yes — even with a technically correct DKIM signature, a message can fail verification if the receiving server alters the email after signing. Common changes like adding X-headers, injecting tracking pixels, or rewriting content during delivery modify the original message structure. Because DKIM signs the exact header and body state at send time, any post-signing modification invalidates the signature unless the server re-signs the message.

How server-side changes break DKIM

DKIM relies on message integrity: a signature is generated based on a canonicalized version of the headers and body. If a receiving server modifies the message — say, by adding a delivery receipt header or converting HTML to plain text — that change alters the content. The canonicalization process on the receiving end won’t match the original, so the signature fails, even if the domain and key were configured properly.

Examples include DMARC-aggressive providers that inject tracking headers, or ESPs that rewrite links for analytics. These changes don’t always break delivery, but they do break DKIM validation — which can hurt sender reputation if repeated. According to RFC 6376 (the standard for DKIM), the signing mechanism assumes the message remains unchanged from send to verify. Servers that alter the message without re-signing it are deviating from that assumption.

Why this happens even with good setup

It’s not a flaw in your configuration. It’s a feature of how some email systems handle messages after delivery. Even a well-signed message from a trusted source can be rejected by receivers that check DKIM strictly — especially if they’re using automated systems to block non-compliant emails.

Let’s say your email server signs the message correctly. Then, the receiving mail server adds a header like X-Received-By: gateway.example.com. That header wasn’t in the original, so the signature verification fails. The same goes for content rewriting, such as turning `Click here` into a tracked link with an embedded image. The body content has changed, and the signature no longer matches.

Some providers that support signing post-processing (like SendGrid, Mailgun, or Amazon SES) will re-sign messages after such modifications, but not all do. If your outbound provider doesn’t, or if you’re using a third-party delivery service that adds content, DKIM validation can fail despite correct setup.

To catch signature failures early, you can test email delivery before sending. Using tools like MailTester’s inbox placement tester helps simulate real-world receipt conditions, including verification checks by major providers. This lets you identify issues like unexpected header changes or failed DKIM validation — before they impact your inbox placement.

Even with perfect DNS and keys, DKIM is only as strong as the message’s unaltered state from send to verify. If the receiving server modifies the message, re-signing is the only way to maintain validity.

The bottom line: keep your DKIM process strictly consistent

DKIM validation fails when the signature doesn’t match the recalculated hash of the message. Even small differences in header formatting—like line breaks, spacing, or capitalization—can invalidate the signature, regardless of correct key usage.

Canonicalization defines how headers are normalized before signing. If the signing process uses relaxed mode but the receiving server expects simple mode, or if whitespace is inconsistently handled, the signature verification will fail. Consistency across every step is not optional—it’s required.

Verify your DMARC compliance in practice

  • Use a real-time verification tool to test your outgoing emails before sending.
  • Check for MIME header canonicalization mismatches before they hit the inbox.
  • Ensure your email infrastructure applies the same normalization rules throughout.

Sources

Keep reading

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

Frequently asked questions

Can DKIM fail even if the signing key is correct?

Yes — DKIM can fail due to header formatting issues like incorrect line breaks, extra spaces, or case sensitivity, even with a valid key.

What does 'MIME header canonicalization' mean in simple terms?

It’s the process of standardizing how email headers are formatted before signing — ensuring consistent case, spacing, and line breaks.

How do CRLF vs LF line breaks affect DKIM?

DKIM expects CRLF line endings. Using LF only (common in some systems) causes a mismatch in hash calculation, leading to signature failure.

Why does header order matter if the values are the same?

DKIM canonicalization treats headers as a sequence. If headers are reordered during signing or verification, the hash changes, breaking the signature.

Can email clients like Gmail modify headers and break DKIM?

Yes — if Gmail or another service adds or alters headers after signing, the signature won’t match unless it re-signs the message.

How can I test if my DKIM signature is being processed correctly?

Use MailTester’s real-time API or inbox-placement testing to verify DKIM status, header canonicalization, and receive detailed failure diagnostics.

Does MailTester support DKIM validation for bulk emails?

Yes — MailTester’s bulk list verification and API can validate DKIM signatures and canonicalization across large email volumes.

Is DKIM failure always a configuration error?

No — DKIM failures can also result from third-party email processing, header modifications, or inconsistent canonicalization across systems.

What happens if I use relaxed vs simple DKIM canonicalization incorrectly?

Mismatched modes between sender and receiver result in different hash outputs — the signature will fail even if all other settings are correct.

Do all email services expect the same header normalization?

No — differences in canonicalization mode (relaxed vs simple) or interpretation of whitespace and line breaks can cause failures across providers.

Can MailTester detect if my email was reprocessed after signing?

Yes — MailTester flags suspicious content changes, header modifications, or unexpected re-signing that could invalidate the original DKIM signature.

What’s the best way to prevent DKIM failures from header issues?

Use a tool with real-time DKIM validation, test with a trusted service like MailTester, and ensure consistent header formatting across all email systems.