Why does DKIM header order matter in email authentication?

You sent a perfectly crafted email. The signature checks out. The SPF and DMARC align. Yet it still lands in spam or gets silently dropped. Why?

One reason often overlooked: DKIM’s header order. Though DKIM signatures are meant to be secure, they’re sensitive to changes in the order of headers—even minor ones. That’s where relaxed mode comes in.

Defined in RFC 6376, relaxed mode allows for small, common variations in header order and whitespace during transit. This relaxation is necessary—many MTAs reorder headers or adjust line breaks when routing. Without it, even valid emails would fail authentication.

Key takeaways

  • DKIM signatures depend on header order, but relaxed mode tolerates minor reordering and whitespace changes during transit.
  • Relaxed mode is essential because real-world email routing often alters header sequence or line breaks.
  • Without relaxed mode, legitimate emails would fail authentication even when delivered correctly.

What exactly is relaxed mode in DKIM, and how does it work?

Relaxed mode in DKIM allows email authentication to succeed even if header order or minor whitespace changes occur during transit, as long as the specified headers are present and correctly normalized. It’s designed to tolerate common email processing changes without breaking the signature. This makes it more reliable than simple mode in real-world delivery.

Normalization under relaxed mode

When DKIM uses relaxed mode, it normalizes header names (lowercasing) and normalizes whitespace—collapsing multiple spaces into one and trimming leading/trailing spaces. This means a header like Subject: Hello becomes subject: hello before signing, so small formatting changes don’t invalidate the signature.

Relaxed mode also lets you specify which headers must be signed. Only those listed in the h= tag are required to match exactly after normalization. This flexibility means a signature can still pass even if other headers are reordered or added, which is common in MTAs that rewrite or add headers during delivery.

How it differs from simple mode

Simple mode, by contrast, requires the exact order of all headers in the signature. Even a single newline added or removed, or a header moved slightly, breaks the signature. This makes it fragile—many legitimate email transformations, like those by mailing lists or spam filters, will break a simple-mode signature.

The practical impact is that relaxed mode dramatically increases the chances that a legitimate email will be accepted by receiving servers, even after processing. Most senders use relaxed mode because it’s resilient to real-world variations.

The DKIM specification (RFC 6376) describes both modes and their use cases. It explicitly recommends relaxed mode for most applications where header order isn't fixed.

If you’re validating email infrastructure or troubleshooting bounces, testing header normalization is essential. Tools like MailTester help detect issues with DKIM, SPF, and DMARC early—before you send. You can verify a single address with our email checker, analyze large lists with bulk verification, or test inbox placement with our inbox tester.

How does relaxed mode process the h= tag in DKIM signing

When DKIM uses relaxed mode, the order of fields listed in the h= tag doesn’t matter—only the set of headers matters. As long as the same headers are signed and included in the signature, validators will accept the signature regardless of their sequence. This is a key feature of relaxed mode, designed to improve compatibility with email clients that reorder headers during transit.

Understanding the h= tag in DKIM signatures

The h= tag in a DKIM-Signature header specifies which email headers are included in the digital signature. It’s a list of field names like from, to, subject, separated by colons. If a header isn’t listed, it can be modified without invalidating the signature. This ensures only intended headers are protected.

Relaxed mode makes header order irrelevant

In relaxed mode, DKIM validators ignore the sequence of headers in the h= list during verification. For example, h=from:to:subject and h=subject:from:to are equivalent as long as the same fields are signed. This is especially useful because some email systems and forwarders reorder headers after delivery, which would otherwise break strict-mode signatures.

Relaxed mode is the default for most modern email providers. The DKIM RFC explicitly defines this behavior, stating that relaxed canonicalization strips whitespace and normalizes case, so small variations don’t affect validation.

Let’s be clear: the h= tag still needs to list the correct headers, but the order can vary without causing a failure. This flexibility is a benefit, not a risk, when sending from trusted domains. The trade-off is slightly less rigid integrity, but it's compensated by higher delivery success across varied email infrastructure.

