DKIM h= Headers Order Issue

Why Does DKIM Signature Validation Fail When h= Headers Aren’t in Alphabetical Order?

You send a carefully crafted email, authenticated with DKIM, only to watch it get rejected by Gmail or Outlook. The bounce message says “DKIM signature validation failed.” You check your setup, re-run the test, and still no luck. This happens more often than you think — not because of misconfigured keys or DNS errors, but because of one tiny detail: the order of headers in the h= tag.

DKIM requires all header names listed in the h= parameter to be sorted alphabetically by name, not by the order they appear in the email. This rule is baked into RFC 6376 — the official specification for DKIM. If even one header name is out of order, the entire signature fails validation. Receiving servers don’t guess; they reject.

Key takeaways

DKIM signature validation fails if any header name in the h= tag is not sorted alphabetically, per RFC 6376.
Sorting is based on the header name only — the order of appearance in the email or content does not matter.
Even one misordered header causes the entire signature to be rejected, breaking email deliverability.

How DKIM Uses h= Headers to Validate Signatures

When you sign an email with DKIM, the signature includes a list of header names in the h= tag, like h=from:to:subject:. The receiving server re-creates that list from the actual headers in the message, sorts them alphabetically, and compares it to the one in the signature. If the sorted lists don’t match—even if the values are correct—the DKIM signature fails. This is why header order during signing matters.

The Hidden Role of Header Order in DKIM

DKIM doesn’t just care about headers—it cares about their exact order during signing. The h= field in a DKIM signature specifies which headers were used in the signature calculation. The receiving server must process those headers in the same sequence. But instead of preserving order, it sorts them alphabetically before validating. That’s the rule.

Let’s say your email includes From, Subject, and To in a certain order. If your signing system puts them in h=Subject:From:To, and the receiving server sorts them to From:Subject:To, the validation fails. The values might be correct, but the sorted list from the signature doesn’t match the one it builds. This is a common mistake in malformed DKIM configurations.

Why Alphabetical Sorting Isn’t Just a Preference

Alphabetical sorting isn’t a design flaw—it’s how DKIM is defined in RFC 6376. The standard makes no exceptions for header order at the verification stage. This ensures that all implementations behave the same way, no matter how the headers were sent. The receiving server must not rely on header order in the message; it must derive the list directly from the headers and sort them.

That means if you’re configuring DKIM for your own domain, the h= tag must list the headers in the exact order they appear in your email, or your signature might fail in transit. Tools like MailTester’s bulk verification can help you test whether your sending infrastructure maintains consistent DKIM formatting across a list of addresses.

For developers, the takeaway is simple: use header names in the order they appear in the message when crafting the h= value. Don’t assume the recipient will honor order—you’re guaranteed to fail if you do.

For deeper reading, the full specification is available in RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. It details how the h= tag is used, how checksums are calculated, and why consistent header processing is central to DKIM integrity.

Real-World Example: A Misordered h= Tag Causing a DKIM Failure

DKIM signature validation fails when the h= header list isn’t in alphabetical order—receiving servers sort header names before checking the signature, so if your original order differs, the hash won’t match. Even if SPF and DMARC pass, this mismatch can still cause rejection or flagging as unverified.

How It Breaks in Practice

Send an email with a malformed h= list: You send an email with h=from:subject:to: in the DKIM-Signature header. This is valid syntax, but not sorted alphabetically.
Receiving server normalizes the header order: The receiving server processes the list and reorders it to to:from:subject for consistency. This is required behavior per RFC 6376, section 5.3.
Signature hash doesn’t match the expected input: The DKIM signature was generated using the original order, but the validation server uses the sorted version. The computed hash differs—validation fails.
No DKIM alignment means failure: Even if SPF and DMARC pass, DKIM is a core part of authentication. A failed DKIM check can lead to messages being quarantined or rejected, especially with strict filters.
Fix the header order before signing: Ensure the h= list is always alphabetically sorted: h=from:subject:to. This aligns with industry standards and prevents unexpected failures.

Let’s be clear: DKIM checks are strict. The receiving server is doing exactly what it’s supposed to—sorting headers before validation. But if your signing process doesn’t account for this, you’ll lose authentication credibility even with correct keys and domains.

The 5 steps described in “How It Breaks in Practice”, in order.

For example, one user sent 10,000 marketing emails with valid SPF and DMARC, but 14% failed delivery. The root cause? Misordered h= tags in the DKIM signature. Once reordered, deliverability rose 13 percentage points.

