What triggers confusion about DKIM's h= tag order?

You sign an email with DKIM, verify the signature passes, but suddenly the email fails in another system. The h= tag lists headers in an order that doesn’t match the message’s actual header sequence — and you’re left wondering why.

This isn’t a bug. It’s how relaxed canonicalization is designed: it allows reordering of headers as long as the header field name and value are preserved. Yet the h= tag still lists headers in a specific, non-linear order — often alphabetical, sometimes based on processing logic — which makes validation inconsistent across tools.

Understanding why the h= tag order diverges from relaxed rules isn’t just academic. It directly impacts whether your DKIM signature is accepted by receiving systems, especially when using multiple verification tools or troubleshooting delivery issues.

Key takeaways

  • Relaxed canonicalization permits header reordering, but the h= tag must list the exact headers used in the signature, regardless of message order.
  • DKIM validators may accept or reject a signature based on h= tag order, even when header values are correct, leading to false positives in validation tools.
  • Implementations vary in how they handle h= order, so consistent behavior across email systems requires strict adherence to the field list in the signature.

How does relaxed canonicalization actually work in DKIM?

Relaxed canonicalization in DKIM allows header fields to be reordered and whitespace normalized while still maintaining signature validity. It converts header names to lowercase, collapses multiple whitespace characters into one, and ensures line breaks are consistently represented as CRLF. This means the original order of headers in the message doesn't need to be preserved during signing.

What relaxed canonicalization actually does

Let’s break it down step by step. When DKIM applies relaxed canonicalization, it first processes each header line by converting the header name to lowercase—so From: becomes from:. Then, it normalizes line endings to CRLF, which ensures consistent formatting across systems.

Next, it trims excess whitespace around header values and folds long lines to prevent formatting issues. Most importantly, it doesn't require header fields to appear in the same order in the signature body as they do in the original message. This flexibility is what makes DKIM robust in real-world environments where email clients and intermediaries may reorder or modify headers during transit.

For example, even if a mail server moves Received: lines to the end of the header block, DKIM with relaxed canonicalization still verifies the signature correctly. This is by design: the standard allows for minor structural changes without breaking authentication.

Why this matters for DKIM verification

Because header order isn't enforced, a DKIM-signed message can be processed by multiple services—like gateways, spam filters, or mailing APIs—without invalidating the signature. But this same flexibility can cause confusion when inspecting signatures, especially if you expect header order to match the original.

The DKIM specification explicitly defines relaxed canonicalization in Section 3.4, noting that it's intended to support the practical realities of email delivery. It’s not a flaw—it’s a feature designed to reduce false negatives during verification.

If your emails are failing DKIM checks because of header reordering, it’s rarely due to a misconfiguration. More often, it's a sign that the signing process wasn’t consistent with relaxed canonicalization rules—like failing to lowercase header names or normalize line breaks.

For developers and mail teams, this means your DKIM implementation must strictly follow relaxed canonicalization rules. If you're troubleshooting verification issues, tools like inbox placement testing or checking individual addresses can help identify whether a problem lies in the signing process or the delivery chain.

Why is the h= tag order not aligned with relaxed canonicalization rules?

The h= tag in a DKIM-Signature header lists the header fields in the exact order they were signed, regardless of relaxed canonicalization’s discarding of header order during content processing. This order is preserved for verification integrity, not content interpretation. Relaxed canonicalization normalizes whitespace and folding, but the h= list remains a strict record of signing order — a checksum, not a processing rule. You’re not supposed to re-order headers when verifying the signature; you verify the signature against the exact header fields and order listed in h=.

It’s a signature contract, not a parser directive

Let’s be clear: relaxed canonicalization applies to the body and header content during hashing. It ignores field order and folds whitespace to standardize the input. But the h= tag is not part of that hash process — it’s a metadata field used to confirm which headers were actually included in the signature. If the signing process listed "From" then "To", the h= tag reflects that, even if the mail server later reorders them.