If you're checking DKIM compatibility or validating your email setup at scale, you can test how your signatures are processed. A real-time inbox placement test can reveal how your DKIM signs affect deliverability across major inboxes.

What happens if the h= tag order differs from the signed header order?

In relaxed mode, DKIM doesn't care about the order of headers listed in the h= tag. As long as the header names in h= match the actual headers present in the message (ignoring position), the signature validates. The validator reconstructs the expected header list from the names in h=, not from their sequence, so rearranging them doesn't break authentication.

How relaxed mode normalizes header order

Let’s say you sign headers like From: [email protected], To: [email protected], and Date: 2024-04-05. In the h= tag, you might list them as From:To:Date: or Date:From:To:—it doesn’t matter. The validator pulls the header names from the h= value, checks that each one exists in the message, and processes them in the order they appear in the actual email.

This normalization is built into the DKIM specification. As defined in RFC 6376, relaxed mode explicitly allows for variation in header order during signing and validation. The goal is to allow practical flexibility while maintaining security.

Why does this matter for email delivery? Because many email systems alter header order during transit—proxying, filtering, or rewriting. In strict mode, such changes would invalidate the signature. Relaxed mode prevents this from breaking authentication due to non-security-related changes.

What if a header in h= is missing?

If one of the headers listed in h= is missing from the message, the signature fails—even if all other headers match. DKIM checks that the exact set in h= is present and correctly signed.

For example, if your h= includes Subject: but the message has no Subject header, the validation fails, regardless of whether other headers are correct.

You can test this by sending a message with a known DKIM signature and altering the h= field or removing one of the listed headers. Tools like MailTester’s inbox placement test can help assess how changes to DKIM configuration affect deliverability in real-world inboxes.

When does DKIM fail due to header order issues?

DKIM fails only when the header fields listed in the h= tag do not match the actual headers present in the message. If your MTA adds a Received header or reorders fields, relaxed mode typically still passes — but simple mode breaks instantly, even with identical content, because it requires strict header order. This means DKIM validation can fail not due to content, but because of timing or routing changes in the delivery path.

Simple mode is fragile; relaxed mode is resilient

Let’s say you sign a message using simple mode and list headers in this order: From, Subject, Date. If your mail transfer agent (MTA) inserts a Received header before the original To field, the actual header order changes. Simple mode sees this mismatch and rejects the signature — even though the message content is unchanged.

Relaxed mode handles this. It ignores header order and instead normalizes field names and values by collapsing whitespace and lowercasing. So even if Received headers get added, or headers shift positions during relaying, relaxed mode maintains validity — provided the actual header fields listed in h= are present.

Why this matters for deliverability

Relaxed mode is the standard choice for most sending platforms because it accounts for real-world email processing. MTAs often modify headers — adding timestamps, hop information, or applying content filters — which would otherwise trigger DKIM failures in simple mode.

According to RFC 6376, relaxed mode “allows for minor header modifications” without breaking authentication, which is why it’s widely adopted. In practice, this reduces false negatives during validation, especially for emails passing through third-party relays, ISPs, or marketing automation tools.

You can avoid delivery issues by ensuring your DKIM signing process uses relaxed mode and properly lists all headers expected to be present. This includes any headers your MTA or ESP adds during transit.

How can you test DKIM's relaxed mode behavior in practice?

Test DKIM’s relaxed mode by sending emails with intentionally altered headers—reordering, adding whitespace, or inserting Received headers—and check if they still pass authentication. Tools that simulate transit changes let you verify whether your signing setup holds under relaxed mode, which is common in real email systems. Use inbox-placement testing to confirm deliverability under these conditions.

Simulate real-world transit changes

  1. Send a DKIM-signed email with reordered headers (e.g., move Received above From) using a test mail server or development environment. This mimics how intermediaries like gateways or forwarders might reorder headers during transit.
  2. Introduce subtle changes like extra newlines or spacing between header fields. DKIM relaxed mode tolerates these, but only if the h= tag explicitly includes the affected fields in its canonicalization list.
  3. Insert Received headers during transit—common in corporate email routing or forwarding. These changes are standard in practice but can break strict mode; relaxed mode should still validate if the h= tag covers all header lines.

