What happens when DKIM validation fails due to a relaxed mode header mismatch?

You send an email, DKIM passes in theory—but the recipient’s server rejects it anyway. Why? Because a subtle mismatch in the header list defined by the h= tag breaks validation, even when the signature itself is mathematically correct.

DKIM signing and verification rely on precise header alignment. In relaxed mode—common in real-world email flows—certain headers are normalized (e.g., whitespace stripped, case ignored). But if the h= tag lists headers that don’t match what’s actually present or has an incorrect order, validation fails. Even a single extra newline, a capitalization change, or a missing header can trigger this.

Key takeaways

  • DKIM fails in relaxed mode if the h= header list doesn’t match the actual headers present in the message, even if the signature is otherwise valid.
  • Relaxed mode normalizes headers like whitespace and capitalization, but the header list in h= must still align exactly with the headers before normalization.
  • Even small header changes—like adding a custom header, reordering existing ones, or inserting line breaks—can break DKIM validation if they aren’t reflected in the h= tag.

How relaxed mode in DKIM changes the rules for header matching

DKIM validation fails in relaxed mode when the actual headers in the message don’t match the list in the h= tag after normalization. In relaxed mode, DKIM ignores minor formatting differences—like whitespace, capitalization, or line folding—by normalizing headers before signature verification. If the verifier doesn’t apply the same normalization rules to the live message headers, the comparison breaks, and validation fails, even if the underlying content is correct.

Relaxed mode normalizes formatting, but only if both sides agree

Relaxed mode was designed to handle real-world email delivery variations. It treats header fields as semantically equivalent even if they’re formatted differently—so "Subject: Hello" and "subject: hello" are treated the same. This normalization includes converting whitespace to single spaces, folding long lines, and ignoring case.

But here's the catch: both the signer and the verifier must apply identical normalization logic. If your email system prepends a header with extra spaces or inserts a CRLF where it shouldn’t, and the verifier doesn’t normalize it the same way, the signed list in h= won’t match the actual headers. The signature passes the syntax test but fails semantic alignment.

Why mismatched header lists cause validation to break

The h= tag in a DKIM signature lists the header fields that were signed. It must match the actual headers in the message after normalization. If a field like From: appears as From: [email protected] in the signature but is sent as from: [email protected] or with extra line breaks, and the verifier doesn’t normalize both sides identically, validation fails.

This is common in email clients or forwarding services that modify header spacing or casing. Even small issues—like a missing space between a field name and colon—can break validation if not handled consistently. The IETF RFC 6376 (the standard for DKIM) defines these normalization rules explicitly, and all validators must follow them to interoperate.

For example, the DKIM specification states that fields must be stripped of leading and trailing whitespace, folded at line breaks, and converted to lowercase before comparison. If your system deviates—even subtly—you risk validation failure.

Always check that your email infrastructure applies the same normalization used by the receiving mail server. Tools that test DKIM signatures with actual email traces can spot these mismatches early. You can verify DKIM structure and header alignment using MailTester’s inbox placement test to simulate real-world delivery conditions.

The impact of non-standard header ordering or insertion on DKIM

DKIM validation fails in relaxed mode when the h= header list doesn’t match the actual headers present during verification because the signature is tied to a specific, ordered set of headers. If a system adds, removes, or reorders headers like Received, MIME-Version, or Content-Type—even after signing—the signature is invalidated, even if the body is unchanged. This is a common failure point when emails pass through multiple relays or are processed by email clients.

Why header modifications break DKIM signatures

When DKIM signs an email, it computes a hash over a specific list of headers defined in the h= tag. If the receiving server applies relaxed canonicalization but the actual headers don’t match the signed list, the hash won’t verify. For example, a Received header added by a proxy server during transit—something that’s standard behavior—can cause a mismatch if it wasn’t included in the original h= list.

Some email routing systems insert headers post-signature, such as Resent-By or DKIM-Signature headers for forwarding. These are not part of the original signing context and can cause validation to fail unless the h= list accounts for them. The same applies to mail clients that modify message structure or add tracking headers, especially in automated campaigns.

Even subtle changes—like reordering headers with identical names due to message parsing—can break relaxed mode. DKIM relaxed mode allows some flexibility, but only within the defined header list. If the server sees a different header order, it can’t reliably reconstruct the original hash, and the signature is discarded.

