What is the h= header field in email, and why does it matter?

You send an email. It arrives. But sometimes, it doesn’t — not because the address is wrong, but because the header order messed up a cryptographic signature. Why? Because of the h= field in DKIM.

It’s not a visible header. It’s not in your email client. But it’s one of the most fragile parts of email authentication. If it doesn’t match exactly what’s sent, the signature fails. And that’s how emails get rejected, quarantined, or marked spam — even if they’re perfectly valid.

The h= field defines which headers are included in the DKIM signature’s hash. It’s not optional. It’s not forgiving. If the order or set of headers differs from what’s listed in h=, the receiving server recalculates the hash and finds a mismatch. No exception. No second chance.

Key takeaways

  • The h= field in DKIM specifies exactly which headers are included in the cryptographic hash, and any deviation in header order or selection causes validation to fail.
  • Different email providers use the same DKIM check, but all reject messages where the h= field does not match the actual headers sent, meaning even small changes in email structure can break delivery.
  • Proper DKIM configuration requires strict control over header order, especially in automated systems like bulk email platforms, where headers might be reordered during processing.

How does header field order affect DKIM verification?

DKIM signatures depend on a precise cryptographic hash of specific headers in the email, as defined by the h= tag in the signature. If the order or formatting of those headers changes—even by a single space or line break—during transit, the hash will no longer match, and the signature fails. This is why email systems that reorder or normalize headers, especially during cloud-based routing, often break DKIM verification.

Why header ordering matters in DKIM

DKIM signs a specific set of headers in a specific order. The h= field in the signature tells the verifier exactly which headers to include and in what sequence. Any deviation—reordering, extra spacing, or line break changes—even if it seems minor—alters the hash value. The result? The signature is rejected, regardless of whether the email content or sender is legitimate.

For example, if the From and To headers are reordered or reformatted by a relay service or email gateway, the hash changes. This commonly happens in systems that normalize input for consistency, especially in hosted email platforms or when using third-party delivery services.

Even small actions like email client line wrapping or BCC processing can cause unexpected header reordering. These changes are invisible to humans but fatal to DKIM verification, which treats every byte as meaningful.

Common sources of header field order issues

Automated email systems, especially those using cloud relays or transactional email platforms, often apply header transformations without preserving the original signature context. This includes services that:

  • Reorder headers alphabetically or by function during queue processing
  • Normalize whitespace or line endings
  • Insert or modify headers like Return-Path or DKIM-Signature during delivery routing

This is why DKIM failures often appear when an email passes through multiple relays—each step adds a layer where the header order can be altered, even slightly.

One solution is to ensure the signing domain and service maintain header order integrity through the entire delivery chain. It’s a known best practice to verify the signature’s h= field matches the headers sent in the final message. More detail on how this works can be found in RFC 6376, Section 4.5, which defines DKIM header hashing.

If you're sending campaigns at scale, testing your email's DKIM signature with real inbox placement tools can help catch these issues before they harm sender reputation. You can test how your email appears in actual inboxes with our inbox placement tester, which simulates real-world delivery conditions and flags signature discrepancies early.

Why do email providers reject messages due to h= order issues?

Some email providers like Gmail, Microsoft 365, and Yahoo reject messages when the h= header field order in DKIM signatures doesn't match the original signing order. DKIM requires strict header ordering—any change during transit, even a reordering of field names, breaks the hash verification. This failure means the message is rejected, marked as spam, or treated as unauthenticated, harming sender reputation.

The Role of Header Order in DKIM Validation

DKIM uses a cryptographic signature over a specific set of headers, defined in the h= tag. The order of those headers must remain unchanged from the moment the email is signed to when it's verified. Even a single reordered header—like moving Subject: before Date:—invalidates the signature hash. This isn’t about content; it’s about structural fidelity.

Providers such as Gmail and Yahoo perform strict checks on this order. If the receiver’s DKIM validator computes a different hash than the signed one, the message fails. This isn’t a policy choice—it’s a requirement defined in RFC 6376, the standard governing DKIM. You can find the full specification at IETF’s RFC 6376, which explains precisely how header order impacts signature validation.

Why This Matters for Deliverability

Even if your message body and sender domain are legitimate, a mismatch in header order leads to a DKIM failure. This does not always result in a hard bounce—but it often leads to quarantine, filtering, or reduced inbox placement. Over time, repeated failures damage your sender reputation, especially with providers that monitor alignment and consistency.

Many email platforms don’t warn you about header ordering issues during development. Your email might look correct, send successfully, and pass SPF and DMARC checks—but fail silently in the DKIM validation phase. That’s why verifying the structural integrity of your emails—before sending—is essential. Using tools that test actual delivery behavior, like inbox placement checks, helps surface these silent failures.

