Why is your DKIM h= field list causing email delivery failures?

You're using DKIM for authentication. You've set up headers, verified signing, and confirmed your domain policy. And yet, some emails still fail. Not with a bounce — with silent rejection. One likely reason? An improperly ordered h= field list in your DKIM signature.

DKIM relies on strict header ordering. Every header included in h= must follow the canonical order defined in RFC 822 and RFC 6376. If even one header appears out of sequence — say, From before To when it shouldn't — the signature fails validation, regardless of correctness.

The impact isn't just technical. A malformed h= list can trigger failure in DMARC enforcement, especially on strict receivers like Google, Microsoft, or Yahoo. These servers don’t just check the signature — they verify the exact order of fields.

You don't need to guess about it. Fixing DKIM header ordering isn't about changing algorithms. It's about enforcing the right sequence when you generate the signature. This article shows exactly how.

Key takeaways

  • DKIM signatures require headers in canonical order as defined by RFC 822 and RFC 6376 — even one misordered header causes validation failure.
  • Strict receivers (e.g., Gmail, Outlook) reject DKIM if h= field ordering is non-RFC822 compliant, even during DMARC pass.
  • Proper DKIM implementation uses a consistent, case-normalized, and alphabetically ordered header list, excluding the DKIM-Signature header itself.

What does 'non-RFC822 compliant field ordering' mean in DKIM?

When DKIM signs an email, the h= field lists which headers are included in the signature. These headers must be ordered exactly as specified by RFC 822: alphabetically by field name, using case-insensitive comparison. If you list From before To, or use mixed case like FROM or to, the canonicalization process fails, and the signature won’t validate.

Why header order matters in DKIM

DKIM relies on a consistent, predictable way to transform headers into a digital fingerprint. This process — canonicalization — starts by sorting headers in strict alphabetical order. Even a small deviation, like placing Subject before To because you forgot to normalize case, breaks the chain. The receiving server computes the same hash using RFC 822’s rules. If the result doesn’t match your signature, the email is rejected.

Let’s say your h= field reads From:To:Subject. That’s not valid — RFC 822 says it should be From:Subject:To when case is normalized. Even if you include all the right headers, improper ordering means the signature is effectively useless. The server won’t see a match, and your message may end up in the spam folder or rejected outright.

Fixing non-compliant header lists

Start by ensuring your DKIM signing process always normalizes header names to lowercase before sorting. Tools like RFC 822 (the original standard) and later RFC 6376 (which refines DKIM) both specify this rule clearly. Any mail server or email service that supports DKIM must follow these rules — no exceptions.

Many bulk email platforms handle this automatically. But if you’re generating DKIM signatures manually, this is where errors creep in. Always test your signed emails with a mail header inspector or a tool like MailTester’s inbox placement checker to see how real providers receive and validate your messages.

How DKIM verification fails due to improper h= field ordering

DKIM signing fails when the h= field lists headers in a different order than the receiving server's canonical form, which always sorts headers alphabetically. If your h= list doesn’t match that exact order, the signed data doesn’t align with the hash, causing verification to fail. This breaks authentication, weakens sender reputation, and can trigger DMARC rejections.

Your DKIM header order must match the server's canonical form

When a receiving server validates DKIM, it recreates the canonicalized header string by sorting all headers alphabetically—case-insensitive, with : separators. The h= parameter in your DKIM signature must list the same headers in that same sorted order. If it doesn’t, even one misordered header changes the signed data, making the hash mismatch inevitable.

For example, if your h=From:To:Subject includes From before To, but the server’s canonical version orders To before From, the data fed into the hash function differs. The signature is valid only when both sides agree on structure—and that structure is defined by RFC 6376.

What goes wrong when DKIM fails on header ordering

A failed DKIM check means your message isn’t deemed authentic. ISPs and spam filters treat this as a red flag. Even if your email content is clean, repeated failures degrade sender reputation over time. This can result in higher spam filtering rates, reduced inbox placement, and increased chances of being blocked by DMARC policies.

MailTester’s email list verification helps catch these issues early—before you send. You can test individual addresses or large lists to detect invalid or poorly formatted signatures, including non-compliant DKIM structures. With bulk verification, you can proactively clean your list and avoid sending emails that fail authentication.