Validate with real-world testing tools

Use email deliverability testing platforms to simulate how your signed messages perform across real mail servers. Tools that replicate major providers' filtering behavior can confirm if relaxed mode holds under live conditions.

Simulate real-world transit changesThe 3 steps described in “Simulate real-world transit changes”, in order.1Send a DKIM-signed email with reordered headers (e.g., move Receivedabove From) using a test mail server or development environment. Thismimics how intermediaries like gateways or forwarders might reorderheaders during transit.2Introduce subtle changes like extra newlines or spacing between headerfields. DKIM relaxed mode tolerates these, but only if the h= tagexplicitly includes the affected fields in its canonicalization list.3Insert Received headers during transit—common in corporate email routingor forwarding. These changes are standard in practice but can breakstrict mode; relaxed mode should still validate if the h= tag covers allheader lines.
The 3 steps described in “Simulate real-world transit changes”, in order.
  • Send a test batch through MailTester's inbox-placement tester to see whether your DKIM-signed emails land in inboxes despite header modifications. This service checks both authentication and filtering behavior.
  • Compare results across multiple receivers (Gmail, Outlook, Yahoo) to spot inconsistencies. Some providers enforce stricter header interpretation than others, even under relaxed mode.
  • Check your h= tag value against the RFC 6376 specification—specifically, the relaxed canonicalization method—ensuring it includes all headers that may be reordered during transit.

Relaxed mode is designed to handle real-world header variations. Testing it systematically with controlled changes ensures your email infrastructure remains resilient. The DKIM specification details how canonicalization works, and tools like MailTester help close the gap between theory and actual delivery performance.

What role does email verification play in ensuring DKIM validity?

DKIM relies on a valid domain and proper email infrastructure to work. If a recipient’s domain doesn’t support DKIM, or if the email address is a catch-all, role account, or disposable, the DKIM signature may fail—even if the message is legitimate. MailTester’s verification process identifies these risky addresses before they’re sent, reducing the chance of DKIM validation failures due to infrastructure issues rather than content.

Before sending, catch the addresses that undermine DKIM

Let’s be honest: even the most well-configured email sender can hit DKIM failures if the recipient’s infrastructure doesn’t support it. Catch-all addresses—common in corporate and legacy systems—often accept any incoming mail but don’t properly validate signatures. Disposable domains and role accounts (like admin@ or sales@) frequently disable or ignore DKIM checks entirely. You wouldn’t want your carefully signed message rejected because the recipient’s system ignores it. MailTester’s bulk list verification flags these before you send, so your DKIM signature isn’t wasted on addresses that never validate it.

Using the bulk email list verification tool helps identify invalid, risky, or misconfigured recipients. It’s not just about bouncing—it’s about spotting addresses where DKIM won’t work, regardless of your setup. This avoids the false impression that your email is technically sound when, in reality, it’s being ignored or rejected due to external limitations. The process isn’t about guessing; it’s about validating real delivery paths.

Prevent spoofing and confirm signing domain integrity

Drafting a message with a valid DKIM header doesn’t guarantee it will authenticate. Attackers can spoof domains with no valid DKIM setup. That’s why a real-time API check is crucial. MailTester’s real-time verification API validates both the address and its domain—ensuring the signing domain is genuinely active and capable of signing messages. If the domain doesn’t have SPF, DKIM, or DMARC records in place, or if it’s blocked, the API flags it. This reduces the risk of your DKIM signature being ignored or misattributed.

DKIM doesn’t work in a vacuum. If a sender’s domain isn’t properly configured—or if the receiving system doesn’t support validation—the signature fails. The same applies if the address is on a domain that doesn’t support signing at all. You can’t enforce DKIM compliance on someone else’s infrastructure. But you can choose not to send to addresses where that infrastructure isn’t likely to handle it. That’s where email verification becomes part of deliverability, not just address validation. As noted in RFC 6376, DKIM’s effectiveness depends on the recipient’s ability to validate. If they can’t, the signature is irrelevant. IETF’s RFC 6376 confirms this—validity is only meaningful if the receiving system acts on it.

