Why Are DKIM H-Tag Errors a Hidden Deliverability Risk?

You've double-checked your SPF record. Your DKIM key is published. The email sends. But it still lands in spam—or worse, fails to deliver at all. Why?

One likely culprit hides in plain sight: a flawed DKIM h= tag. DKIM signatures validate that headers and body content remain unchanged from sender to recipient—but only if the right headers are included in the signature. If the h= tag lists headers that aren’t actually signed, or omits required ones, the signature fails, even if everything else is configured correctly. These are the common DKIM h tag mistakes with non-signing fields that most teams miss until they’re facing inbox placement drops.

Think of DKIM like a sealed envelope: the seal guarantees integrity. But if the seal only covers a subset of the envelope’s contents—say, the sender address but not the subject line—the verifier can’t trust the message. Mistakes in the h= tag break that trust. This article reveals where the gaps are, how they undermine deliverability, and why correcting them matters—especially when dealing with non-signing fields you might assume are irrelevant.

Key takeaways

  • The DKIM h= tag must list only headers actually included in the signature; including unsigning headers fails validation.
  • Even a single invalid header in the h= tag can cause rejection by receivers that enforce strict DKIM checks.
  • Headers like Content-Type, Message-ID, and Date are typically required—misconfiguring their inclusion in h= breaks the chain of trust.

What Does the DKIM h= Tag Actually Do?

The DKIM h= tag defines which email headers are included in the cryptographic hash of the signature. If the signing server lists From:Subject:Date: in h=, only those three headers must be present and correctly formatted in the message. Any missing, misplaced, or typos in these headers—like a misnamed Subject or extra whitespace—break the signature validation, even if the content is otherwise correct.

How the h= Tag Interacts with Header Order and Names

DKIM signatures are sensitive to header ordering. The headers listed in h= must appear in the exact sequence in the final message. If your email library adds a trailing space to From, or inserts a Precedence header between From and Subject, the hash won’t match—because the signature was computed on a different header sequence.

And yes, header names are case-insensitive in DKIM, but the formatting still matters. A From header with capitalized F in the middle (like FroM) or extra spaces before the colon (From : ) will not match the expected format. The signing process expects consistency, and even small variations trigger failure.

Why Non-Signing Fields Cause Signature Failures

Some fields don’t appear in the h= list but might still appear in the message, like List-Subscribe, Auto-Submitted, or custom tracking headers. These are harmless if they’re not listed—but if you accidentally include them in h= or rely on a header that’s meant to be excluded, the signature will fail.

Let’s say you signed the message with h=From:Subject:Date:Reply-To, but your sending system forgot to include Reply-To on some messages. DKIM will complain, even if the header exists in the data—because it wasn’t actually sent. The signature is not just about presence, but about matching the exact set of headers used at signing time.

For deeper visibility into how your headers align with DKIM expectations, use a real-time verification tool. Check individual addresses and headers before sending to catch these issues in advance. You don’t want to send on a high-volume campaign only to have DKIM fail and land in spam.

According to RFC 6376, the standard defining DKIM, only headers listed in h= are hashed and validated. Misunderstanding this is one of the top reasons DKIM fails in practice. You can read the full specification at IETF’s RFC 6376.

Common DKIM h-Tag Mistakes with Non-Signing Fields

You’re signing headers in the DKIM h= tag that either don’t exist, were modified later, or aren’t supposed to be signed at all. This breaks signature validation, lowers deliverability, and can trigger spam filters. Let’s fix the most common missteps before they hurt your sender reputation.

Headers in h= that aren’t actually in the message

  • Don’t include Reply-To: in h= if you’re not sending a Reply-To header — mail servers will reject the signature.
  • Never list Sender: unless it’s present and unmodified. If your system uses From: only, don’t include Sender: in h=.
  • Ensure every header in h= appears exactly as it’s sent in the raw message, with no missing or extra fields.

Headers that are present but omitted from h=

  • If you’re sending a Subject: or Content-Type: header, make sure it’s in h= — omissions fail validation.
  • Some systems add Content-Transfer-Encoding: after signing. If it’s part of your message, include it in h=.
  • Don’t assume your MTA won’t alter headers — verify what’s actually sent.