This discrepancy is intentional. The canonicalization rules strip away formatting noise, but the h= list ensures a verifier can confirm the full set and order of headers that were in the original signature. This prevents attacks where a malicious actor alters an email’s header order in transit but keeps the hash the same, or replaces a header without altering the signature’s content.

Why the confusion exists

Many assume that if relaxed canonicalization ignores ordering, then the h= tag should be irrelevant. But the signature’s integrity depends on both the canonicalized content and the specific headers it was applied to. You can’t just hash any order of headers and claim the signature validates — the verifier checks that the listed headers were signed in that sequence, even if the server later reorders them.

For example, if your server signs the "From", "To", and "Subject" headers in that order, but the signature’s h= field says "Subject", "From", the verifier flags it as invalid. Even if the content hash passes under relaxed canonicalization, the header list mismatch breaks the signature chain.

This is standardized in RFC 6376, which explicitly separates the canonicalization process (which normalizes order) from the h= tag’s role (which preserves signing order for integrity checks). You’re not verifying a processed header list; you’re verifying the exact signing context.

Still, if you're sending mail at scale, even minor DKIM misconfigurations can impact inbox placement. A reliable verification step before sending helps you catch issues like missing or misordered headers — especially in systems with automated email templates. Use bulk verification to scan your mailing list for invalid or misconfigured addresses: check your list’s deliverability and DKIM readiness with MailTester’s real-time tools.

What happens when the h= tag order doesn't match the message's header order?

DKIM doesn’t require the h= tag list to follow the order of headers in the message. The validator checks only that the listed headers are present, correctly canonicalized, and actually signed. As long as all signed headers are included in the h= list—regardless of order—verification passes. The order of headers in h= is irrelevant to compliance.

How DKIM handles header ordering

When a DKIM signature is validated, the key step is confirming that the headers named in the h= tag were both present in the message and processed using the correct canonicalization method—either simple or relaxed. The order in which those headers appear in the h= list does not affect whether they are considered valid inputs.

Let’s say your h= tag lists Subject:From:To but the message header order is To:From:Subject. That’s perfectly fine. The DKIM verifier will still validate the signature if the same set of headers was signed and the body is correctly signed and canonicalized. This is consistent with the relaxed canonicalization rules defined in RFC 6376, section 3.4.1.

What actually breaks DKIM verification isn’t order—it’s absence. If a header that was signed is missing from the h= list, the verifier cannot confirm it was included in the signature computation. This leads to failure, even if the header is present in the actual message.

For example, if you sign To and Subject, but forget to include Subject in the h= list, the validation fails. That’s not because of order—it’s because of omission. The header must be named, regardless of placement in the message or in the h= list.

Why this matters in practice

Most DKIM implementations and email servers don’t enforce header order in h=. They only check for correct inclusion and proper canonicalization. This allows flexibility in how signers structure their headers, which is helpful when using dynamic email tools or frameworks that reorder headers during processing.

For systems like SendGrid, Mailchimp, or HubSpot—commonly integrated via MailTester’s integrations—this behavior is expected. These platforms generate DKIM signatures with header lists that may not reflect raw message order but still pass validation because the correct headers are present and canonicalized.

Understanding this removes confusion when debugging DKIM failures. You’re not looking for order mismatches—you’re checking completeness. If you’re validating DKIM signatures for bulk sending or inbox placement, ensure all headers included in the signature are named in the h= tag. You can test this with tools like inbox placement tests that check both header structure and authentication.

For deeper inspection of raw DKIM signed messages, refer to the official DKIM specification on canonicalization methods. It confirms that header ordering in h= is strictly for identification, not validation.

Can a DKIM signature pass validation with reordered headers in the h= tag?

Yes, a DKIM signature can pass validation even if the headers listed in the h= tag are reordered, as long as the headers were actually present and included in the canonicalized message body. DKIM’s relaxed canonicalization rules ignore header order during validation — only presence and field values matter.

How DKIM handles header order in the h= tag

The h= tag in a DKIM signature specifies which headers should be signed. What it doesn’t do is enforce their order in the message. The signing process records which headers are signed, but the verification process evaluates them based on their canonical form, not their sequence in the original email.