Let’s be clear: if you’re sending email at scale and seeing DKIM validation issues, check the h= header list against the actual message headers at delivery. Use tools that test real-world delivery paths to identify where headers are being added or reordered. The DKIM spec explicitly defines relaxed canonicalization but also makes it clear that the signature is only valid if the header set matches.

To avoid this, sign with a comprehensive h= list that includes all headers your infrastructure or third parties might add. Commonly overlooked headers include Received, Resent-From, Auto-Submitted, and Content-Transfer-Encoding. If you're using a third-party ESP like SendGrid or Mailchimp, verify how they modify messages before sending.

Use inbox placement testing before sending to spot DKIM failures early. Test how your email delivers across providers—this reveals if DKIM is failing due to header mismatch or other issues during transit.

Why relaxed mode still requires precise header alignment after normalization

Relaxed mode doesn't skip header order—it normalizes it first, then checks that the h= list matches the normalized headers in sequence. Even one extra or missing header breaks the validation, because DKIM verifies the exact set of headers used in the signature.

Normalization isn't a free pass

Let’s say you send an email with a slightly reordered or modified header. Relaxed mode still normalizes spaces, line breaks, and casing, but it doesn’t ignore structural mismatches. The h= list in the DKIM signature must exactly reflect the normalized headers present in the message.

For example, if the h= list includes from:to:subject but the actual message has a cc: header not in that list, or a list-unsubscribe header that shouldn’t be there, the validation fails. The signature is tied to a specific set of headers — normalization doesn’t expand or relax the list itself.

Why the mismatch happens in practice

Email systems often process headers inconsistently during transit. A mailing list server might add a List-Id or Precedence header, or a gateway might rewrite Received lines. These aren’t typically signed, but if they slip into the h= list by mistake, even in relaxed mode, the signature fails.

Similarly, if a header like Content-Type is encoded with unusual whitespace or wrapped incorrectly, the normalization step might fail to produce a match with what’s in the h= list. This isn’t a flaw in relaxed mode — it’s how RFC 6376 defines it.