Headers modified after signing

  • If your service appends X-Feedback-ID: or similar tracking headers post-signature, don’t include them in h= — these aren’t in the original signed message.
  • Always sign headers as they exist at the moment of signing. If a header is added later, it must be excluded from h=.
  • Use tools like RFC 6376 to trace how the signature should map to the original header set.

Signing headers that shouldn’t be signed

  • Never include Return-Path: in h= — this header is added by the receiving MTA, not the sender.
  • Don’t sign Received: or Delivered-To: — these are generated by intermediate servers.
  • Your h= tag should only include headers you explicitly added during message composition.

These errors don’t just break DKIM — they signal poor infrastructure to inbox providers. Use a real-time verification tool like MailTester’s email checker to test whether your sender environment is producing valid, consistent headers. It flags missing or extra fields before you send.

How Misconfigured h= Tags Break DKIM Validation

DKIM fails when the headers listed in the h= tag don’t match exactly what’s in the received message. Even a single missing, altered, or reordered header—like a changed Subject or a stripped Received header—breaks the hash comparison. Receiving servers reject messages with failed DKIM signatures, regardless of SPF or DMARC status. It’s not a soft fail; it’s a hard rejection.

What the h= Tag Actually Does

When you sign a message with DKIM, the h= tag defines which headers are included in the signature hash. The receiving server computes the hash of the actual headers in the incoming message using the same list. If the original message had a From: and To: but the h= tag includes Date: and Message-ID: while omitting From:, the hash won’t match.

Let’s say you sign with h=from:subject:date; but the server receives a message where Subject: has been transformed (e.g., by a mailing list) or removed. The expected hash is calculated on a header that doesn’t exist anymore. Even if all other fields are correct, the validation fails.

Why This Matters in Real-World Deliverability

Mail providers like Gmail, Outlook, and Yahoo use DKIM as a key part of their spam and authentication checks. A failed DKIM signature often triggers rejection, even if SPF passes and DMARC policy allows delivery. You might get a clean SPF result, but the message still lands in spam or gets dropped entirely.

Common non-signing fields—like Received:, Delivered-To:, or Return-Path:—can appear in the message path but aren’t typically intended for signing. Including them in h= without ensuring they’re preserved leads to failures. Conversely, excluding a header that’s actually present in the final message breaks the match.

The RFC 6376 specification outlines how DKIM validates signatures, and the strict header-by-header comparison is intentional: it prevents tampering. You can’t "get away with" a partial match, even if the message is otherwise safe. Misconfigurations here silently undermine your sender reputation.

For teams using bulk email tools, even small changes in how headers are processed can cause massive DKIM failures. A single poorly-configured h= tag can invalidate thousands of messages. Using a tool like MailTester to verify your list and simulate sending can catch these issues early—especially before sending to high-volume campaigns. You can test your message headers and their signing setup using our inbox placement tester to see how your signed email performs in real environments.

Real-World Example: The Misleading h=From:Subject:Date:

You sign DKIM with h=From:Subject:Date:, but your email service appends a custom delivery ID header after signing. The receiving server checks only the headers listed in h=, finds no such header in the message, and rejects the signature—even if From and Subject are correct. This happens because DKIM requires exact header alignment. Even one missing or extra header breaks validation.

The Hidden Pitfall of Post-Signature Modifications

Let’s say you’re using an email service that adds a X-Message-ID: or Delivery-ID: header after your DKIM signature is generated. The signing process sees only From:Subject:Date:, so it doesn’t account for the new header. When the recipient’s server validates the signature, it expects exactly those headers to be present. If one is absent or modified, DKIM fails—even if all the content is legitimate.

This is a common issue in bulk email platforms that auto-inject tracking or routing headers. You might assume DKIM is working because your From field is correct, but the signature is rejected due to mismatched header lists. According to the DKIM RFC (RFC 6376), the signing process must include every header in the h= list in the final message. If any are added afterward, the validation fails.

Even small changes like adding a Message-ID: or Received: header (which many servers do for tracking) can break DKIM if not properly accounted for in the signing list.

How to Catch This Before It Breaks Deliverability

Let’s be honest: you won’t catch this unless you test thoroughly. Most email clients and providers don’t warn you when DKIM fails due to header mismatches—only that the message is not authenticated. If you’re seeing unexpected bounce rates or inboxing issues, this is worth investigating.

The simplest fix is to include all headers that your email service will eventually add in the h= list. But that requires knowing your vendor’s behavior. Many services don’t document this upfront.