Relaxed canonicalization in DKIM—defined in RFC 6376—allows any order of headers in the h= tag. The verifier first canonicalizes the message, meaning it normalizes whitespace and sorts headers by name before hashing. So even if you list From before To in the h= tag, or vice versa, the result is the same as long as both headers exist in the canonicalized message.

What actually matters for a passing DKIM check

The critical factors are: did the header appear in the email? Was its value properly normalized? Was the hash of the signed content matched? Reordering the h= tag doesn’t affect this — only the presence and values of the headers matter.

Let’s say you sign From: [email protected] and To: [email protected]. If the validator finds those two headers in the canonicalized message (even if listed in a different order than specified in h=), and the hash matches, the signature passes.

For senders, this means you don’t need to worry about maintaining the exact header order in your h= tag — especially when sending through third-party platforms that may reorder headers during processing. What you care about is ensuring the right headers are included and their values aren’t altered.

If you’re validating DKIM signatures at scale — whether in a bulk email campaign or for inbox placement — consistent header inclusion and proper canonicalization matter more than order. Tools like MailTester’s bulk verification can help you catch malformed headers, invalid recipients, or other issues that might indirectly affect DKIM signing reliability.

How can you verify if a DKIM signature’s h= tag is valid?

You can verify a DKIM signature’s h= tag by confirming that every header listed actually appears in the original email’s headers, that those headers were canonicalized using relaxed rules (lowercase, single spaces), and that the signature value matches the hash computed from the canonicalized headers and body. If any of these steps fail, the signature is invalid—even if the key is correct.

Check the h= field against the actual headers

  • Extract the h= tag from the DKIM-Signature header and list each header name in order.
  • Inspect the full, raw email headers and ensure every listed header exists exactly as named—no case variations, no missing fields.
  • For example, if h=from:subject:date, make sure From:, Subject:, and Date: are present and not omitted or altered.

Verify relaxed canonicalization was applied

  • Relaxed canonicalization converts all header names to lowercase and normalizes whitespace between values to a single space.
  • Check that the header values used in the signature computation follow these rules—no extra newlines, no leading/trailing spaces, no multiple spaces between words.
  • Use tools like RFC 6376 to confirm the canonicalization method matches the relaxed mode specified by the signature.
  • Even a single extra space or uppercase letter can break the hash check, making the signature appear invalid even with the correct key.

Confirm the signature value matches the computed hash

  • Rebuild the header and body content using relaxed canonicalization, then compute the HMAC-SHA256 hash using the domain’s public key.
  • Compare the computed hash directly with the signature value in the Signatures field.
  • If they differ, the signature is invalid—either due to incorrect header selection, wrong canonicalization, or a corrupted key.
  • Tools like MXToolbox’s DKIM Validator can help automate checking this step.

Use the MailTester email checker to validate individual email addresses before sending—helping avoid issues like invalid DKIM signatures caused by poorly formed or forged addresses.

Common misconceptions about DKIM h= tag order

The h= tag in DKIM doesn't require any specific order—neither alphabetical nor message order—and reordering headers doesn't invalidate the signature under relaxed canonicalization. Many tools flag this as a failure, but the real problem is often missing fields, malformed syntax, or incorrect header values, not order.

DKIM doesn’t care about header order—really

Let's be clear: the h= tag lists the headers involved in the signature, but the order in which they appear doesn’t matter as long as the headers are present and correctly formatted. Under relaxed canonicalization (which is used by 95% of modern email systems), header order is ignored. This means you can list From, To, Date in any sequence—you won’t break the signature.

This is defined in RFC 6376, section 3.5, which specifies that relaxed canonicalization normalizes whitespace and ignores header order during verification. So if you're seeing a signature rejection due to h= order, check the actual header content first—missing or incorrect CRLF endings, extra spaces, or duplicate headers are far more likely culprits than order.

Why some tools report "failures" you shouldn’t panic over

Some validation tools still flag h= order as an error, but they're using outdated or overly strict logic. These tools often default to strict canonicalization, which isn’t how most servers process DKIM today. If your signature passes with relaxed canonicalization (as it should), there’s no issue.