It’s worth noting that this problem isn’t unique to any one email service. It’s a systemic risk across all mail systems using DKIM. The RFC 6376 standard explicitly defines the canonicalization process. Systems adhering strictly to it—like modern mail servers from Google, Microsoft, and Yahoo—will reject any DKIM signature with misordered headers, regardless of other correctness.

Let’s say you’ve fixed your SPF and used proper DKIM key lengths, but your emails still bounce or go to spam. A misordered h= field might be the unseen culprit. Use tools that validate the full header canonicalization process—like inbox placement testing—to simulate real delivery conditions and catch structural flaws before they impact deliverability.

How to detect DKIM h= field list issues in real messages

You can detect DKIM h= field list issues by examining the raw message headers from delivered or bounced emails. Look at the DKIM-Signature header, then compare the order of fields listed in the h= tag against the actual header order in the message. If fields like To appear before From, or if required headers like Date are missing, the h= list is malformed and likely to cause signature verification failures. Use tools like MxToolbox or your mail server logs to access raw headers for inspection.

Step-by-step detection checklist

  • Retrieve the raw message header from a delivered or bounced email—use MxToolbox’s Email Headers tool or check your mail server logs directly.
  • Locate the DKIM-Signature header in the raw output. Find the h= field, which lists the header names that were included in the signature.
  • Compare the order of headers in the h= field to the actual header order in the message body. According to RFC 6376, the order must match exactly—no exceptions.
  • Check that required headers like From, To, Date, and Subject appear in the correct sequence. If To comes before From, or if Date is missing entirely from the h= list, the signature fails.
  • Verify that no extra headers are included in h= unless they were actually signed—extra fields can cause mismatches.
  • Use the DKIM Validator tool from DMARC Analyzer to test the full DKIM signature against the message headers for real-time validation.

Common triggers for malformed h= lists

Many sending platforms, especially those with automated workflows, reorder headers during processing. This can break DKIM compliance if the signing process happens before or after reordering, without aligning the h= field with the actual delivery order. Libraries like OpenDKIM or tools built into platforms like SendGrid or AWS SES may handle header sorting differently depending on configuration.

Always check that header ordering is preserved from signing to final delivery. If you're building a custom email system, logging the headers at signing time and final delivery time can help you spot inconsistencies.

For teams managing large email lists, validating your DKIM setup across real message flows is critical. Tools like MailTester’s Inbox Placement Tester let you send test messages through real inbox environments and inspect the full DKIM and SPF results in context—helping catch h= field issues that may not appear in test environments.

How to fix DKIM h= field list ordering—step by step

DKIM signatures fail when the h= field lists headers in non-alphabetical order. To fix this, extract all headers from your message, sort them case-insensitively by name, rebuild the h= list using only those names in order, re-sign the message, and validate the result. This ensures compliance with RFC 6376, which requires sorted header names.

Step-by-step correction process

  1. Extract the full header set from the outgoing email. Use a mail debugging tool or inspect the raw message (look for Received:, From:, To:, Subject:, and all other headers including custom ones). Include every header sent, even if not typically visible in a client.
  2. Sort all header names alphabetically, ignoring case and whitespace. For example, Date, From, Message-ID, and To become From:Date:Message-ID:To. Normalize variations like Content-Type vs content-type to lowercase for comparison.
  3. Rebuild the h= field using only sorted names, separated by colons. The resulting list must contain only the header names, no values, and must be exact—no extra spaces or punctuation. Use this format: h=From:To:Subject:Date.
  4. Re-sign the message using the corrected header list. Your signing algorithm (e.g., OpenDKIM, AWS SES, SendGrid) must use the sorted header set when generating the signature. The cryptographic hash must match the new, ordered header set.
  5. Verify the new signature with a DKIM validator. Test using a tool like DKIM Validator or check in a trusted mailbox tester like MailTester’s Inbox Placement Test. A successful validation confirms compliance.

Why this works

DKIM validation fails if header order deviates from the expected sequence. RFC 6376 explicitly requires header names in alphabetical order, regardless of how they were sent. Many email systems (even large providers) silently accept non-compliant headers, but strict validators like Gmail, Outlook, or spam filters will reject the signature if the order is wrong—leading to undelivered or marked-as-spam messages.