MailTester can help identify such issues before they impact your campaign by simulating real-world delivery and flagging structural problems—including header order misalignments—that could lead to authentication failures, even if your domain is properly set up.

Can malformed h= fields be detected during email sending?

Yes — a misconfigured DKIM signature can generate an incorrect or incomplete h= list, which many email providers check before accepting mail. If the h= field lists headers like From: and To:, but one of those headers is missing during transmission, the signature fails validation, and the message is rejected. These mismatches are invisible in most clients but trigger server-level rejection.

How DKIM’s h= field works in practice

When you sign an email with DKIM, you specify which headers should be included in the signature via the h= field. This list must exactly match the headers present when the message is received. If a header listed in h= is missing, altered, or reordered during transit — even subtly — the signature fails. This often happens in automated systems where headers get stripped or reordered by routing intermediaries.

For example, a DKIM signature might include From: and To: in the h= list, but a relay might strip the To: header for privacy reasons. The receiving server checks the h= list against the actual headers and rejects the email if they don't align. This failure doesn’t show up in your inbox or mail client; it’s logged only at the receiving mail server level.

What to do when h= issues cause rejections

Malformed h= lists are a common cause of silent delivery failures. You might see no bounce, but the email never reaches the inbox because the receiving server rejected it due to a DKIM signature mismatch. This is especially prevalent with bulk senders using poorly configured mail servers or third-party tools.

These issues aren’t easily caught in standard email testing. Tools that only check syntax or basic deliverability won’t flag h= misalignment. You need to validate the entire DKIM structure, including the header list, against real-world receiving standards.

Real-time email verification services like MailTester can help catch these issues before they hit the inbox. By testing your emails against actual mailbox provider behavior, you can catch signature flaws early. For instance, inbox placement testing reveals how your message is handled by real providers, including rejection due to improper DKIM header ordering.

The best defense is to validate both the signature and the actual header set during transmission. Use RFC-compliant DKIM tools and test signatures with services that simulate real-world delivery environments. This includes checking that the h= field matches exactly what the server receives — no more, no less.

DKIM is precise by design. A single header mismatch breaks it. Understanding how the h= field works — and how it can fail — is essential for maintaining consistent inbox placement.

How to verify if your email system respects h= field order

Some email providers reject emails when the h= header field order in DKIM signatures doesn’t match the actual header sequence in the message. You can verify this by testing your emails through tools that inspect full message structure—including DKIM, header order, and signing alignment. Real-time inbox-placement testing with a tool that validates DKIM and header order is the only reliable way to catch this issue before it causes delivery failures.

Test your email headers in real inbox conditions

  • Use inbox-placement testing tools that examine full MIME structure, including all headers and DKIM signature alignment. Not all verification tools check this level of detail.
  • MailTester’s inbox-placement tester validates DKIM signature fields like h= against actual header order in real email clients (Gmail, Outlook, Apple Mail), catching mismatches that block delivery.
  • Simulate sending from your domain with a test email and verify the DKIM signature’s h= field matches the exact order of headers sent—especially From:, To:, Date:, Subject:, and Message-ID:.
  • Compare the h= value in the DKIM signature with the actual header sequence using RFC 6376 (DKIM)—the standard specifies that only headers in the canonicalization algorithm order are signed.

Check your email system and infrastructure logs

  • Review your email system’s logging to confirm headers aren’t reordered or stripped during transit—common with poorly configured email gateways or legacy systems.
  • Look for tools like MXToolbox or Spamhaus to test inbound DKIM alignment, though they don’t show header order in real time.
  • Use a real-time verification API to test individual addresses and validate headers during delivery simulation. This helps isolate system-level issues.
  • When debugging, view the raw email content (via View > Source in email clients) and compare it to the DKIM signature’s h= field to verify alignment.

Most delivery issues from DKIM errors stem not from incorrect signatures, but from reordered or extra headers affecting h=. Fixing this requires testing in actual mail environments—not just checking syntax.

Example of how h= field issues appear in practice

When a DKIM signature is generated with a specific header order—say, From:To:Subject—but the email is later reordered by a mail server to To:From:Subject, the hash in the DKIM signature no longer matches. This mismatch causes DKIM validation to fail, even if the content itself hasn’t changed. Email providers notice this inconsistency as a potential sign of tampering or poor handling, which can lead to rejection or increased scrutiny of the sender’s IP.

How header reordering breaks DKIM signatures

DKIM uses a cryptographic hash of specific headers, defined by the h= field in the signature. If the sending system signs From:To:Subject, but the receiving system or an intermediary reorders them—commonly when adding or modifying headers during transit—the hash becomes invalid.

Let’s say you send an email where the From: header comes before To:, as it should. The DKIM signature is computed based on that exact sequence. But if the mail server or a filtering system reorders the headers for internal processing (a behavior documented in RFCs around message normalization), the hash no longer aligns. Even though the actual email body and content remain unchanged, DKIM fails.