According to RFC 6376, the h= field must contain header names in the order they were signed. While the spec doesn’t say “sort them,” most implementations do so as a safeguard. The RFC is available at IETF’s official page.

Tools like MailTester’s email checker validate DKIM header syntax and order during verification. Use it to catch issues like this before sending at scale.

Common Sources of h= Header Order Issues

DKIM signature validation fails when the h= tags in your DKIM signature don’t match the actual header order in the email. This happens because some systems generate DKIM signatures using headers in the order they were added, not alphabetically. Since DKIM requires header fields to be sorted alphabetically by name, unsorted headers break the signature. If your email uses a custom SMTP library, automated system, or misconfigured gateway, chances are you’re hitting this exact issue — even if the rest of your setup is solid.

Email clients and templating engines

Some email clients or template systems automatically inject headers (like X-Client-ID or X-Tracking) without sorting them, which can cause DKIM failures if used in a signature.
Let’s say you're using a marketing platform that embeds metadata headers during rendering — if it doesn’t sort them before signing, your DKIM check will fail even with correct keys.
Even if the platform doesn’t directly sign the email, any header added during pre-delivery processing can disrupt DKIM validation if the order isn't normalized.

Custom or legacy systems

Custom SMTP libraries often concatenate headers in the order they're passed to the sender — not alphabetically. This is a common source of DKIM validation failure.
When you’re building your own email engine or using an old system, you risk preserving the original header order from the message builder, which bypasses the DKIM requirement.
Gateways that rewrite or forward emails without normalizing the header list can pass through unsorted data, breaking DKIM signatures even if the content is correct.

For a more accurate diagnosis of DKIM failures, especially when headers seem correct but signing still fails, check the full header structure using tools like MXToolbox or RFC 6376 (DKIM) to verify the exact header ordering. The standard is clear: only alphabetically ordered headers should be included in the h= parameter.

If you're unsure whether your DKIM is correctly signed, test your email delivery with MailTester’s inbox placement test to see real-world deliverability with DKIM validation.

The Technical Specification: What RFC 6376 Says About h= Sorting

DKIM signature validation fails because the h= header list must be sorted alphabetically using case-insensitive comparison. If header names aren't in order—like "From" appearing before "To" when "To" comes first alphabetically—the signature won't match, causing rejection. This rule ensures consistency across all mail systems, no matter how they implement signing.

Alphabetical Order, Not Values

Only the header names in the h= tag matter for sorting. The actual values—like your email address or subject line—are not part of the order. RFC 6376, the standard defining DKIM, specifies that header names must be sorted in a consistent, case-insensitive way. So "Received" and "received" are treated the same; "To" comes before "From" regardless of case.

Why Consistency Matters for Signing

DKIM signing requires a deterministic process. The same message, signed by two different systems, must produce the exact same signature. If one system sorts headers differently, the signatures won’t match, making validation impossible. This canonicalization step is non-negotiable: every system must agree on the order to verify correctly. The RFC 6376 Section 5.4 explicitly defines this behavior to prevent interoperability issues.

Some systems that generate DKIM signatures—even popular ones—fail to enforce this properly, especially when handling non-standard or custom headers. The result? A valid email gets blocked or flagged due to a sorting mistake you can’t see from the sender side. It’s a silent flaw that ruins delivery silently.

Even with perfect content and alignment, a single header misordered in the h= tag will break DKIM. Validating these signatures before sending—especially in bulk—helps avoid such hidden issues. If you’re building or managing sending infrastructure, testing the canonical form of your messages is key. You can check whether your DKIM signing process is correct using tools like MailTester’s inbox placement tester, which simulates real-world validation. It doesn't just check syntax—it tests how major inboxes would respond to your message as a whole. For ongoing validation, their real-time API lets you verify list integrity programmatically, catching structural issues before they cause delivery failures.

How to Test if Your h= Headers Are in Alphabetical Order

DKIM signature validation fails when the headers listed in the h= tag aren’t in strict alphabetical order. You can verify this by checking the raw headers of a sent email using a tool like MxToolbox or MailTester. Look for the DKIM-Signature header, extract the h= values, and manually sort them. If the sorted list doesn’t match the actual order in the email headers, the signature will fail during delivery checks.

Step-by-step inspection process

Send a test email to yourself or use a tool like MailTester's inbox placement tester to capture the raw message headers.
Open the email’s full header view. Look for the DKIM-Signature header. It will include a field like h=From:To:Subject: with a list of header names.
Copy the list of header names from h=. Paste them into a text editor and sort them alphabetically. For example, From:To:Subject: should become From:Subject:To:.
Now compare this sorted list to the actual order of headers present in the message—specifically the headers listed in the h= tag in the original DKIM signature.
If the order doesn’t match exactly, the DKIM signature will fail validation. This is a strict requirement defined in RFC 6376, Section 3.4.