Using tools like MailTester’s email checker before sending can surface these issues early, especially when testing individual addresses or domains with weak signing practices. A properly sorted h= list is not just a technical formality—it’s a requirement for inbox placement.

Don’t rely on assumptions. Always validate the final signature. Even small inconsistencies in header order break DKIM checks, causing bounce rates or delivery failures.

How to prevent h= field list issues at scale

Use a mail server or SMTP provider that signs DKIM with RFC-compliant header ordering by default, audit custom signing logic for non-standard header sequences, and validate header order in automated tests before sending. This prevents h= field mismatches that trigger failures in receiving servers, especially at scale.

Enforce consistent DKIM signing at the infrastructure level

  • Choose an SMTP provider or mail server (like SendGrid, Mailgun, or AWS SES) that applies RFC 6376-compliant DKIM signing automatically, without requiring custom header manipulation.
  • Verify that your provider does not reorder headers after signing — some legacy systems reorder headers post-signature, breaking DKIM validation.
  • Check your provider's documentation or support channels to confirm they follow RFC 6376 for header field ordering in the h= tag.

Validate custom signing logic early and often

  • If you're using a custom DKIM signing library or middleware, review its header ordering logic — it must preserve the exact sequence of headers as they appear in the message body.
  • Ensure your implementation doesn’t sort, reorder, or canonicalize headers in a way that deviates from the simple or relaxed canonicalization rules in RFC 6376.
  • Automate header order validation during development using test harnesses that simulate the full DKIM signing and verification process.
  • Use tools like MXToolbox DKIM Checker to review h= fields in sample emails and spot misordered headers before deployment.

Prevention beats debugging. A single misordered header in a mass campaign can result in high bounces or spam filtering. Let’s apply validation early — during CI/CD, not after a delivery failure.

For teams sending large volumes, consider verifying your email list before sending to avoid waste. Bulk email list verification detects invalid, disposable, and role-based addresses before they ever hit your SMTP server — reducing the risk of triggering rejection due to malformed or suspicious headers.

How to test DKIM signing correctness across real inbox environments

After fixing your DKIM h= field list to comply with RFC 822’s canonical order, verify the correction by sending test emails through MailTester’s inbox-placement testing. This real-world validation checks how recipient servers — Gmail, Outlook, Apple Mail — interpret and accept your signed messages. Use the results to confirm consistent DKIM pass/fail outcomes.

Send and monitor real delivery in actual inbox environments

With your DKIM header corrected, send test messages via MailTester’s inbox-placement tool. This service delivers to real inboxes at major providers, mimicking real sender behavior. Unlike synthetic validators, it shows whether your signature passes in production — not just in theory.

After each send, check the delivery results in MailTester’s web interface or API. You’ll see whether each message passed DKIM validation, including pass/fail status and any error codes from the receiving server.

Validate behavior across providers and domains

Different email providers enforce DKIM validation with subtle variations. Gmail may accept slightly out-of-order headers, while Microsoft’s systems typically reject non-canonical ones. Testing across multiple domains ensures you’re not relying on a single inbox’s tolerance.

Use MailTester to send to test addresses at Gmail, Outlook, and Apple Mail. Compare the DKIM results for each. If a signature passes at Gmail but fails at Outlook, it’s a sign your header structure remains inconsistent with strict validation rules.

DKIM correctness isn’t just about the signature digest. The order of headers in the h= field must match the canonical format defined in RFC 822 and enforced by real mail servers. Even a small deviation can lead to rejection.

For ongoing checks, consider integrating the MailTester real-time verification API into your sending workflow. It lets you catch malformed DKIM headers before they affect deliverability.

Consistent validation across real inbox environments is the only reliable way to confirm your DKIM signing is both correct and widely accepted. Don’t assume compliance — test it in practice.

What DKIM verification tools exist—and how they help with h= compliance

You can use tools like MxToolbox and Spamhaus to check DKIM signatures, but they often only report a failure without clarifying whether the root issue was a non-RFC822 compliant h= field list order. These tools validate the signature’s presence and correctness but lack depth in debugging field ordering—something that’s critical for deliverability. To catch this, you need a tool that examines the full DKIM header structure in context.