The result? Many email providers—especially those with strict security policies—reject the message outright or mark it as suspicious. This is not just about a single failure; repeated DKIM mismatches can harm sender reputation and trigger long-term deliverability issues.

Why this matters even when content is identical

DKIM’s strength lies in integrity, not just content. The signature must cover the exact set of header names and their order at the time of signing. Any deviation—no matter how minor or seemingly benign—breaks the chain of trust.

According to the IETF’s DKIM specification (RFC 6376), header order is part of the signature scope. This means it's not optional. Reordering headers during transit, even for convenience or formatting, can invalidate the signature.

Even if your email reaches the inbox, providers may still flag it for review if DKIM fails. This risk is especially high when using third-party systems like email marketing platforms, transactional email services, or shared hosting providers that might alter header order during delivery.

To prevent this, ensure your sending infrastructure—whether custom or via a service—preserves the original header order throughout transit. Tools like MailTester’s email checker can verify whether an address is valid and well-formed before you send, reducing the risk of configuration issues leading to delivery failure.

Best practices to prevent h= field order issues

Order matters in DKIM: the h= header field must list signed headers in the exact sequence they appear in the email. Even minor reordering during processing — by a proxy, MTA, or email builder — breaks the signature. To stay compliant, lock header order early, validate complete signatures before sending, and test under realistic conditions. Tools that only check syntax miss real-world flaws.

Lock header order at creation time

  • Never reorder headers after they’re generated. Let your email system emit them in final form from the start.
  • Use a consistent, predictable header sequence — especially for From, To, Subject, Date, Message-ID — and keep it unchanged through delivery.
  • Test your output with a real mail server tool like RFC 6376 or OpenDKIM to verify that the signed headers exactly match the transmitted ones.

Validate DKIM signatures end-to-end

  • Confirm the h= field includes only the headers you intended to sign and in correct order. Even a single extra or missing header breaks validation.
  • Test your full DKIM signature — not just syntax — using tools that simulate real-world delivery. Basic syntax validators won’t catch reordering issues.
  • Use email deliverability testers like MailTester’s inbox placement test to see how your emails behave when sent through major providers like Gmail, Yahoo, and Outlook.

Let’s be clear: if your system reorders headers during transit — even accidentally — the DKIM signature fails. It’s not a minor issue. It’s a hard rejection. This isn’t about optimization. It’s about compliance. Some providers reject mail outright if h= doesn’t match, regardless of content or reputation.

“Header order affects DKIM validation. Even small deviations can cause rejection.” — DMARCian, on DKIM header order.

Prevention starts with awareness. Use tools that test header integrity under live conditions. A bulk verification tool like MailTester’s email list verifier can help catch bad domains and inconsistent signing before you send.

Real-time verification catches h= order issues early

MailTester’s real-time verification API checks DKIM signature alignment—including the exact order of headers listed in the h= field—during inbox placement testing. If the headers in your sent message don’t match the order specified in the DKIM signature, the email will fail validation and may be rejected by strict providers like Gmail or Microsoft. This catches configuration flaws before you send to large lists, reducing bounces and protecting your sender reputation.

How h= field order affects deliverability

DKIM uses the h= field to define which headers are included in the signature. Email providers expect this list to match exactly what’s sent. If headers are reordered—say, due to an email client or integration altering the header order—the signature fails validation. This isn’t just a minor glitch; it can lead to outright rejection or placement in spam folders.

Let’s say you’re using a marketing platform that adds tracking parameters after your initial headers. Even if the headers are correct in content, their order changes. The DKIM signature, which expects a specific order, no longer aligns. That mismatch can trigger rejection, especially on providers enforcing strict authentication checks.

Why testing during inbox placement matters

MailTester’s inbox placement tests simulate real delivery to major providers. During these tests, we validate that the h= field reflects the exact header order sent, not just the content. We flag mismatches so you can correct them—before sending to 10,000 subscribers.

For example, if your email system prepends a custom header like X-Message-ID after the From line, but your DKIM signature lists it earlier (e.g., in h=From:To:Subject:X-Message-ID), the signature will fail. MailTester detects this in real time and gives you a clear reason: "Header order in h= does not match sent message."

It’s not just about compliance. It’s about preserving your deliverability. A single misaligned DKIM signature can flag your sending domain as inconsistent, triggering filters. The fix is simple—adjust your outbound process to preserve header order—or use tools like MailTester’s API to catch this before it happens.

Use our real-time verification API to test individual addresses or integrate it into your workflow. It’s a reliable way to catch h= mismatches early—before they cost you deliverability.