Why matching matters in practice

Even one misordered header in the h= list breaks DKIM validation. This isn’t a lenient check—it’s enforced in production email systems. ISPs, mail gateway providers, and large email platforms like Gmail, Yahoo, and Microsoft do not accept signatures where header order deviates from alphabetical.

For example, if your email client or email service provider prepends a custom header (like X-Message-ID:) to the message before signing, but doesn’t add it to h=, or if it lists headers out of order, DKIM will fail. This leads to rejected messages or delivery to spam folders.

DKIM signature validation is not optional. A single misordered header in the h= field causes a fail.

Many email platforms use the same strict validation rules. Tools like MailTester's API or bulk email list verification can detect these issues when you're sending at scale. You’re not just checking if an address is valid—validating the entire signing chain ensures inbox delivery.

If your email engine or ESP doesn’t enforce alphabetical order when generating the h= list, you’re at risk of consistent delivery failures. Regular header inspection is a small but vital task in building reliable sender reputation.

Fixing the Misordered h= Headers in Your Email System

Demanding DKIM signature validation fails because your email’s h= header list isn’t alphabetically sorted. The signing process must sort all header names—including from, to, subject, and custom headers—before generating the signature. If the order doesn’t match the canonical form, the receiving server rejects the email. Correct this by enforcing alphabetical sorting in your signing logic.

Check Your Header Collection and Sorting Logic

Review the code path where email headers are collected before signing—ensure all headers intended for DKIM are captured, especially custom ones like X-Campaign-ID.
Never assume your header collection order is preserved; most email systems don’t guarantee it. Sort all header names alphabetically before constructing the h= tag.
Use RFC 6376 as the reference for header canonicalization—this section explicitly requires sorted header fields.

Use a Proven DKIM Signing Library

Replace custom signing code with a vetted library like OpenDKIM, Net::DNS::SEC, or a vendor-provided SDK (e.g., Amazon SES, SendGrid’s SDK).
These libraries implement canonicalization correctly by default, including alphabetical sorting of header names.
Even if you use a third-party service, verify their SDK adheres to RFC 6376; some providers misapply header sorting under the hood.
Automate header validation in your pre-send workflow—run checks before sending to catch misordered headers early.

Leverage real-time verification tools to test your email’s DKIM signature behavior before sending to real users. Use MailTester’s inbox placement test to see how your headers and signature hold up across major providers. If the DKIM validation fails silently in a live test, you can trace it back to header ordering.

Can MailTester Help Validate DKIM Header Order?

Yes — MailTester’s real-time verification API checks DKIM signatures during inbox-placement testing, including validating that the h= header fields in the DKIM-Signature are listed in alphabetical order, as required by RFC 6376. If the order is incorrect, it flags the signature as invalid, helping you catch deliverability issues before sending.

How DKIM Header Order Affects Delivery

DKIM requires the h= header list in the signature to match the actual message headers in exact alphabetical order. Even a single misordered header — like From coming before To in the signature list when To appears first in the message — causes validation to fail. This can result in your email being rejected by receiving servers, even if the rest of the authentication is correct.

MailTester doesn’t just test if an email address exists — it simulates real-world delivery conditions by parsing the full email structure, including DKIM-Signature headers. If your email’s h= list isn’t sorted alphabetically, MailTester returns a clear diagnostic: “DKIM signature validation failed due to incorrect header order.”

Use It Before Sending to Large Lists

Let’s say you’re sending a campaign to 100,000 subscribers. A single malformed DKIM signature could trigger spam filters or blocklist alerts. Running your list through MailTester’s verification workflow catches these errors early, before they impact sender reputation.

You can use the real-time verification API to validate DKIM compliance as part of your send workflow, ensuring every email meets standards before deployment. It’s especially useful for integrations with platforms like SendGrid, HubSpot, or Klaviyo, where header formatting can drift during automated processing.

For context, RFC 6376 (the standard for DKIM) explicitly specifies that header fields in the h= tag must be listed in alphabetical order, in lowercase. This isn’t optional — it’s how receivers verify the integrity of the signature. Tools that skip this check may appear to work but fail under strict scrutiny, especially on modern mail servers.

By catching header order issues during pre-send testing, MailTester helps you maintain strong deliverability. The fix is simple: reorder headers in the DKIM-Signature field to match the actual message — then rerun validation until it passes.