That’s why testing is essential. Use a real inbox placement tool to verify how your messages appear on the receiving end. MailTester’s inbox placement test sends actual messages through major inboxes and shows exactly how DKIM, SPF, and DMARC are validated. You’ll see whether the signature fails—and why—before sending to real users.

For teams that send at scale, pre-validation is non-negotiable. Bulk list verification includes header and DKIM health checks, catching issues like this before they impact deliverability.

How to Check for DKIM h-Tag Issues in Practice

You can catch DKIM h-tag mismatches by sending a real email through a deliverability testing tool like MailTester and reviewing the DKIM report. The report shows exactly which headers were included in the signature and which ones were present in the final message, exposing any discrepancies caused by missing or altered headers. This step catches issues that only appear after the email leaves your system.

Real-Time DKIM Validation with Trusted Tools

  • Send a test message directly to MailTester’s inbox placement tester to generate a full DKIM report: test your domain’s DKIM configuration in real time.
  • Review the DKIM report for any “header mismatch” errors—these show when a header listed in the h= tag doesn’t appear in the final email.
  • Verify that every header in the h= list is present in the final message headers, not just in the original draft or outbound queue.
  • Check if auto-reply filters, campaign tagging, or routing rules modify or insert headers after signing, which can invalidate the signature.
  • Use the MailTester email checker to verify individual addresses before sending, ensuring they’re not caught in post-processing loops.

Common Pitfalls in Header Handling

  • Don’t assume the headers in your email client or mailer match what arrives in the inbox. Post-processing can strip or rewrite fields like From, To, or Subject.
  • Treat the h= tag as a contract: only include headers that remain unchanged from send to delivery.
  • Auto-generated headers (like X-Message-ID) should not be signed unless they’re preserved intact by all intermediary systems.
  • Review the DKIM standard for guidance on header selection and signing practices—it’s the definitive reference.
  • For large-scale campaigns, integrate the MailTester API to validate sender configurations across all outbound messages.

DKIM fails silently when headers don’t match. A single missing or altered field breaks the signature. Use actual delivery tests—no simulation—to find and fix these mismatches before they damage sender reputation.

Best Practices for Defining the h= Tag in DKIM

Include only headers that are present in every message and won’t change across delivery routes. Avoid dynamic fields like tracking IDs, routing tags, or user-agent headers. Stick to standard, stable ones: From, To, Subject, Date, Message-ID, and Reply-To only if consistently used. This prevents DKIM failures during validation.

What to Include in the h= Tag

  • Only headers that exist in every delivery, unmodified by infrastructure. This includes From, To, Subject, Date, Message-ID, and Reply-To—only if they are consistently present across all messages.
  • Exclude headers that are modified, added, or stripped by transit systems, such as routing IDs, campaign tracking tags, or X-headers used for internal processing.
  • Use standard, well-known headers—no custom or vendor-specific prefixes unless they are stable and always included.
  • Avoid relying on header values that change per send (e.g., DKIM-Signature, Authentication-Results, Received) or user-agent strings.

Why Consistency Matters

DKIM signs a specific subset of headers. If the receiving server sees a header listed in the h= tag that wasn’t present in the original message, or if its value has changed, the signature fails. This is a common point of failure.

For example, a dynamic tracking parameter like X-Track-UID can alter the header value between sending and receiving, breaking the signature. Even if your system uses the same header name, any non-constant data breaks DKIM.

RFC 6376, which defines DKIM, explicitly states that the h= tag should reference only headers that are "expected to be present and unaltered" in delivery [RFC 6376]. This isn’t just best practice—it’s mandatory.

  • Test your DKIM configuration with tools that check header alignment. Verify individual addresses to catch issues before sending.
  • Use a real-time verification API to validate mail streams before deployment. Integrate with your sending workflow for automated checks.
  • Monitor your mail streams for bounces tied to DKIM failures. These often indicate a mismatch in the headers defined in h= vs. what’s actually sent.
  • When testing deliverability, simulate inbox placement using tools that evaluate both content and metadata. Test how your emails land across inboxes to catch alignment issues early.
“The h= tag must reference headers that are guaranteed to be present and unchanged in transit.”

When in doubt, use a minimal set: From, To, Subject, Date, Message-ID. These are rarely altered and are always present. Over-including headers only increases failure risk.

