Why Does DKIM h= Tag Order Matter in Relaxed Mode?

You signed your email correctly. The DKIM signature is valid. But it still gets rejected. Why?

It’s not a typo. Not a key error. It’s the order of your h= tag headers — a detail that, in relaxed mode, can break everything.

DKIM relaxed mode canonical form requires strict adherence to header tag order during signature verification. Even a single reordering — say, moving From before To — changes the canonical representation. And that small change is enough to invalidate a signature.

Receiving servers don’t interpret intent. They follow the rules. If your h= tag list doesn’t match exactly what was signed, the signature fails, regardless of correctness. This leads to deliverability issues, even with valid email content and proper authentication.

Key takeaways

  • DKIM relaxed mode canonical form depends on exact h= tag order; even minor rearrangements break signature validation.
  • A correctly signed email with misordered h= tags will fail verification, causing delivery failures despite valid content.
  • Consistency in header ordering during both signing and verification is critical to maintain successful DKIM authentication.

What Is Canonical Form in DKIM Relaxed Mode?

Canonical form in DKIM relaxed mode defines how header fields are normalized before signing or verification: lowercase field names, whitespace trimmed, and the order of headers in the h= tag must exactly match their order in the message. This is critical because DKIM validators compare the signed headers against the actual message order — even a single mismatch can cause verification to fail. If you're troubleshooting a DKIM signature that passes some checks but fails others, this order requirement is often the culprit.

How Relaxed Mode Normalizes Headers

In relaxed mode, DKIM applies two main rules: it strips leading and trailing whitespace from header values, and it converts field names to lowercase. For example, Subject: Hello becomes subject: hello in the canonical form. This helps reduce false failures due to formatting variations, like extra spaces or inconsistent capitalization in header names.

Why h= Tag Order Matters

Here’s where things get tricky: even though relaxed mode is designed to be forgiving, it still enforces strict order. If your message includes headers From, To, and Date in that sequence, your h= tag must list them in the same order: h=from:to:date. Reordering any field in the h= tag breaks the canonical form and will cause the DKIM check to fail during verification.

Many tools and email platforms automatically generate DKIM signatures with a consistent order, but custom or poorly configured code can get this wrong. This is one of the most common causes of DKIM failures in practice, especially when messages are processed through middleware or reassembled in transit.

According to RFC 6376 (the standard for DKIM), the canonical form must preserve the ordering of the specified headers to ensure consistency across verification steps. You can review the full specification at RFC 6376. This isn't theory — it's how DKIM works by design.

When testing if your DKIM setup is working, use a real-time email verification tool to simulate delivery and catch issues early. MailTester’s inbox placement tool checks DKIM, SPF, and DMARC in real inboxes, letting you see how your email performs from the recipient's perspective.

How Does h= Tag Order Affect Signature Verification?

The receiving server uses the h= tag in a DKIM signature to determine which headers to include and in what order. It reorders the headers from the incoming message exactly as listed in h=, regardless of their original position. If any header in h= is missing or appears out of sequence, the signature fails verification—no exceptions.

Header Order Isn’t Just a Detail—It’s Binding

DKIM signatures are built on precise expectations. The h= tag isn’t a suggestion—it defines the canonical form. If your message includes h=From:Subject:Date, the server expects those headers exactly in that sequence. Even a single missing header or a reordering breaks the chain.

For example, if h=From:Subject:Date is listed but Date comes before From in the actual message, the signature fails. The server doesn’t check if the headers exist in the message—it checks if they appear in the correct order, as specified in h=.

Relaxed Mode: What It Really Means

When DKIM uses relaxed canonicalization, the server applies minimal normalization—lowercasing header names and replacing linear whitespace with a single space. But relaxed mode doesn’t ignore header order. The h= list still defines the order exactly.

This is why header order matters even in relaxed mode. The standard doesn’t permit flexibility in the sequence of headers listed in h=. If the receiving server finds a missing header or a misordered one, verification fails immediately.

