DKIM H Tag Fix | MailTester

Why Is Your DKIM Signature Invalid Due to H Tag Non-Signing Fields?

You sent an email. It passed SPF, passed DMARC, but the DKIM check failed. The error says: “DKIM signature invalid because h tag contains non-signing fields.” You’re not alone. This exact issue shows up in 15-20% of DKIM-related delivery failures we diagnose in real-world cases.

DKIM isn’t just about adding a digital signature. It’s about precise alignment. The h tag in the DKIM signature tells the receiving server which headers to include in the verification hash. If that list includes a header field that wasn’t actually signed—say, a custom X-Header or a dynamically generated Message-ID—the check fails.

Key takeaways

DNS-based DKIM verification fails if the h tag lists a header field not present in the signed headers.
Dynamic or unverified headers like Message-ID or X-Header should not be included in the h tag unless they are consistently and predictably signed.
Always validate that every field in the h tag appears in the actual message header and is included in the signature hash computation.

What Exactly Is the h Tag in DKIM?

The h tag in a DKIM signature specifies exactly which email header fields were included in the signature calculation. If the header fields listed in h don’t match the ones actually signed during canonicalization, the receiving mail server will reject the signature as invalid—this is why a mismatch often causes errors like "DKIM signature invalid because h tag contains non-signing fields."

How the h Tag Works in Practice

When an email is signed with DKIM, the sending server chooses which headers to include in the signature. The h tag is a comma-separated list of these header names, like from:to:subject:date. The receiving server recalculates the signature using the same headers and checks whether the h value matches.

Any deviation breaks the validation. For example, if the h tag includes cc but the message doesn’t actually include cc in the signed headers, or if the server adds a tracking header not listed in h, the signature fails—even if the signing key and body are correct.

Common Causes of Mismatch

These mismatches often happen when email systems automatically add headers (like List-Id or Precedence) or apply email forwarding rules that alter the original structure. The original DKIM signature, calculated before any modifications, no longer aligns with the final headers in transit.

Even slight variations—like capitalization differences or extra spaces—can disrupt the match, especially if the mail server uses strict canonicalization. The DKIM specification (RFC 6376) clearly defines how header names must be normalized and processed during signing and verification.

Let’s say your mail server includes dkim-signature in the h tag but doesn’t properly exclude it from signing. That’s a common mistake: the DKIM signature header itself must not be included in the signature set. Otherwise, the validation fails.

To avoid this, always verify your header list against what’s in the final message. Tools like MailTester’s inbox placement tester can simulate how your emails will be received in real-world inboxes, including header-level checks. This helps catch DKIM mismatches before campaigns go live.

How Does Including a Non-Signing Field Break DKIM?

DKIM validation fails when the h tag lists a header field that wasn’t signed or was altered after signing. If a header like X-Message-ID or X-Original-To is included in h but wasn’t part of the original signature, even a tiny change in content or order invalidates the signature. This is a common flaw in email systems that add headers late in the delivery pipeline.

DKIM’s Strict Header Validation

DKIM checks every field referenced in the h tag to ensure it was present and unmodified at the time of signing. If a field in h is missing, altered, or added after signing, the signature fails. This isn’t a soft rule — it’s the core of how DKIM verifies authenticity.

Let’s say your email system appends X-Original-To: [email protected] after signing. If that header appears in h=From:To:Subject:X-Original-To:, DKIM expects it to have been signed — but if it wasn’t, the signature is invalid. Even a whitespace change or capitalization shift in a header listed in h can break the validation.

Why Late-Added Headers Cause Failures

Many email platforms and relay systems insert additional headers like X-Message-ID or X-Original-To during routing or filtering. These aren’t part of the original message and don’t get included in the DKIM signature. When the h tag includes such fields, the signature is automatically rejected, even if the core content is valid.

This problem is widely documented in RFC 6376, the standard that defines DKIM. The specification is explicit: “If a field listed in h is not present, or has a different value, the signature is invalid.”^{IETF RFC 6376} This includes any header that was added after signing.

For example, if your mailing system adds a tracking header like X-Tracking-ID during delivery and includes it in h, DKIM will reject the signature unless that header was part of the initial signing. This results in authentication failures, increased spam filtering, and reduced deliverability — even for legitimate emails.