Even the Internet Society’s RFC 6376 confirms that relaxed canonicalization allows header reordering as long as the values match, which makes the h= list purely a reference list. Think of it like a grocery list: if you buy apples, milk, and bread, the order you write them down doesn’t matter—what matters is that you included them.

If you’re troubleshooting DKIM issues, focus on the header values, signature integrity, and SPF/DKIM alignment—don’t waste time trying to fix header order. Use a tool like MailTester’s email checker to verify whether an address is deliverable and catch issues like missing headers or incorrect syntax early.

How does MailTester help with DKIM and email deliverability issues?

You can catch DKIM configuration problems before they hurt deliverability by testing your email addresses against real mail servers using MailTester’s real-time verification API. It checks for invalid, catch-all, or risky addresses—common signals of misconfigured authentication—and its inbox placement tests surface DKIM issues early with clear, actionable feedback, so you know exactly what’s blocking your emails from reaching inboxes.

Test DKIM in the real-world environment

DKIM validation isn’t just about signing your messages—it’s about whether the receiving server can successfully verify that signature. MailTester’s real-time API simulates actual email delivery by sending test messages through live mail servers, including those from Gmail, Yahoo, and Outlook. This isn’t a theoretical check; it’s a live test that confirms whether your DKIM record is properly formatted, aligned, and trusted in practice.

If your DKIM h= tag list order violates relaxed canonicalization rules—meaning header fields are listed out of order or inconsistently—it can fail verification even if the content is correct. MailTester flags such inconsistencies early, helping you avoid silent delivery failures. You don’t need to guess why an email failed; the tool shows you exactly where the authentication chain broke.

Prevent issues before you send

Before you send to a large list, run it through MailTester’s bulk verification tool to catch invalid or risky addresses that could drag down your sender reputation. Addresses that are catch-all, role-based, or hosted on disposable domains often have misconfigured DKIM or no SPF/DKIM at all. These accounts can be a red flag to inbox providers.

Bulk verification also identifies patterns that hint at authentication instability. For instance, a high rate of catch-all or temporary addresses in your list can signal poor data hygiene, which inbox providers use to assess sender legitimacy. MailTester’s inbox placement test simulates how your message lands in real user inboxes across multiple providers, surfacing DKIM errors or reputation risks you might miss with other tools.

Use the real-time verification API to integrate email validation directly into your send workflow. When a new subscriber signs up, you can validate their address instantly and catch DKIM misconfigurations at the source. This level of proactive testing is not only common in high-volume senders but is an industry-standard practice for maintaining deliverability.

Best practices for managing DKIM signatures reliably

DKIM signature consistency depends on strict header ordering and canonicalization. The h= tag lists headers in the order they appear in the signed message, which can vary under relaxed canonicalization unless you standardize header names (lowercase) and include only stable, relevant fields. Deviations here cause validation failures even when the signature is mathematically valid.

Standardize header handling

  • Always use lowercase for header names when signing (e.g., from, not From). This ensures consistency across mail systems that normalize case.
  • Apply relaxed canonicalization only after normalizing both header names and field values. Refer to RFC 6376, Section 3.4 for the canonicalization process.
  • Verify your signing implementation handles header folds, whitespace, and line ending differences consistently across platforms.

Optimize the h= tag content

  • Include only essential, non-dynamic headers in h=, such as from, to, subject, and date. Omit fields like message-id or return-path unless they are stable and consistently set.
  • Avoid adding per-message fields (e.g., tracking IDs, session tokens) unless you're confident they won't change during delivery. Dynamic values break signature validation across forwarding or rewriting systems.
  • Test DKIM signatures across multiple email clients and relay environments—including mobile apps, corporate gateways, and third-party forwards—using inbox placement tools like MailTester’s inbox placement tester to catch inconsistencies before production sends.
Even with correct cryptographic signatures, inconsistent header ordering or dynamic fields in h= can cause rejection by receivers that enforce strict relaxed canonicalization rules.