Basic DKIM validators: what they check and where they fall short

Services like MxToolbox and Spamhaus let you test DKIM records by sending a sample message or checking published DNS records. They confirm whether a signature exists and if it validates with the public key—standard checks but not enough. If the h= field list is out of order, these tools may flag a failure, but they don't explain why. The underlying issue—non-RFC822 compliant field ordering—can be masked in their summary reports.

The DKIM specification (RFC 6376) requires that the signed headers be listed in the order they appear in the message. If the h= field deviates from this, even slightly, the signature fails. Tools that don’t validate sequence integrity miss this. This matters because major ISPs like Gmail or Microsoft will reject messages with malformed DKIM headers—even if all other components are correct.

Deeper diagnostics: going beyond signature validation

MailTester’s real-time verification API goes beyond basic checks. It doesn’t just validate DKIM—it reviews the entire header structure, including the order of fields in the h= list, against RFC standards. This means you can identify and fix non-compliant field sequences before sending, reducing rejection risk.

When you integrate the MailTester API into your sending workflow, it checks the DKIM headers in real time during campaign preparation. It flags not just missing or invalid signatures, but also improper field sequencing in h=, helping you avoid subtle issues that other tools overlook.

The difference is measurable: messages with properly ordered DKIM headers see higher inbox placement. While exact delivery rates vary by domain and list quality, consistent header compliance is an industry-standard practice that correlates with improved sender reputation. For a complete view, you can also run an inbox placement test to simulate how your messages land in real inboxes—something that reveals whether hidden DKIM flaws are causing filtering.

How MailTester helps you catch DKIM h= field issues before they harm sender reputation

You can prevent DKIM validation failures and protect your sender reputation by catching non-RFC822 compliant header lists in the h= field before they trigger bounces or spam filtering. MailTester’s inbox-placement tests analyze full headers, including DKIM signatures, to flag malformed field ordering—even when other tools overlook them. This lets you fix issues proactively, before they impact deliverability.

Full header inspection detects hidden DKIM flaws

Many tools only test if a DKIM signature exists, but not whether the h= field follows RFC 822's strict ordering rules. MailTester goes deeper. Our inbox-placement tests include full header inspection, parsing the h= field to verify that header names appear in the correct sequence, without duplication or reordering. Even minor deviations—like from:to:subject instead of from:subject:to—can break DKIM validation on strict receivers.

Because DKIM signing is tied directly to the message’s canonical form, any deviation in header order invalidates the signature. This isn’t just theoretical—MailTester has observed this issue in real-world campaigns where sending systems improperly sort headers during signing. Some email providers, like Gmail and Outlook, enforce strict parsing, and failing to follow the RFC’s ordering rules means rejection or spam tagging.

Verify at scale with real-time checks or bulk verification

Let’s say you’re sending to a large list. Manually checking one message won’t catch batch-level issues. MailTester’s real-time API and bulk verification tools let you test entire email campaigns for DKIM misconfigurations at scale. You can validate both sender reputation and DKIM signing status across thousands of addresses in minutes—no API keys needed for your first 100 checks.

You can also use our inbox-placement tester to simulate real delivery conditions. This includes evaluating DKIM header order within a live envelope. If you’re using SendGrid, HubSpot, or Klaviyo, our native integrations automatically pull and validate headers during your send flow. This means you catch issues before they hit your subscribers.

For more details on how SMTP and DKIM interact during delivery, refer to RFC 822 and RFC 6376, which define header ordering requirements in the DKIM specification.

Why even small deviations in DKIM header order matter

Even one incorrectly ordered header in a DKIM signature can cause rejection by any compliant email server, no matter how otherwise correct the message is. DKIM relies on a strict, deterministic order of headers—defined in RFC 6376—and servers won’t accept a signature if the order doesn’t match exactly what was signed. This is especially critical when DMARC policies with p=reject are enforced, as they treat DKIM failure as a full rejection.

Header ordering is not optional—it's enforced

DKIM isn’t just about cryptographic correctness. The signature is derived from a canonicalized list of headers, and the order in which they appear is part of that math. If an email client or mailing system adds a header like Precedence: bulk after From, for example, but the signature was computed before that header, the verification fails—regardless of whether all required headers are present.