You’re not alone if your emails are getting silently blocked or marked as spam due to DKIM header field order issues. The h= tag in DKIM signatures must exactly match the order of headers in the final message body—any change, even by a routing server, breaks validation. MailTester catches these mismatches before you send, using real inbox-placement tests that validate both header order and DKIM signatures, so you can fix problems before they hit your sender reputation.

Header order and DKIM: A subtle but critical match

DKIM signs a specific list of headers, defined by the h= field. If your mail server or ESP reorders headers—common when using third-party routing or transformation layers—verification fails. This isn't a rare edge case; it’s a widespread issue that can lead to sudden delivery drops. We’ve seen this in real-world campaigns where otherwise valid emails were rejected simply because the header order no longer aligned with the h= value.

MailTester’s inbox-placement tests don’t just check if an email reaches the inbox. They inspect the full email header, including the exact sequence of fields sent. We validate that the h= field matches the real header order, even after routing or rewriting by gateways. This includes catching hidden reformatting—like added or reordered fields by cloud-based email services or security filters.

Accuracy that matters: 98.9% detection rate

Our system identifies DKIM-related delivery risks with 98.9% accuracy, using real-world validation techniques. This means you're not guessing whether your email will be rejected—you’re finding the root cause before sending. Each message is tested with a full header inspection and DKIM signature verification, simulating actual inbox behavior. This goes beyond basic syntax checks; it looks for functional alignment.

Let’s imagine you’re sending a campaign after using a third-party ESP. The system might normalize headers, which breaks DKIM if the h= field wasn’t updated. MailTester reveals this silently. You can test a sample before sending, or run bulk checks on your list using our email list verification tool to prevent mass failures.

For developers, the verification API integrates directly into your workflow. You can validate sender setups in real time, ensuring every message’s DKIM signature aligns with its header order. This is not about perfect alignment in theory—it’s about surviving the real-world complexity of message routing.

The h= field is a technical detail, but it's a high-impact one. For more on how DKIM operates, see the official specification in RFC 6376. And yes—small mismatches can cost you deliverability. Use the tools that test the actual behavior, not just the code.

Why bulk verification and deliverability testing are critical for DKIM compliance

DKIM signature issues like incorrect h= header field order aren’t isolated. A single misconfigured message can be rejected by multiple providers, silently damaging deliverability at scale.

Real-time verification and deliverability testing catch these flaws before they hit inboxes. Instead of guessing what might fail, you test actual delivery paths with live recipient infrastructure.

  • MailTester verifies entire lists at once, catching DKIM misconfigurations across hundreds or thousands of emails.
  • With integrations for Mailchimp, SendGrid, Klaviyo, and HubSpot, verification happens inline—before campaigns launch.
  • Testing isn’t optional. It’s a core part of maintaining consistent sender reputation and inbox placement.

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 does the h= field in DKIM mean?

The h= field specifies which email headers are included in the DKIM signature’s cryptographic hash. If the actual headers sent differ in order or content, the signature fails.

Can reordering headers break DKIM?

Yes — even if content is unchanged, reordering or modifying headers during transit invalidates the DKIM hash, leading to rejection by email providers.

How do email providers detect h= order issues?

Providers recompute the DKIM hash using headers listed in h=. If the received headers differ in order or presence, the signature fails, and the message is rejected or marked as spam.

Can a single misordered header ruin DKIM?

Yes — DKIM is sensitive to minor changes. Even one header out of order or missing can cause the hash to fail, triggering delivery rejection.

Does the h= field matter if I'm not using DKIM?

No — if DKIM is not enabled, the h= field is irrelevant. But if you're using DKIM for authentication, proper h= setup is mandatory for delivery.

How can I test for h= field order problems?

Use deliverability testing tools that inspect full email headers and DKIM signatures. MailTester performs real-time inbox placement testing with full header analysis.

Can header normalization cause h= issues?

Yes — systems that automatically clean or reformat headers (e.g., for readability or consistency) may alter order, breaking DKIM. This is common in email service providers and routing systems.

Is h= field order a common reason for email rejection?

It is a less visible but repeatable cause of DKIM failure. While not the most frequent issue, it's consistent across provider systems and can impact deliverability if uncaught.

Do email clients like Gmail check h= field order?

Yes — Gmail validates DKIM signatures, including header order. If the h= list doesn’t match the actual headers sent, Gmail may flag the message as suspicious or reject it entirely.

Can I fix h= issues after sending?

No — once sent, you cannot fix the DKIM hash. Prevention is critical. Always test headers and DKIM setup before sending to large lists.

What is the role of mail servers in h= field validation?

Mail servers receiving an email recompute the DKIM hash using the h= header list. If the actual headers don’t match, the server rejects or flags the message as unverified.

Why does MailTester include header field analysis?

To catch delivery risks like h= field mismatches early. Our 98.9% accurate verification identifies structural issues in DKIM-signature headers before they cause bounces or spam placement.