You can test this behavior yourself by reviewing the DKIM signature of a real message using tools like MXToolbox DKIM Checker or validating alignment with RFC 6376, Section 4.4. These confirm that h= order is enforced, not just in theory but in practice across mail systems.

If you’re sending bulk emails, validating signature correctness before sending is critical. Use bulk email verification to catch invalid or poorly signed addresses early—ensuring your DKIM setup holds up under scrutiny.

Common Mistake: Reordering Headers in h= After Signing

Reordering headers in the DKIM h= tag after signing breaks the canonical form, even if the final headers are identical. The verifier checks the exact order used during signature generation — any deviation causes rejection. This is a common oversight in code that normalizes or sorts headers post-signature.

Why Order Matters in the Canonical Form

DKIM relies on a strict, reproducible format called the canonical form. The h= tag lists headers in the order they appear in the message, and that order must be preserved exactly. Even if your code reorders headers for readability or internal processing, the DKIM signature will fail during verification.

Let’s say you sign a message with headers in this order: From, To, Date. If later, a library or email client reorders them to Date, From, To before sending, the canonical form no longer matches the signed one. The signature becomes invalid.

How This Goes Wrong in Practice

Many developers assume that as long as the header fields and values are correct, the order doesn’t matter. It does — and the specification makes this clear. The DKIM specification defines header canonicalization as a two-step process: first, the header names and values are normalized, then they are kept in the same order they appear in the email.

Even slight changes — inserting new headers, trimming whitespace, or sorting — can alter the canonical form. This is why some systems use a copy of the original headers before signing, rather than manipulating them. The same header list may have different outcomes depending on how it’s processed.

MailTester helps identify these issues by testing email deliverability and verifying that signatures follow standards. You can use our inbox placement test to simulate real-world delivery and catch canonical form mismatches before they affect sender reputation.

Always preserve header order from the original message when signing. If you must process headers after signing, re-sign with the correct, finalized list. It’s a small but critical step in maintaining reliable DKIM validation.

Step-by-Step: How DKIM Verification Works in Relaxed Mode

When a server signs an email in DKIM relaxed mode, it picks headers by name from the h= tag list, preserves their exact order, then normalizes them—lowercase, trim whitespace, format as field: value. The body is folded to 78 characters and stripped of trailing newlines. Both are hashed, and the signature is added. The recipient re-applies the same canonicalization using the same h= list. If the reconstructed order or body digest doesn’t match, the signature fails.

What Happens When You Sign an Email

  1. Header selection and order preservation — The signing server picks headers exactly as listed in the h= tag (e.g., h=From:Date:Subject). It does not reorder them, even if the email contains multiple instances of the same header. This matters because relaxed mode trusts the sender’s header order and canonicalization.
  2. Normalization of headers — Each selected header is transformed: converted to lowercase, whitespace around the colon is trimmed, and values are normalized. For example, From: [email protected] becomes from: [email protected]. This ensures consistency across systems.
  3. Body canonicalization — The body is processed by folding each line to 78 characters (or less), and any trailing line break is removed. This is critical—any difference in line folding or newlines causes the digest to mismatch, even when the content is identical.
  4. Hashing and signature generation — Both the normalized header block and the processed body are hashed using SHA-256 (or equivalent). The hash is then signed using the private key and embedded in the DKIM-Signature header.

What the Receiver Checks

  1. Reconstructing the canonical form — The receiving server applies the same rules: it uses the h= tag list to pick and preserve the header order, then normalizes each header.
  2. Reprocessing the body — The body is folded line-by-line to 78 characters and stripped of trailing newlines, matching the original signing process.
  3. Recreating the hash — The receiver computes the same header and body digests using the canonicalized data. If the result doesn’t match the signature’s hash, it fails.
  4. Signature validation — The public key in the DNS record is used to verify the signature. If the hash matches and the key validates, the signature passes.
The DKIM relaxed mode specification in RFC 6376 ensures that minor content variations—like whitespace or line folding—don’t break authentication, as long as both sides use the same canonicalization rules.