By filtering out non-ideal addresses early, you preserve your sender reputation and keep your DKIM checks meaningful. That’s not just about avoiding bounces—it’s about sending only where authentication can actually have an impact.

How to validate DKIM setup using real-world deliverability testing

Send test emails through your ESP to real inboxes across Gmail, Outlook, and Apple Mail. Use MailTester’s inbox-placement tool to verify that DKIM signatures survive MTA processing — this confirms relaxed mode is working as intended and your headers are being validated correctly during transit.

Test DKIM integrity with real-world inbox delivery

  1. Send a test message from your ESP using your configured DKIM keys. Ensure it includes a valid h= tag listing all headers in the order they appear in the message. This is critical: relaxed mode allows header reordering, but only if the listed headers are all present.
  2. Use MailTester’s inbox-placement tester to send your message to real inboxes at major providers. Real inboxes, not lab environments, ensure you’re testing actual processing rules — including those applied by Gmail’s reputation systems and Outlook’s spam filters.
  3. Check the detailed report for header delivery and DKIM validation outcomes. If the DKIM signature passes, your setup is correctly handling relaxed mode. If it fails, the issue is likely in header ordering, missing headers in the h= list, or malleable header changes by an MTA.
  4. Compare the original header order with the delivered version. Relaxed mode should still validate if the h= list includes all headers that are actually signed — even if their order changes during transit. The key is presence, not sequence, in relaxed mode.
  5. Review any bounce or rejection logs. Some MTAs, especially older or tightly configured ones, may not fully honor relaxed mode. Use tools like MxToolbox to check your DNS records and alignment with RFC 6376.

Why relaxed mode must be tested in flight

Relaxed mode is designed to tolerate minor header reordering — a common occurrence across message transit. But not all DKIM implementations handle this correctly. You can’t assume it works just because your code passes local tests.

Some providers prioritize alignment between From and DKIM d= domains. If the h= tag is incomplete or incorrect, even relaxed mode will reject the signature. This is why testing with real-world delivery is non-negotiable.

Relaxed mode’s real-world behavior is not uniform. A 2022 RFC 6376 update clarified header handling, but implementation varies. Only in-production delivery testing reveals issues that local simulators can’t detect.

Common misconceptions about DKIM relaxed mode and header order

Relaxed mode doesn't ignore header order—It only allows for some flexibility in the sequence of signed headers, as long as all required headers are included, properly formatted, and normalized. You still must sign the correct headers, and any missing or misformatted ones will cause validation to fail. This isn’t a free pass to skip checks.

  • Relaxed mode does not remove the requirement to sign the correct headers—you must still include every header listed in the h= tag in the signature.
  • If a header in the h= tag is missing from the signature, even in relaxed mode, validation fails. The system checks for completeness, not just order.
  • Header order is relaxed only within the boundaries of the h= tag—headers can be reordered arbitrarily in the message body, but the list must remain accurate.
  • Whitespace and capitalization are normalized before signing, so you can use consistent formatting (e.g., From: vs from:), but only if normalization rules are consistently applied.
  • Signatures are checked against the canonicalized version of each header—this means case and extra spaces are stripped, so your signing process must mirror this normalization.
  • Relaxed mode does not tolerate malformed input. If a header is incorrectly formatted (e.g., missing colon, illegal characters), normalization fails and the signature is rejected.
  • MailTester's email checker can validate DKIM alignment and header consistency in real-time, helping spot issues before sending: test any address for deliverability risks.

What the RFC actually says

DKIM's relaxed mode is defined in RFC 6376, section 3.4, which confirms that ordering is relaxed only between fields, not within them. The canonicalization process strips trailing whitespace, lowercases the header name, and ensures consistent formatting. The key point remains: all headers in the h= list must be present and correctly signed.

How this impacts delivery

If your signing process skips headers or includes them out of order without proper canonicalization, even relaxed mode won’t save it. This is especially common with dynamic email templates that reorder headers during transit. Always test with a real email verification service like inbox placement testers to ensure your DKIM signature aligns with what receiving servers expect. You can’t rely on relaxed mode to fix poor implementation—only solid practices will.