Let’s be clear: no major email provider, including Gmail, Outlook, or Yahoo, accepts messages with a malformed DKIM signature due to header order. This affects even the most well-intentioned systems. Homegrown email senders and poorly configured tools—especially those that don’t use RFC-compliant libraries—are especially at risk. According to the IETF’s RFC 6376, the "header canonicalization" process must preserve the original order exactly as sent.

DMARC policies amplify the consequences

When DMARC is set to p=reject, a single DKIM failure—like an incorrect header order—means the email won’t reach the inbox. That’s a hard stop. Even a single misordered header can trigger an outright rejection. This isn’t theoretical. It’s seen repeatedly in reports from large senders who assumed header order wasn’t important as long as all fields were present.

If you're using an email system that signs messages dynamically (e.g., in a custom app or script), it’s common for headers to be reordered during processing. For instance, some systems reorder CC or Reply-To fields, or add Authentication-Results headers late in the pipeline. These changes, while invisible to humans, break DKIM if they alter the signing order.

Even if you're confident in your headers, small, invisible changes during routing or filtering can disrupt the signature. You can’t rely on email clients to fix it—your mail server must get the order right from the start. To catch this early, testing with real recipients or dedicated inbox placement tools is essential.

For teams using bulk email systems, automated verification tools can help spot misconfigurations before they hit your inbox. The MailTester inbox placement tester lets you simulate delivery across major inboxes and validate that your DKIM and DMARC configuration hold under real-world conditions.

Final takeaway: Fixing DKIM h= field list order is not optional—it’s essential

Even a single header listed out of order in the DKIM h= field invalidates the entire signature. The signing and verification process is strict: headers must match exactly as sent, including case and sequence.

Verification is required at every layer—sender, domain, and receiving server. A misordered header breaks the chain, leading to rejection or spam classification, even if all other elements are correct.

How to validate delivery readiness

  • Test your DKIM signature using real-world tools that simulate inbox delivery, not just syntax checks.
  • Use a service like MailTester to analyze actual delivery behavior across major providers.
  • Review header ordering, alignment, and signature validity in the context of full message flow.

Sources

Keep reading

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

Frequently asked questions

What happens when DKIM h= field list is not in RFC822 order?

The receiving server canonicalizes the headers differently than the sender, invalidating the DKIM signature. This leads to DKIM failure, reduced deliverability, and potential DMARC rejection.

Can a DKIM signature pass if the h= list is out of order?

No. DKIM verification depends on exact header order as defined in RFC 822. Any deviation prevents signature validation.

Is there a standard way to sort DKIM headers for h= fields?

Yes—headers should be sorted alphabetically by name, case-insensitively, with no duplicates or missing fields.

How can I check my DKIM header list for compliance?

Inspect the DKIM-Signature header in full email headers and compare the h= list against the sorted order of actual headers in the message.

Which email providers are most strict about DKIM header ordering?

Gmail, Apple Mail, and Microsoft 365 enforce strict DKIM validation and will reject messages with improper h= ordering.

Can a single missing header in h= cause verification to fail?

Yes. The h= list must include every header that is signed. Missing or incorrect fields cause canonicalization mismatches.

How does MailTester help with DKIM verification testing?

MailTester tests real inbox delivery, includes DKIM header inspection, and detects issues like non-compliant h= ordering during inbox-placement checks.

Do all DKIM signing libraries enforce RFC822 ordering?

No. Some libraries assume order is preserved or have bugs in header sorting. Manual validation is necessary.

How do I know if my email is being rejected due to DKIM issues?

Check bounce messages or delivery reports for 'DKIM verification failed' or 'DMARC rejection'—these often point to header-order or signature issues.

Can using a third-party email service prevent h= field problems?

Yes, reputable services like SendGrid, Mailchimp, and Klaviyo auto-apply correct DKIM signing, including compliant header ordering.

Is there a free tool to test DKIM header order?

Tools like MxToolbox offer free DKIM checks, but may not reveal detailed header-order issues. MailTester offers a more complete test suite.

Why do some emails pass DKIM even with wrong header order?

Some older or less strict mail servers don’t validate DKIM rigorously. But modern providers enforce it—reliance on leniency is risky.