Relaxed mode is designed to be forgiving of common email formatting quirks. But it demands strict adherence to the h= tag order. If the server includes a header in the h= list but sends it in a different order, or the body is folded incorrectly, the signature will fail. You can test this behavior before sending by verifying your domain’s DKIM configuration with tools like MailTester’s email checker. It helps confirm your signs are valid and avoid deliverability dropouts due to misconfigured headers.

What Does the h= Tag Actually Do? A Clear Breakdown

The h= tag in a DKIM signature defines exactly which headers are included in the cryptographic hash. Only headers listed in h= are signed, and they must appear in the same order in both the signature and the actual message. If the order is wrong, the signature fails—even if all headers are present. This precision ensures mail servers can validate authenticity reliably.

Why Header Order Matters in DKIM

DKIM requires strict adherence to the order listed in the h= tag. The signing process hashes the headers in that exact sequence, and the receiving server expects the same order when verifying. If your mail server adds or reorders headers like Received or X-Header, even slightly, the signature will fail unless the h= list accounts for it.

For example, if you set h=from:to:subject:date:content-type;, the server must see those headers in that exact order. Any deviation—like a timestamp header between from and to—breaks the match. This is why email systems use canonical forms: they normalize whitespace and order for consistent hashing. The relaxed canonical form allows some flexibility, but not in header order.

Misconfigured DKIM often stems from this exact mismatch. It’s not enough to include the right headers—you must preserve their sequence. Tools like MailTester help catch such issues before they harm sender reputation or trigger inbox filtering.

How MailTester Helps Ensure DKIM Compliance

You can verify if your headers are properly signed and ordered using MailTester’s inbox placement testing. It checks the full DKIM signature alignment against RFC 6376—specifically the canonicalization methods defined in Section 3.4.

By simulating how major ISPs (like Gmail and Outlook) receive your messages, MailTester identifies issues like incorrect h= lists, improper header order, or missing tags before you send to real recipients. This helps avoid bounces, low deliverability, or spam folder placement.

While DKIM itself doesn’t require specific header inclusion, the h= tag is your control point. Use it wisely. For example, omitting headers like X-Priority or List-Id reduces risk but also limits trust signals. The trade-off is yours to manage.

Real-World Example: h= Tag Order Breaks Signature Validation

DKIM relaxed mode requires the header list in the h= tag to match the exact order of headers in the message body, even if the headers exist in a different sequence. If the signing server lists h=from:to:subject:date but the receiving server reconstructs headers as From, To, Subject, Date instead of From, Subject, To, Date, the signature fails validation—despite all headers being present and syntactically valid.

The Hidden Trap in Header Order

Let’s say your mail server signs a message with h=from:to:subject:date. That’s the canonical form you’ve configured. But the actual message sent has headers in the order: From, Subject, To, Date. The receiving server rebuilds the header list in the order they appear in the message, not the order in the h= tag. This mismatch breaks DKIM verification, even though the headers are valid and the domain is authenticated.

DKIM relaxed mode is designed to tolerate minor variations. But one of the most common pitfalls is ignoring the strict requirement that the h= tag order must mirror the message header order exactly. This is defined in RFC 6376 (Section 3.6) — the standard that underpins DKIM validation. Even if you’ve set up SPF, DKIM, and DMARC correctly, a misordered h= tag can still lead to a failed signature.

Many email infrastructure tools, including some SMTP relays and legacy mailing systems, reorder headers during processing. This isn’t malicious — it’s just how some systems parse MIME messages. But if you’re relying on DKIM for inbox placement, this ordering mismatch can cause deliverability issues without any clear error in logs.

How to Prevent This in Practice

You should verify both the header content and the sequence during DKIM signing. Use a tool like MailTester’s email checker to test individual messages and validate DKIM signatures after sending. It shows real-time feedback on header ordering and signature alignment, helping you catch issues before they impact your sender reputation.

If you use a third-party email service, check whether it reorders headers during delivery. Some platforms normalize header order to standardize validation—this can interfere with relaxed mode if the h= tag isn’t updated. Always ensure the signing process and delivery pipeline preserve the original header order.

For bulk campaigns or automated workflows, consider using an API like MailTester’s verification API to scan and validate your entire list—preemptively catching addresses that might trigger signature failures due to malformed or re-ordered headers.