When in doubt, validate your DKIM setup using real-world testing. Tools like MailTester’s verification API can help detect malformed or inconsistent signatures during list hygiene checks, especially before large sends.

How do modern email systems handle DKIM validation with relaxed canonicalization?

Modern email providers like Gmail, Outlook, and Apple Mail use relaxed canonicalization, meaning they validate DKIM signatures by reprocessing the headers according to the spec—never by checking the order listed in the h= tag. A correctly signed message with properly canonicalized headers will pass validation regardless of h= sequence, as long as the signed headers are present and correctly formatted.

Relaxed canonicalization is the norm, not the exception

Most major inbox providers now implement relaxed canonicalization as defined in RFC 6376. This means they don’t require the h= tag to match any specific order in the signature. Instead, they extract the signed headers from the message body, canonicalize them using the same rules (including collapsing whitespace), and then verify the signature against the public key in the DNS record.

Let’s say you send an email with DKIM headers like h=From:To:Subject:. Even if the actual header order in the email is Subject:From:To:, the system will still validate it correctly—because it reprocesses the headers as specified, not because it trusts the listed order.

Why h= order doesn’t affect validation

The h= tag’s primary purpose is to clarify which headers were signed, not to enforce an order. The DKIM spec explicitly allows relaxed canonicalization to accommodate differences in how mail servers handle header ordering—common because many systems reorder or collapse whitespace.

For example, Gmail’s documentation notes that header ordering doesn’t impact DKIM verification outcomes when relaxed canonicalization is used. You can verify this behavior using tools like MxToolbox or by examining message source in your inbox. The underlying rule is simple: if you can reproduce the signed header list and match the signature, you pass.

Relaxed canonicalization reduces false positives caused by header reordering during transit. It’s an industry-standard practice that aligns with real-world email delivery patterns.

The bottom line: h= tag order isn’t the issue — it’s what it represents

DKIM’s h= tag list order does not need to match the sequence of headers in the message body. The list specifies which header fields were signed, not their position in the original email.

Canonicalization rules—specifically relaxed or simple—are what determine how headers are processed before signing. The integrity of the signature depends on consistent field inclusion and proper canonicalization, not the order of the h= list.

When testing DKIM signatures, focus on correct field selection and proper canonicalization. Misunderstanding h= as a sequence requirement distracts from actual implementation issues.

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 require headers to be listed in order in the h= tag?

No. The h= tag order does not affect DKIM validation under relaxed canonicalization. Only the presence and content of headers matter.

Can I reorder headers in the h= tag without breaking DKIM?

Yes. As long as all signed headers are present and correctly canonicalized, the order in h= has no impact on verification.

Why do some tools flag h= tag order as invalid?

Some tools misinterpret the spec or have incomplete validators. Correct validators ignore h= order and focus on field content and alignment.

Is relaxed canonicalization mandatory in DKIM?

It’s not required, but it’s the default and most widely used method. Strict mode is rarely used in practice.

What happens if a header listed in h= is missing?

The DKIM signature fails verification. The h= tag must match exactly with the headers included in the canonicalized body.

Can DKIM pass if a header is added to h= but not in the message?

No. Validation requires all fields in h= to be present. Extraneous fields cause failure even if the message itself is valid.

Is DKIM configuration easier with MailTester?

Yes. MailTester’s inbox placement tests and verification API identify issues like missing or mismatched DKIM headers before sending.

How does MailTester help prevent deliverability issues?

It verifies email addresses and checks authentication setup, including SPF, DKIM, and DMARC, reducing bounce rates and improving inbox placement.

Do DKIM h= tags affect sender reputation?

Only indirectly. A failed DKIM check can harm sender reputation. But the h= list order itself has no effect.

What’s the role of the h= tag in DKIM signatures?

It lists the specific header fields that were included in the signature. It’s not a positional reference, but a declaration of coverage.

Can I include 'body' in the h= tag?

No. The h= tag only applies to headers. The body is signed separately via the b= tag and is not part of the h= list.

How can I test my DKIM signature without sending an email?

Use MailTester’s real-time API to validate email addresses and configuration in a live environment without sending to real users.