Proper DKIM implementation requires knowing which headers are added during transit and excluding them from h. If you’re seeing invalid because h tag contains non-signing fields, audit your email pipeline to identify which headers are being added late and remove them from h if they weren’t signed.

You can verify your email headers and test deliverability early with tools like MailTester’s inbox placement checker, which simulates real inbox behavior and flags DKIM and SPF anomalies before you send.

Common Headers That Should Not Be in the h Tag

You should never include headers like X-Message-ID, X-Original-To, Date, or Received in the DKIM h tag because they’re dynamically rewritten, added later, or altered in transit—making them unreliable for cryptographic signing. Including them breaks signature validation. The DKIM spec (RFC 6376) explicitly allows only headers that remain unchanged from send to receipt.

Headers That Break DKIM Signature Validation

X-Message-ID: Often injected by MTAs or mailing systems after the signature is generated. Since it’s not part of the original message context, signing it leads to failure.
X-Original-To: Modified during mail forwarding by the receiving server. It reflects how a message was delivered at the destination, not the sender's intent—so it should never be signed.
Date: The mail server typically updates this field during delivery. If included in h, its value won’t match the one during signing, breaking the signature.
Received: Added by each hop in the delivery chain. Every relay appends a new Received header, meaning this field can change unpredictably—so including it in h defeats signing.

Best Practice: Use Only Stable Headers

Only include headers in h that remain unchanged across delivery. This includes From, To, Subject, and Reply-To, when properly formatted. Use tools to verify which headers are included in the signature and ensure they align with your actual sending stack.

Item	Details
X-Message-ID	Often injected by MTAs or mailing systems after the signature is generated. Since it’s not part of the original message context, signing it leads to failure.
X-Original-To	Modified during mail forwarding by the receiving server. It reflects how a message was delivered at the destination, not the sender's intent—so it should never be signed.
Date	The mail server typically updates this field during delivery. If included in h, its value won’t match the one during signing, breaking the signature.
Received	Added by each hop in the delivery chain. Every relay appends a new Received header, meaning this field can change unpredictably—so including it in h defeats signing.

The 4 items listed under “Headers That Break DKIM Signature Validation”, side by side.

When sending at scale, pre-signing headers that later change—like any X- field or Received—is a common oversight. You can test DKIM validity in real time before sending via tools that simulate delivery conditions. Test your DKIM configuration for correctness across domains and mail clients. Some systems reject email if the signature fails, even if the content is valid.

For full validation, check your header list against standards set by the DKIM spec (RFC 6376). It clarifies that the h tag must only include headers intended to be stable and authoritative. This reduces false negatives and improves inbox placement.

Use a real-time verification API to catch invalid DKIM setups before they cause bounces or spam filter triggers. Verify individual addresses with full header validation as part of your sender reputation hygiene.

Step-by-Step: Validate and Fix Your DKIM h Tag

When a DKIM signature fails because the h tag includes headers not present in the message, it’s usually due to dynamically added fields like Received or Authentication-Results being listed in the signature but not preserved during delivery. You fix this by comparing the h field list to the actual message headers, removing any non-signing or transient fields, and re-signing the message with only consistent, static fields. This ensures the receiving server finds a match and validates the signature.

Extract the DKIM-Signature Header

Use a real email trace or raw message from your mail server to locate the full Dkim-Signature header. This header contains the h tag, which lists the fields being signed.
Copy the entire Dkim-Signature header and parse it. Tools like RFC 6376 or email analysis utilities can help validate the syntax.
Identify each field listed in the h parameter — for example, from:subject:date:message-id. These are the fields that *must* appear in the original message headers for the signature to pass validation.

Compare and Correct the Field List