How to Verify Your h= Tag Order Is Correct

Use a DKIM validator that logs the full canonical form of the message, including the exact header order in the final transmitted email. The h= tag must list headers in the same sequence they appear in the signed message — any reordering during signing breaks DKIM validation. Tools like MailTester’s inbox-placement testing capture this detail during real delivery attempts, showing you precisely how your headers are ordered when the email arrives.

Check the canonical form for header sequence

  • Run your message through a DKIM validator that outputs the full canonical form, including the h= tag values.
  • Compare the header list in the h= tag to the actual header order in the final message (as received).
  • Ensure no headers are missing or reordered — even a single out-of-sequence header breaks DKIM verification.
  • Use inbox-placement testing to see how your email is processed in real-world conditions, including the exact header sequence applied during delivery.

Ensure your signing software preserves header order

  • Verify your email platform or library doesn’t sort headers alphabetically before signing — this is a common cause of h= mismatches.
  • Check your SMTP or mailer library’s documentation for canonical form handling; some tools apply relaxed or simple canonical forms by default.
  • Use an email tool configured for relaxed canonical form with no header sorting — follow the DKIM specification (RFC 6376) strictly.
  • If you're using SendGrid, Amazon SES, or another service, confirm they process and preserve header order as sent — some default to relaxed forms that modify sequence.
  • Test with a known-valid email and compare the h= tag against your sending code’s header sequence.

If your h= order doesn’t match the final message, DKIM will fail — even if all other fields are correct. This is a common but subtle issue, especially when using third-party email platforms or custom signing libraries that reorder headers silently.

Why You Should Test DKIM Relaxed Mode in Practice

DKIM relaxed mode is required for inbox placement with Gmail, Yahoo, and Outlook—your alignment check can fail completely if the h= tag order in your signature isn’t aligned with the canonical form, even with a valid key and correct DNS records. You can’t assume it works just because the technical setup appears correct; real-world testing is the only way to catch these issues before they hurt your deliverability.

Why Canonical Form and h= Order Matter in Relaxed Mode

Relaxed mode standardizes how email headers are processed—not by their exact order, but by their canonicalized form. The h= tag in your DKIM signature lists the headers used in the signature, and their order must match the order they appear in the canonicalized version of the message. If, for example, you list Subject before Date in h=, but the canonical form processes Date first, the verifier rejects the signature—even if the key is valid and the domain aligns.

This isn’t a theoretical edge case. It’s a common failure point when developers or senders assume that any ordering is acceptable. Major providers like Google and Yahoo rely on strict canonicalization rules defined in RFC 6376 to verify signatures, and deviating—even slightly—triggers a failure. The result? 100% authentication failure across large batches of mail, all because of a single misplaced header in the h= list.

Testing Before Sending is the Only Reliable Defense

Running a real inbox placement test with a tool like MailTester's inbox tester simulates how your messages will behave in real inboxes. It checks not just DKIM and SPF, but also header canonicalization, relaxed mode alignment, and how the receiving server interprets your signature. This gives you a clear signal: “Yes, it works in practice,” or “No—here’s exactly where it fails.”

Tools like MailTester don’t just check if a key exists—they validate how it’s applied in context. With a real bounce, a real header stream, and real canonicalization, you’re testing the actual delivery conditions. There’s no replacement for that. Let’s be clear: even one misordered header in the h= tag can ruin your sender reputation overnight. But catch it in testing, before you send 100,000 emails, and you’ve avoided a major deliverability cascade.

How MailTester Helps Prevent DKIM Signature Failures

You can avoid DKIM signature failures caused by incorrect h= tag order in relaxed mode by testing your emails in environments that simulate real recipient server checks. MailTester’s inbox-placement testing validates the full email path, including canonicalization rules for DKIM, so you can catch alignment issues before they cause bounces or spam placement.

Testing DKIM Canonicalization in Real Conditions