Why Non-Signing Headers Should Still Be Checked

You must check non-signing headers in DKIM signatures not because they're signed, but because the h= tag lists which headers are required to be present. If a header in h= is missing, DKIM fails—even if every other part is correct. Even headers not listed in h= matter: if they're modified after signing, they can still affect message routing or trigger spam signals.

The Logic of h=: Presence Matters

DKIM uses the h= tag to define which headers are part of the signature’s scope. Any header included in that list must actually exist in the message. If it’s missing—say, Subject: is in h= but never sent—the DMARC policy will fail, and the message is likely rejected, even if the signature itself is mathematically valid.

Think of it like a checklist: the signer says, “Here’s what I’m signing.” If a required field is blank, the verification fails. You can’t argue that it was implied—it has to be there.

What About Headers Not in h=?

Headers not listed in h= can exist and be altered after signing without breaking the DKIM validation. But that doesn’t mean they can be ignored. For example, a modified Received: or Delivered-To: header may not invalidate the signature, but it can still raise red flags with spam filters or cause routing issues.

Spam scoring algorithms often examine header consistency. If headers like Return-Path or From don’t match across multiple fields, or if Received: chains are inconsistent, mail servers may apply reputational penalties. These aren’t DKIM-specific, but they do impact deliverability.

Even if a header isn’t signed, you should still validate it for compliance. If the From header in the message shows a known brand, but the Return-Path points to a different domain or a disposable address, that’s a red flag. Tools like MailTester’s email checker can help find these inconsistencies before you send.

Let’s be clear: DKIM is about cryptographic validation, but deliverability is broader. Consistent headers—signed or not—help maintain sender reputation. A single malformed Received: header or a missing Message-ID can silently degrade inbox placement.

For more context, see the DKIM RFC, which details how header signing and verification are structured. The system assumes you know what headers matter—because if they’re not signed, you’re still responsible for their correctness.

How MailTester Helps Diagnose DKIM and Header Misconfigurations

You can catch DKIM h= tag mistakes with non-signing fields by testing emails in real inboxes. MailTester’s inbox-placement testing simulates actual delivery conditions and flags DKIM failures—often caused by misconfigured h= tags, like signing headers that aren’t actually signed or including headers not meant to be signed. The tool validates the entire signature chain, including header alignment, so you know if your DKIM setup is sound before sending.

Real-World Validation with Inbox-Placement Testing

DKIM isn’t just about generating a signature—it’s about aligning it with the exact headers sent. A common failure point is the h= tag including fields that aren’t signed, or excluding ones that should be. MailTester’s inbox-placement tests send real emails to major inboxes like Gmail, Outlook, and Yahoo, checking whether DKIM parses and validates correctly during actual delivery. If the h= list doesn’t match what’s signed, the signature fails—even if all other fields are correct.

This end-to-end approach catches issues that static validators miss. Tools that only check syntax or DNS records can’t spot a mismatch between what you claim to sign and what’s in the header block. For example, a misaligned h= tag may list “Received” or “X-SPF-Result” but not include “Date” or “Message-ID”—fields your server does sign. Such inconsistencies often lead to rejection or spam filtering. The DKIM RFC specifies that only listed header fields should be included in the signature, so misalignment breaks compliance.

AI-Powered Header Analysis and Bulk Validation

Let’s say you’ve got 50,000 addresses in your list. You don’t want to debug DKIM failures one email at a time. MailTester’s bulk verification runs real-time DKIM checks across your entire list, flagging addresses where the signature fails—often due to header mismatches in the h= tag. It also integrates with your CRM or ESP via the email verification API, so you can validate at point of entry.

Our in-app AI assistant helps you parse header lists and detects problematic patterns. It spots missing fields, redundant entries, or inconsistent formatting. For example, it identifies when “To” is signed but not in the h= tag, or when a header like “List-ID” is included but not part of the signing scope—common in campaign emails. No guesswork. Just a clear report of what’s wrong and why.

Use the inbox-placement tester to validate your full message before sending, and ensure your DKIM setup holds up in the wild.

Preventing h= Tag Errors Before They Happen

DKIM h= tag errors happen when signed headers don’t match what the receiving server expects—usually because headers were added, removed, or altered after signing. Let's fix that upfront: document every header in your messages, confirm which ones you include in h=, test all message types, and audit logs to catch any post-signature changes before they break delivery. It's not a one-time setup—it's ongoing verification.