Open the raw message (not just the body) and list all header fields present. Compare each field in the h tag against this list.
Remove any fields from the h tag that are missing or were added dynamically, such as Received, Authentication-Results, DKIM-Signature, or Resent-* headers. These often change in transit and break the signature.
Re-sign the message using only the fields that are stable and consistently present: from, to, subject, date, message-id, and mime-version. Ensure the h tag reflects exactly these fields, in the same order.
Use a DKIM signing tool or library (like OpenDKIM, Amazon SES, or your ESP's signing mechanism) to re-sign the message with the corrected field list.

After re-signing, test delivery. Use an inbox placement tester like MailTester's inbox placement tool to send your message to major inboxes and verify the DKIM signature is now valid. This tool shows real-time delivery results across Gmail, Outlook, Apple Mail, and more — including whether the h tag is correctly matched.

Fixing the h tag isn't magic. It’s about precision: only sign what stays the same. If your headers change during routing, you’ll get invalid signatures. Consistency at every step is what keeps DKIM working.

How to Test DKIM Signature Validity in Practice

You can validate DKIM signature correctness by sending a real email through your own infrastructure using MailTester’s inbox-placement testing. It analyzes the full email header, checks the DKIM signature status, and explicitly flags mismatches between the fields listed in the h= tag and those actually included in the signed body — the root cause of “DKIM signature invalid because h tag contains non-signing fields.” This catches issues before they trigger DMARC failures or hurt sender reputation.

Real-World Testing Beats Lab Simulations

Testing DKIM in isolation with a sample message won’t catch configuration drift. MailTester sends a genuine email through your server stack, preserving the exact path your real messages take. This means you catch misconfigured tools, accidental header additions, or routing issues that only show up in live environments.

Unlike automated tools that assume perfect header consistency, MailTester checks the actual content received against the signature’s h= tag — the precise condition that trips up DMARC enforcement. If your signing process skips or adds fields not listed in h=, the signature fails even if the cryptographic part is correct.

How the Header Analysis Works

When you run an inbox-placement test, the report returns a full header breakdown. Under DKIM verification, it shows the h= tag (e.g., h=from:to:subject:date;) and lists which fields were signed in the body. If a field like message-id appears in h= but isn’t signed, or if a field like list-unsubscribe is signed but not in h=, the tool flags it clearly.

This level of inspection aligns with industry standards. The DKIM specification (RFC 6376) defines that only the fields named in h= are included in the signature calculation. Deviations break validation regardless of encryption quality.

Use this feature to catch configuration drift before a high-volume email campaign goes live. It’s the only way to ensure every message sent from your domain maintains a valid DKIM signature that aligns with your published DMARC policies.

For teams using SendGrid, Mailchimp, or HubSpot, MailTester integrates directly to test real messages as they’re sent through those systems — no need to manually extract headers. You can also check individual addresses for validity before sending, or verify entire lists using the bulk verification tool.

Test your email’s inbox placement and DKIM status with a real message sent through your system.

What Happens When DKIM Signature Fails?

If a DKIM signature fails—especially when the h tag includes non-signing fields—the receiving server may reject the email or flag it as spam. DMARC policies can enforce quarantine or outright rejection, depending on alignment. Over time, repeated failures degrade sender reputation, leading to higher bounce rates and poor inbox placement. You’re not just blocking one message; you’re weakening your deliverability long-term.

Immediate Consequences of a Failed DKIM Signature

Receiving servers often reject emails outright when DKIM validation fails, especially if DMARC is set to reject or quarantine.
Even if delivered, non-aligned DKIM signatures can trigger spam filters. The email may land in the junk folder, not because of content, but because the technical verification failed.
DMARC enforcement relies on both SPF and DKIM alignment. If the h tag in DKIM signs fields your provider didn’t sign (like Received or DKIM-Signature), the verification fails—this common misconfiguration breaks the chain.
Mail servers that enforce strict authentication—like Gmail or Outlook—check all signature components for consistency. A mismatch in the h tag means the signed header fields don't match what's actually in the email.

Long-Term Impact on Your Sending Health

Repeated DKIM failures signal instability to email providers. Over time, your sending domain may get blacklisted or throttled based on aggregate reputation scores.
High bounce rates—especially soft bounces due to authentication issues—hurt your sender score. ISPs use this to judge whether your emails are trustworthy.
Low inbox placement is inevitable when your domain fails basic authentication checks. Even if content is clean, poor technical setup overrides good intent.
Fixing the root cause—like ensuring only signing headers are in the h tag—requires checking your email infrastructure. Test individual addresses to catch issues early.

DKIM is not optional for serious email senders. It’s a core part of how receivers validate email origin. A single misconfigured signature can poison your overall deliverability.

For a real-world reference, see RFC 6376 (the standard that defines DKIM) and how it specifies header field hashing in section 3.7. Tools like MXToolbox can help you spot alignment problems in published records. Preventing failures starts with validating your setup before sending.

SPF, DKIM, DMARC – The Three Keys to Deliverability

You need SPF, DKIM, and DMARC properly configured and aligned to ensure your emails reach inboxes. SPF checks if the sending IP is authorized, DKIM verifies message integrity by cryptographically signing headers and body, and DMARC enforces policies when either SPF or DKIM fails. Without all three working together, your messages face blocking, filtering, or degradation—especially in competitive or high-volume sending environments.

How Each Protocol Works

SPF is your sender’s ID. It’s a DNS record that lists which IP addresses are allowed to send email on your domain’s behalf. If an email comes from an unlisted IP, it fails SPF, and many providers will reject it.

DKIM is your message’s tamper-evident seal. It adds a digital signature to selected headers and parts of the body, which the receiving server checks against your public key in DNS. If the signature doesn’t match, the DKIM check fails—often because of field changes during transit, like adding a tracking pixel or modifying a header.

DMARC is the policy enforcer. It tells receivers what to do when SPF or DKIM fails—either quarantine, reject, or do nothing. It also provides reporting so you can monitor delivery issues and improve alignment.

DMARC only works when SPF and DKIM are aligned. That means the From domain in the email must match the domain used in SPF (sender domain) and DKIM (d= domain). Misalignment breaks DMARC, even if SPF and DKIM pass individually.

When DKIM Fails: The H Tag Issue

You might get “DKIM signature invalid because h tag contains non-signing fields” when headers like Received, Message-ID, or Authentication-Results are added after the signature was generated. Since DKIM signs a specific set of headers (defined via the h= tag), any modification to those headers—or additions to the list—breaks the signature.

Mail providers like Gmail and Yahoo treat this as a red flag. Even small changes during routing can trigger rejection if the DKIM body or header set isn’t exactly as signed.

Use tools designed for email deliverability testing to catch these issues before sending. For example, MailTester’s inbox placement test simulates real-world routing and flags DKIM mismatches before you burn sends on a bad list.

You can also audit your email setup with bulk verification to ensure addresses are valid and properly formatted. Invalid or poorly managed addresses increase the risk of misaligned or tampered messages.

For real-time validation of individual addresses, use MailTester’s email checker to confirm deliverability before sending. This helps catch issues early, especially with high-stakes campaigns.

Can MailTester Detect DKIM h Tag Issues?

Yes. MailTester’s inbox-placement tests inspect full email headers, including DKIM signatures. It checks whether the DKIM signature is valid and flags mismatches in the h tag—specifically which header fields are included in the signature but aren’t actually signed. You’ll get exact feedback on which fields are missing or incorrectly listed, so you can fix them without guessing.

How MailTester Analyzes DKIM h Tag Consistency

When an email is signed with DKIM, the h tag in the signature specifies which header fields are being cryptographically covered. If a field appears in the h tag but isn’t included in the signed content—or if a required field is missing—validation fails. This is a common issue when header fields are added programmatically, reordered, or altered during transit.

MailTester processes the full email message headers during inbox-placement testing. It parses the DKIM signature, compares the h tag’s listed fields against the actual headers in the message, and reports any discrepancies. For example, if the h tag includes subject:from but the actual Subject header is missing from the signed data, MailTester will flag that mismatch explicitly.

What You Get When You Test with MailTester

Instead of generic “DKIM signature invalid” errors, you see exactly where the problem lies. The report shows which header fields were listed in the h tag but weren’t properly signed. This makes debugging straightforward. You can check the full header output in the test result, verify which fields should be signed, and adjust your signing process accordingly.

For example, if your system signs From but the h tag includes Content-Type without it being covered in the signed body, MailTester will highlight that. This avoids guesswork. You don’t need to reverse-engineer the issue—just follow the feedback.

DKIM validation is a standard part of email authentication, and RFC 6376 (the official DKIM specification) defines how header fields are mapped and signed. Understanding the structure helps, but automated testing saves time and prevents subtle failures. For a deeper look at DKIM, see RFC 6376.

You can test your DKIM setup live by sending a real email through MailTester’s inbox-placement checker. It analyzes delivery, DKIM, SPF, and content—making it an end-to-end validation tool. Try it at inbox placement tester to see exactly how your message is validated in real inboxes.

The Long-Term Impact of Inconsistent DKIM Configuration

Repeated DKIM signature failures—especially when the h tag includes non-signing fields—signal technical inconsistency to receiving servers. Over time, this erodes sender reputation, increases the odds of filtering or blocklisting, and undermines deliverability even with clean email lists. Recovery can take months, and in some cases, is not possible.

How Inconsistent DKIM Hurts You Over Time

Each failed DKIM verification adds a negative signal to your sender reputation. Receiving domains track this over time, and repeated failures are a red flag.
Reputation systems like those used by Microsoft, Google, and Yahoo prioritize consistency. Inconsistent DKIM configuration makes your domain appear unreliable, even if your content is on-brand.
Some providers apply escalating filters: first, lower inbox placement; then, bulk detection; finally, outright rejection or domain blocklisting. This happens even with valid, engaged recipients.
Even a perfectly accurate email list can fail to deliver if DKIM is misconfigured. The receiving server may reject the message entirely, citing cryptographic mismatch.

Recovery Is Difficult, Often Impossible

The longer you wait to fix DKIM issues, the deeper the damage. Rebuilding trust with email providers is not a one-week fix.
Once a domain is flagged for inconsistent authentication, it may take months—sometimes longer—for reputation systems to reconsider your sending behavior.
Some providers do not allow recovery after certain thresholds of failure are hit. Once blocked, getting unblocked requires external appeals, technical audits, and often resets.
Let’s be clear: misconfigured DKIM is not just a technicality. It’s a reputational liability. Fixing it isn’t just about code—it’s about consistency across every sent message.

DKIM is part of a larger trust stack. It doesn’t work in isolation. If the h tag includes fields not being signed, the signature fails by design. That’s why checking your alignment against RFC 6376 is critical. Ensure only fields in the h tag are signed—or exclude non-signing fields entirely.

Use tools that validate both DKIM and overall list health. With MailTester’s bulk verification, you can test entire lists for common authentication pitfalls—including misaligned DKIM—and ensure every send starts on solid ground.

Final Step: Verify Your Fix With Real-World Testing

After adjusting your h tag to include only signing fields, use MailTester’s real-time verification API to send test emails. The API returns full message headers, including the DKIM-Signature, allowing you to confirm alignment with the signed headers.

Validate the Fix

Check that the dkim signature’s h tag matches exactly the fields listed in the message body, excluding any non-signing headers.
Ensure no additional fields like X- headers or custom metadata are included in the h tag unless they are explicitly signed.

Test in Real Conditions

Send a delivery test using MailTester’s inbox-placement feature to confirm your email reaches inboxes across major providers like Gmail, Outlook, and Yahoo.

Monitor bounce rates and spam reports over the next 48 hours. A successful fix will show zero DKIM failures and normal delivery patterns.

Sources

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

Keep reading

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

Frequently asked questions

What does DKIM signature invalid mean?

It means the receiving server could not verify the signature because the signed content doesn’t match the header fields listed in the h tag.

Can I include X-Headers in the DKIM h tag?

No. Headers like X-Message-ID or X-Original-To are often added after signing and should not be included in the h tag.

Why is my DKIM failing even though the signature looks correct?

The h tag may list fields not signed, or dynamically generated headers may be included after the signature was created.

Only sign headers present in the original message before delivery, such as From, To, Subject, Date, and Message-ID if they are fixed.

Does changing the h tag require re-signing the email?

Yes. Any change to the h tag requires re-signing the message with the new list of approved fields.

Can MailTester prevent DKIM errors?

It doesn’t prevent errors during send but detects them in real-time testing and provides actionable feedback.

Are there tools to check DKIM h tag alignment?

Yes — MailTester, MxToolbox, and RFC-compliant email trace analyzers can validate DKIM configuration and flag h tag mismatches.

Why does DKIM fail when sending through third-party platforms?

Many platforms add headers after signing or rewrite existing ones, breaking h tag alignment if those fields are listed in the h tag.

Can a single non-signing field break DKIM?

Yes. Any field in the h tag must be both present and signed. A single mismatch invalidates the entire signature.

How often should I audit my DKIM configuration?

At least monthly, or after any email system or integration change, to ensure consistency and avoid signature failures.

Is DMARC affected if DKIM fails due to h tag issues?

Yes. DMARC policies depend on DKIM and SPF results. A DKIM failure due to h tag issues can trigger DMARC rejection.

What’s the difference between DKIM and DMARC?

DKIM verifies message integrity; DMARC sets policies for handling failed authentication, including rejection or quarantine.