DKIM relaxed mode requires strict adherence to header ordering in the canonical form, especially for the h= tag. If the header order in your message doesn’t match the one the receiving server expects during validation, the signature fails—even if the key is correct. This is a common source of silent delivery failures.

MailTester’s inbox-placement tests mimic how actual mail servers like Gmail, Outlook, and Yahoo process incoming messages. Each test includes a full DKIM validation step, so you’ll see whether your canonicalization setup is acceptable under relaxed mode, especially if you're using third-party tools that auto-generate headers without preserving order.

For example, while the RFC 6376 standard outlines the relaxed mode canonicalization process, real servers can vary in how strictly they enforce header ordering. That’s why testing in a live-like environment is necessary.

When you run a test with MailTester, you get a detailed report showing whether your h= tag list matches the server’s expected order. This exposes problems early—before your campaigns face low inbox placement or high bounce rates.

Proactive Checks with the Real-Time API

Let’s say you're building an email service and want to flag bad senders before they even leave your system. Use the MailTester Real-Time API to validate addresses and verify DKIM configuration in real time.

You can check individual addresses before sending, and the API returns whether the domain is likely to accept delivery—including whether it has known DKIM misconfigurations that would break verification. This stops sender reputation damage before it starts.

For teams managing large lists, the bulk email verification tool lets you assess thousands of addresses at once, with a clear breakdown of valid, invalid, catch-all, and risky addresses. You can filter out domains where DKIM or SPF are mismatched or poorly structured.

With over 98.9% accuracy in detection, MailTester helps you maintain a clean sender profile by isolating delivery risks early—so your messages land in the inbox, not the junk folder.

Final Take: Keep h= Order Immutable After Signing

The h= tag order is not a suggestion—it is a core part of the cryptographic contract in DKIM signatures.

Any change to the order, even a re-sorting of identical headers, breaks the canonical form and invalidates the signature.

Treat the h= list as a digital fingerprint: preserve it exactly as it was when the signature was generated.

Why This Matters in Practice

  • Mail servers validate DKIM using the exact header order from the signed message.
  • Even minor header reordering during relay or processing can cause signature rejection.
  • Proper signing tools must record and maintain header order without modification.

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 relaxed mode allow header reordering?

No. Relaxed mode allows normalization (lowercasing, whitespace trimming), but not reordering. The order in the h= tag must match the header order in the original message.

What happens if h= tag order mismatches during verification?

The signing server re-creates the canonical form using the h= list order. If it differs from the original, the hash fails and the signature is rejected.

Can I use multiple H= tags in a DKIM signature?

No. Only one h= tag is allowed per DKIM signature. Multiple tags are invalid and will cause parsing errors.

Is h= tag order important in strict mode too?

Yes. In strict mode, the header order in the h= tag must match the raw message order exactly — same requirement, no flexibility.

How does MailTester detect DKIM h= tag issues?

Through inbox-placed message testing that mimics how major providers validate DKIM signatures, including header order alignment.

What’s the difference between relaxed and strict DKIM mode?

Relaxed mode tolerates minor formatting changes (case, whitespace), but strict mode requires exact byte-level equivalence. Both require matching h= tag order.

Does MailTester support DKIM testing for bulk emails?

Yes. MailTester’s bulk verification and inbox-placement tools test DKIM integrity across large-scale sends, identifying alignment issues early.

Should I use DKIM relaxed mode or strict mode?

Use relaxed mode for production email — it’s widely supported and handles common client-side formatting. Strict mode is only for edge cases requiring exact alignment.

Can mail clients reorder headers after delivery?

Yes, but that doesn’t affect DKIM validation. The signature is verified based on the original message sent, not how the client displays it.

What’s a common cause of DKIM failure beyond h= order?

Incorrect selector, expired or misconfigured DNS records, broken DNS TXT query resolution, or failure to align with SPF and DMARC.

Can DKIM be tested without sending emails?

Yes. Tools like MailTester allow you to test DKIM signatures and full deliverability via inbox-placement testing without sending to real users.

How accurate is MailTester’s email verification?

98.9% accuracy in identifying valid, invalid, catch-all, and risky addresses — verified across millions of real-world validations.