According to the [DKIM specification (RFC 6376)](https://www.rfc-editor.org/rfc/rfc6376), the h= list must correspond exactly to the headers used in the signature after canonicalization. That means no guessing. When in doubt, verify your DKIM setup with real-world testing.

Use our email checker to validate addresses and catch misconfigurations before sending. For ongoing DKIM hygiene, test your email streams with our inbox placement tool to see how your authenticated messages land in real inboxes.

Step-by-step: How to verify your DKIM header list matches actual sent headers

DKIM validation fails in relaxed mode when the h= tag lists headers that don’t match the actual message headers—either in name, order, or presence. Even a single mismatched or missing header causes the signature to fail. To fix it, extract the raw header before sending, normalize each header key to lowercase with collapsed whitespace, and ensure the h= list includes only the exact headers present in the message.

  1. Extract the raw email header before sending — Use your MTA, ESP, or a debugging tool to capture the full header as it exits your system. This is the definitive version used in DKIM signing. Avoid relying on headers from a draft or webmail interface; they may differ from the final version sent.
  2. Compare header names and order against the h= tag — The h= tag in your DKIM signature must list every header included in the message, in the exact order they appear. Even a slight change in order can break relaxed-mode validation. Headers are case-insensitive in relaxed mode, but order matters.
  3. Normalize each header name — In relaxed mode, header keys must be lowercased and whitespace collapsed. For example, "Subject: Test" becomes "subject:test" (no leading/trailing spaces, single space between). This applies universally to both the raw header and the h= list.
  4. Verify all headers in h= are present, and no extras exist — The h= list should include only those headers actually in the message. Omitting a header or listing a non-sent one will cause failure. Use tools like RFC 6376 section 3.5 to confirm relaxed mode rules.
  5. Test the full signature with real-time verification — Use MailTester’s real-time verification API to validate your DKIM signature before sending. It checks header normalization, h= alignment, and overall validity—no guesswork, no delays.

Why order and presence matter in relaxed mode

In relaxed mode, DKIM requires both exact header names and correct sequence. An extra header, a missing one, or an out-of-order header breaks matching. Even if all headers are technically correct, a single misplacement can invalidate the signature. The relaxed standard applies to the full header list, not just selected fields.

Use automation to avoid manual errors

Manually checking headers is error-prone. If you send large volumes, integrate with a verification tool early in your workflow. MailTester’s bulk verification lets you check entire lists for DKIM readiness—ensuring headers are consistent and properly signed before deployment.

How MailTester helps catch DKIM header mismatches before sending

DKIM validation fails in relaxed mode when the header list in your signature doesn't match the actual headers included in the email—especially if you're signing non-canonical headers or using tools that reorder or modify them. MailTester finds these mismatches early by simulating real-world email delivery and testing both content and cryptographic signatures. It checks not just if an address is valid, but whether your message is signed correctly at the wire level.

Proactive validation across your entire email workflow

  • Use inbox-placement testing to send a real email to known inbox providers and see if DKIM passes in practice—not just on paper. This catches header mismatches before they impact deliverability.
  • Enable the in-app AI assistant to scan your email stream for known signing issues, including cases where h= lists in the DKIM signature don’t align with actual headers like From, To, or Date.
  • Test individual messages using the real-time API—a precise way to validate how your email renders at the protocol level, including relaxed mode header matching.
  • Run bulk list verification via MailTester’s bulk checker to filter out addresses that may generate signature failures due to malformed content or unusual header structures.
  • Review detailed feedback on your DKIM signature—especially the h= tag—to ensure only the headers intended for signing are included. Misaligned signed headers are a common cause of relaxed mode failures.

Why relaxed mode matters and how it’s tested

Relaxed mode in DKIM allows minor formatting differences, but it still requires the header list to reflect reality. If you're signing from: subject: date: but the actual message has From or Subject altered by an ESP or filter, the signature will fail. This is why simulating real delivery is key.

According to RFC 6376, relaxed mode is designed to reduce breakage from common header transformations. But it only works when the h= list accurately reflects what’s sent. You can test this in isolation using MailTester’s API or verify your full campaign path with inbox placement tools.

Let’s be clear: a valid email address isn’t enough. If your DKIM signature points to headers that don’t exist or are reordered, the message fails validation—even if everything else seems correct. MailTester catches this before you send.

Common header modifications during transit that break DKIM

Dkim validation fails when h= header list doesn't match in relaxed mode because intermediate mail servers often add or alter headers like Received, MIME-Version, or Content-Type during transit. These changes aren't flagged by relaxed mode's header canonicalization, which assumes only minor whitespace tweaks. When the actual headers diverge from the list in h=, the signature check fails. This is especially common with email gateways, security filters, and routing agents that modify content or structure without preserving the original DKIM signing context.

Received headers and MIME injections are frequent culprits

Most mail servers insert a Received: header when forwarding messages. These entries are added by every hop—mail transfer agents, security gateways, and spam filters. Since DKIM signs the original header list, any new Received: header breaks the match unless explicitly included in the h= value. The same applies to automated systems that inject MIME-Version: or Content-Type: headers in the body, which can alter the canonicalized header list.

Security filtering services often rewrite or normalize headers like From: or Subject: for tracking or spam mitigation. A routing agent might replace a domain in the From: field to preserve SPF alignment, or a gateway may truncate a subject line exceeding a threshold. In relaxed mode, DKIM only ignores whitespace, not structural changes. So even a single added or modified header causes verification to fail.

Large header values get truncated, breaking signature alignment

Some gateways or servers enforce strict limits on header length—commonly 78 characters per line in the old SMTP spec. If a header like References: or Message-ID: exceeds this, it gets split or truncated. When the canonicalization process later reconstructs the header, it may differ from the original. Since relaxed mode still checks the exact header names and values, even a single character change invalidates the signature.

This is why DKIM signing must account for known processing steps. Tools like RFC 6376 define relaxed mode specifically to tolerate minor changes, but only when the modification is within allowed boundaries. When systems deviate too far—for example, by injecting unlisted headers or altering field contents—you should verify your mail streams with tools that test how headers survive transit. For example, MailTester's inbox placement tester can simulate routing anomalies and highlight where DKIM fails due to header divergence, helping you identify misconfigured or overly aggressive filtering setups.

The role of header normalization in DKIM relaxed mode

DKIM validation fails when the h= header list doesn’t match in relaxed mode because only the headers explicitly listed in h= are subject to normalization during verification. If a required header is missing or altered outside that list, even small changes can break the signature. The relaxed mode allows flexibility in whitespace and line breaks, but only for headers in the signed list — not for others.

Only listed headers are normalized

When DKIM uses relaxed mode, it normalizes only the headers specified in the h= parameter. This means any header not listed — even if it’s in the message body — can be altered without affecting the signature. Let’s say your email includes a Subject header not in h=; changing it from "Update" to "New Update" won’t break the signature, because it’s not verified.

But if a header like Date or To is in h= and gets modified during transit (e.g., by a relay adding a header or stripping whitespace), the verification fails. Relaxed mode can handle minor formatting issues, but it doesn’t ignore signed headers that were altered.

Unsigned headers can be changed safely

If a header isn’t in the h= list, it doesn’t need to be preserved — so changes to it don’t affect DKIM validation. For example, a mailing list manager adding a List-Id or Auto-Submitted header won’t break the signature, even if the format changes slightly.

This is why you see DKIM passing in many inbox scenarios where the original message has been modified — only the signed headers matter. But if the signing domain forgot to include a critical header in h= (like From or To), even relaxed normalization won’t help. The mismatch causes failure.

The key rule: DKIM relaxes formatting only for headers in the h= list. If your email client or service alters a header not listed — or leaves one out that should be listed — the validation will fail. The DKIM RFC defines this behavior clearly: normalization applies strictly to the signed header set.

Before sending high-volume campaigns, verify your DKIM setup with real email traffic. You can test how your domain signs messages and detect which headers are being misaligned using inbox placement testing at MailTester's inbox tester. This helps catch issues before they hit deliverability.

How to test DKIM validity using real-world delivery simulation

You can catch DKIM validation failures caused by mismatched h= header lists in relaxed mode by sending test emails through MailTester’s inbox-placement test. This simulates how real mailbox providers evaluate your messages, revealing hidden issues like missing or misordered headers before you send at scale. The delivered message’s full DKIM signature is available for inspection, so you can compare the h= list to the actual headers the recipient actually received.

Run a real-world inbox placement test

  1. Send a test message via MailTester’s inbox-placement tester. This route mimics how actual mailbox providers (like Gmail, Outlook, or Apple Mail) receive and process your email. You’ll get back the exact headers, DKIM signature, and delivery outcome as a real user would.
  2. Extract the DKIM signature and compare its h= list. The h= value specifies which headers were signed. In relaxed mode, these don't need to match 1:1 with received headers, but must be a valid subset. If the received message has a header not listed in h=, it can still pass—but if a required header is missing from the list, DKIM validation fails.
  3. Use the in-app AI assistant to analyze the header mismatch. Paste the DKIM signature and the full recipient header output into the AI assistant. It will review each header and flag discrepancies, such as missing Message-ID or Date in h= when they appear in the received email. This catches edge cases like automated tooling modifying headers post-transport.
  4. Fix the signature before large-scale sends. Once you identify which headers are signed but not present, or which are present but not signed, adjust your signing configuration. This prevents delivery failures and improves sender reputation.

Why relaxed mode isn’t a free pass

Relaxed mode allows minor header alterations (e.g., whitespace changes), but it doesn’t excuse missing required headers. Per RFC 6376, the h= list must include all headers that were intentionally used in the signature. If a header like To or Subject is signed but missing in the final received message, or if a non-significant header like Received is listed in h=, validation fails. This is why testing in real delivery conditions matters—it reveals what the actual mailbox sees, not what your tooling assumes.

Real-world testing is more reliable than static verification tools. Tools like SPF Check or MXToolbox can test DNS records, but they don’t simulate end-to-end delivery. MailTester’s inbox-placement test gives you the full picture: sender reputation, header integrity, DKIM output, and deliverability outcome. Use it early in your pipeline—before you scale. The cost of a single DKIM failure in a high-volume campaign can be a blocked sender IP or spam filtering.

Test your email pipeline before it reaches your audience. With MailTester’s inbox-placement test, you’re not just verifying syntax—you’re validating delivery in real conditions.

The difference between canonicalization and relaxed mode in DKIM

DKIM validation fails when the h= header list doesn’t match the actual headers in relaxed mode because even minimal normalization still requires every signed header to be explicitly listed—no defaults, no assumptions. Relaxed mode applies only lowercase conversion, whitespace collapse, and line-ending folding, but the signer must still include each header intended for signing, in full, within the h= tag. If a header is missing, even if it’s unchanged by the canonicalization process, the signature won’t validate.

How relaxed mode normalizes headers

In relaxed mode, DKIM applies just three transformations: it converts header keys to lowercase, collapses contiguous whitespace into a single space, and removes line-ending foldings (soft line breaks) from header values. These changes are minimal and designed to be forgiving of minor formatting differences that might occur during transit. The goal is to allow valid emails to pass even when routed through systems that reorder or reformat headers slightly.

But relaxed mode doesn’t guess what headers are signed. It relies entirely on the h= tag in the DKIM-Signature header to define which headers are included in the hash. If the tag lists only from:to:subject but the message contains a signed date header, and that header wasn’t included in h=, the verification fails—regardless of whether the signature was otherwise intact.

Why the sender must explicitly list every header

DKIM’s signature is computed over a specific, normalized set of headers. Even in relaxed mode, where the normalization is light, the verifier expects the sender to be precise. There’s no fallback to "just assume all headers are signed." This is a deliberate security and integrity constraint: every signed header must be accounted for in the header list.

Let’s say your mail server signs From, To, Date, and Message-ID. If you only list from:to in h=, the validator will ignore the Date and Message-ID fields during hashing, even if they’re present. This mismatch leads to a failed validation. This isn’t a bug—it’s how DKIM is defined in RFC 6376. The specification requires strict alignment between the h= list and the actual headers included in the signature.

Relaxed mode doesn’t change the rule—only the normalization. It still demands full transparency from the sender. If you’re debugging DKIM issues, validating header alignment with the h= tag is the first step. You can test this setup using tools that inspect the full DKIM-Signature header and compare it to the actual message. For instance, MailTester’s bulk verification helps catch malformed or missing header configurations before they impact deliverability.

Why header mismatches are a common cause of failed DKIM validation

DKIM signatures rely on strict header alignment. Even a single added, removed, or altered header during transit—especially in relaxed mode—can break the signature verification.

This typically indicates misconfiguration in email routing, forwarding rules, or content transformation by intermediaries, leading to rejected messages, damaged sender reputation, and poor inbox placement.

Tools like MailTester detect these issues by simulating real-world validation across email infrastructure, helping catch header mismatches before they impact deliverability.

Sources

Keep reading

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

Frequently asked questions

What does the h= tag in a DKIM signature do?

It lists the exact headers that were included in the DKIM signature. A mismatch between this list and the received headers causes validation failure, even in relaxed mode.

Why does relaxed mode still fail validation if headers don’t match?

Relaxed mode normalizes headers but still requires the same list of signed headers in the message as specified in h=. Missing or extra headers break the verification, even after normalization.

Can a received header like Received break DKIM signature validity?

Yes — if the Received header wasn't included in the h= list and was added post-signature, it can cause a mismatch, leading to DKIM failure.

How do I know if my DKIM h= list is correct?

Compare the h= list against the exact headers in your sent message after full canonicalization. Use MailTester to simulate real delivery and verify consistency.

Does DKIM relaxed mode allow missing headers?

No. Relaxed mode applies normalization but still requires the exact same headers in the h= list as are present and signed. Missing headers result in validation failure.

Can email services inject headers after DKIM signing?

Yes — many email gateways, filters, or routing systems inject headers like Received or Content-Type after DKIM signing, which can break the signature.

How does MailTester catch DKIM validation issues?

MailTester’s inbox-placement testing simulates real delivery and reviews full signature integrity, including header list alignment, before sending.

What happens if DKIM fails in relaxed mode?

The email may be rejected by recipient servers or marked as suspicious. This harms sender reputation and reduces inbox placement rates.

Is it safe to include all headers in h= for DKIM?

Only include headers you need to sign. Including unnecessary headers increases the risk of mismatch due to transit modifications.

Can I test DKIM verification in real time?

Yes — use MailTester’s real-time verification API to test individual messages for DKIM integrity, SPF, and DMARC alignment before sending.

How accurate is MailTester's verification process?

MailTester achieves 98.9% accuracy across bulk and real-time checks, helping teams reduce bounces, detect invalid domains, and maintain sender reputation.

Do purchased MailTester credits expire?

No — all purchased credits never expire, allowing teams to manage verification workloads over time without rush or waste.