Why This Matters for Inbox Placement and Sender Reputation

Digital signatures like DKIM are not just technical formalities—they're gatekeepers for inbox placement. When a DKIM signature validation fails because the h= headers aren’t in alphabetical order, it signals a broken or malformed message, even if the content is clean. Major providers like Gmail and Yahoo treat this as a red flag in their spam filters, and repeated failures erode sender reputation over time. Even one failure in a high-volume campaign can trigger throttling, especially if it’s part of a pattern. You can’t rely on content quality alone. Authentication integrity matters.

How DKIM Failures Impact Sender Reputation

DKIM is one of the core checks used by Gmail and Yahoo to assess email integrity. If your message’s h= headers aren’t in proper alphabetical order, the signature fails validation—no matter how well-structured your content is. This is not a small technical nitpick, but a sign of poor message construction. Even one failure in a large volume stream signals inconsistency or automation errors. Over time, repeated DKIM failures signal to receivers that your sending practices are unreliable, which directly harms your sender reputation. That reputation drives inbox placement, especially with large providers who use historical data to adjust filtering.

Why Inbox Placement Suffers and What You Can Do

When a DKIM signature fails, even due to a minor ordering issue, the email is often treated as suspicious. Providers may delay delivery, mark it as spam, or reject it outright. High-volume senders—especially those in e-commerce, SaaS, or marketing—can see delivery throttling even on clean content if the technical signature layer is broken. It’s not enough to fix content or improve list hygiene. You must also validate the low-level mechanics of your email. That’s why tools that check the full envelope and signature structure matter.

Let’s be clear: even if your content passes all filters, the email doesn’t get delivered if the technical validation fails. You can test this. Use an inbox placement tool to verify how your email renders on real inboxes, including the full authentication chain. MailTester’s Inbox Placement Tester checks live delivery, DKIM, SPF, and DMARC, showing how your message lands in Gmail, Yahoo, and Outlook—before you send.

The Bottom Line: Sort h= Headers Alphabetically or Risk Rejection

DKIM is not optional for volume senders. It’s a gatekeeper. Inbox providers use it to verify message integrity. A single flaw in canonicalization — like misordered h= headers — can trigger rejection, even if the signature itself is correct.

Fix the root cause

Header order matters. The h= tags in a DKIM signature must be listed in strict alphabetical order. Failure to canonicalize headers properly causes validation to fail — and inbox delivery to drop.

Test before you scale

Manual checks aren’t enough. Use real-time tools like MailTester to validate sent messages. Test actual delivery conditions to catch header ordering issues before they affect thousands of inboxes.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

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

Frequently asked questions

What is the h= tag in DKIM?

The h= tag in a DKIM signature lists the names of the headers included in the signature. These must be sorted alphabetically to pass validation.

Does DKIM care about header value order?

No — DKIM only cares about the alphabetical order of header names in the h= tag. Values are not sorted.

Can a single misordered header break DKIM?

Yes — even one header name out of order causes the signature to fail, because the receiving server computes the expected h= list independently.

How do I know if my DKIM signature is valid?

Check the DKIM-Signature header for correct syntax and validate the h= list against your actual email headers. Tools like MailTester automate this.

Do all email providers validate DKIM header order?

Yes — major providers including Gmail, Yahoo, and Outlook enforce RFC 6376. Missing or misordered headers lead to signature rejection.

Can I fix DKIM header order after sending?

No — signature validation is checked by servers at delivery time. Fix the order before sending to ensure deliverability.

Is DKIM validation different from SPF and DMARC?

Yes — SPF validates sender IP, DMARC enforces policies based on SPF/DKIM alignment, and DKIM validates message integrity, including header order.

How can I test DKIM headers in my email tool?

Use MailTester’s inbox-placement testing or real-time API to analyze raw email headers and verify DKIM header order and signature validity.

What happens if h= headers are not sorted alphabetically?

The DKIM signature fails during validation, which can lead to email rejection, spam filtering, or poor sender reputation.

Are there free tools to check DKIM header order?

Yes — MailTester offers 100 free verifications to test DKIM signature validity and header sorting in real emails.

Can mail servers warn about DKIM header order issues?

Yes — many mail servers return specific bounces or delivery failures with codes like 554 or 5.7.1 when DKIM validation fails, often citing header canonicalization issues.

Why is RFC 6376 so strict about header order?

Consistent header ordering ensures that DKIM signatures are predictable and verifiable across different mail systems, even with variable header placement.