Map and Verify Every Header

  • Start by listing every header present in your outgoing emails—From, To, Subject, Date, Content-Type, and any custom X-headers.
  • Check which of these are actually included in the DKIM h= tag in your signing configuration. If a header is used in the signature but not listed, the verification fails.
  • Use RFC 6376 as a reference for header normalization rules, especially how case folding and trailing whitespace affect signature validation.
  • Ensure you’re not silently including non-signing headers (like X-Feedback-ID or Message-ID used only for tracking) in h=, which can cause mismatches if they vary per send.

Test Consistency Across Message Types

  • Run your campaign, transactional, and drip emails through the same DKIM signature process. Even small differences in header order or content can break h= alignment.
  • Use your ESP’s or MTA’s header inspection tools to verify what each message actually delivers. Not all ESPs preserve headers identically during routing.
  • Check logs from your mail transfer agent or ESP for signs of header manipulation—some platforms normalize or rewrite headers like Subject (e.g., adding a prefix or trimming content) after signing.
  • Validate that no third-party tool—like a newsletter platform or email gateway—is interfering with headers after your DKIM signature is applied.

When you’re sure the signed headers in h= are accurate and consistent across all send types, you eliminate a common root cause of DKIM failures. You can test this setup with real recipient checks using MailTester’s inbox placement tester, which includes DKIM header validation in its delivery simulation.

The Bottom Line: Consistent Headers Are the Foundation of DKIM

DKIM validation relies entirely on exact header matching. If even one non-signing field is incorrectly included in the h= tag, the signature fails — regardless of the rest of the configuration.

Common h= tag mistakes with non-signing fields

  • Including optional or dynamic headers like Content-ID or DKIM-Signature in h= tags, which should never be signed.
  • Missing a required header from h= tags when it appears in the message, especially in forwarded or auto-generated emails.
  • Using inconsistent header names (e.g., From vs from) due to case sensitivity in the signing process.

Even a single mismatch in the h= tag can trigger authentication failure, leading to higher bounce rates and damaged sender reputation. These issues often go undetected in testing tools that don’t simulate real-world inbox behavior.

Use MailTester to test your DKIM configuration across real inboxes and identify h= tag errors before they impact deliverability. Its inbox-placement testing catches header-level inconsistencies that static validators miss.

Fixing h= tag mismatches reduces authentication failures, improves inbox placement, and strengthens sender reputation over time.

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 if a header in the DKIM h= tag is missing?

DKIM validation fails. Even if other headers are correct, the signature hash won’t match, and the email may be rejected or marked as spam.

Do all mailers need to include the same headers in h=?

No, but they must maintain consistency. The set of headers in h= must match the actual headers present in every message.

Can I include a custom header in the DKIM h= tag?

Yes, but only if it's consistently present and not altered after signing. Otherwise, it risks breaking DKIM.

How do I know if my DKIM h= tag is correct?

Test with a deliverability tool that simulates real inbox checks. MailTester's inbox-placement tests reveal DKIM issues in real-world scenarios.

Does the order of headers in h= matter?

Yes, DKIM is order-sensitive. The headers in h= must appear in the same sequence in the actual message for the hash to match.

Are non-signing headers dangerous?

Not directly, but if they’re modified post-signature and not included in h=, they can cause confusion. Only signing fields directly impact DKIM.

Can a change in the 'From' field after signing break DKIM?

Yes, if From is in the h= tag and changes after signing, the hash won’t match. The From field must be consistent before signing.

Does MailTester detect DKIM problems?

Yes. MailTester’s inbox-placement testing includes real-time DKIM verification and reports failures due to h= tag mismatches.

Why do some emails pass DMARC but fail DKIM?

DMARC allows both SPF and DKIM to pass. A failed DKIM signature is rejected by DMARC even if SPF passes—common with h= tag errors.

Can DKIM be tested in isolation?

Not reliably. DKIM must be tested in context with other headers and delivery paths. Use tools like MailTester that simulate end-to-end delivery.

Is there a tool to audit my DKIM h= tag configuration?

Yes. MailTester provides inbox-placement testing with DKIM diagnostics. It checks header presence, order, and signing accuracy.

How often should I re-check DKIM header configurations?

After any major email system change—new ESP, updated template, routing rule. Regular checks help maintain sender reputation.