Best practices for maintaining reliable DKIM authentication in production

Always use relaxed DKIM mode—simple mode fails too often due to header reordering in real-world delivery. Your email service provider must consistently include the same headers in the h= tag. Clean your list with real-time validation before sending. MailTester’s bulk verification catches invalid domains and catch-alls early, reducing DKIM validation failures.

Use relaxed mode, not simple mode

  • Simple mode requires identical header order every time—impossible in real email delivery chains. Relaxed mode ignores order differences and focuses on header content, making it far more reliable.
  • Major inbox providers like Gmail and Outlook expect relaxed mode. Using simple mode increases the chance of your emails being rejected or marked as suspicious.
  • According to RFC 6376, relaxed mode is the standard for production environments—simple mode is only suitable for testing or debugging.

Maintain predictable header inclusion

  • Verify that your ESP or mailing system includes the same headers in the h= tag across every send. Inconsistent header sets break DKIM validation even when the signature is correct.
  • Commonly included headers: From, To, Subject, Date, Reply-To, and Message-ID. These should remain stable unless you’re intentionally adding custom fields.
  • Use MailTester’s bulk verification tool to clean your email list before sending. It identifies catch-all domains, invalid addresses, and disposable email providers—many of which fail DKIM checks due to non-routable destinations.
  • Check that your DKIM signature includes only headers actually present in the message. Misaligned h= tags are a frequent cause of failure, even with correct signing.
  • If your provider dynamically modifies headers (e.g., adds tracking parameters), ensure they're also included in the h= list. Otherwise, DKIM fails upon verification.
“Relaxed mode is not just recommended—it's necessary for maintaining consistent, deliverable email in production.”

DNS record errors are another common failure point. Double-check your DKIM public key and selector at MxToolbox to ensure it’s published and accessible. Use tools like the inbox placement tester to validate end-to-end deliverability after configuration. A clean list and correct DKIM setup together provide the best baseline for inbox delivery.

Conclusion: DKIM relaxed mode makes email authentication resilient

Relaxed DKIM mode ensures that legitimate emails remain deliverable even after minor changes in header order, such as those introduced by MTAs during transit. This resilience reduces unnecessary bounces and maintains inbox placement for valid messages.

Understanding how the h= tag is processed under relaxed mode allows you to diagnose signature failures, validate header alignment, and improve authentication consistency across email platforms.

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 DKIM care about header order?

Only in simple mode. Relaxed mode ignores header order and validates based on header names and content instead.

What is the purpose of the h= tag in DKIM?

The h= tag specifies which email headers are included in the cryptographic signature for authentication.

Can I use relaxed mode with any DKIM implementation?

Yes—relaxed mode is widely supported and recommended for production email delivery.

Why does my DKIM signature fail after sending?

Common reasons include missing headers in h=, incorrect header normalization, or using simple mode with a relayed message.

How does MailTester help with DKIM verification?

MailTester’s inbox-placement and real-time API tests validate that DKIM-signed emails reach inboxes and pass authentication checks.

Can relaxed DKIM mode be bypassed by spoofers?

No—relaxed mode preserves cryptographic integrity. It only tolerates minor formatting changes, not content tampering.

Is it safe to rely on relaxed DKIM mode?

Yes—relaxed mode is standard practice and designed to balance resilience with security in real-world delivery.

Does adding a Received header break DKIM?

No—if DKIM uses relaxed mode, header order changes like added Received headers do not invalidate the signature.

How can I test my DKIM setup without sending mail?

Use MailTester’s inbox-placement tool to simulate delivery and verify DKIM validation under real conditions.

What happens if h= includes a header that isn’t in the message?

The signature fails during validation because the header list does not match the actual headers present.

Can DKIM work without proper h= tag configuration?

No—incorrect or missing h= entries will cause signature verification to fail, even with valid keys.

Is there a performance cost to using relaxed mode?

No—relaxed mode has no measurable performance impact and improves resilience across delivery paths.