Why Does the DKIM H-Tag Include Non-Signing Headers?

You send an email, the DKIM signature passes, but the receiving server rejects it anyway. You check the headers, and the h= tag lists a bunch of headers you didn’t sign. Why? Because the signing process expects perfect alignment — every header in h= must be actually included in the signature body. If not, the validation fails.

DKIM is built on strict consistency: the h= tag tells the server which headers were signed. If the actual signed headers don't match what's listed, the signature is invalid. This isn’t a flaw — it’s by design. But when tools or systems inject tracking or delivery-specific headers without signing them, the h= tag becomes misleading, and the message fails.

Key takeaways

  • The h= tag in a DKIM signature must exactly match the list of headers included in the signature body — no extras, no omissions.
  • Headers like X-Message-ID, X-Original-To, or campaign tracking IDs can break DKIM if added to h= without being signed.
  • Automated email systems that modify headers without updating the DKIM h= tag are a common cause of signing failures.

How the DKIM H-Tag Works in Practice

The DKIM h= tag specifies exactly which headers were included in the signature. If your email’s h=From:Subject:Date:To: list doesn’t match what the receiving server expects, DKIM fails—even if the content is unchanged. This precision ensures no tampering, but requires you to control every header in transit.

Why the h= Tag Matters in Real-World Email Delivery

When you send an email with DKIM, the h= tag acts like a contract: “These are the headers I signed.” The receiving server checks each header listed in that tag, recalculates the hash, and compares it to the signature. If any header was added, removed, or altered—like a tracking pixel inserted by an ESP or a forwarded message’s header changed—verification fails.

Let’s say your email system accidentally adds a custom X-Campaign-ID header during delivery. If that header isn’t included in the h= list, DKIM will fail, even if the content is clean. This is why you must know every header your mail system or service touches.

This strict matching is not a flaw—it’s a feature. It prevents attackers from sneaking in forged headers or altering critical metadata like the From field. The DKIM specification mandates this behavior to preserve integrity across mail transports. Any deviation breaks the chain.

How to Get It Right: Control the Headers You Sign

When you set up DKIM, you must explicitly define which headers to sign. Most email services do this automatically, but if you’re using a custom backend, you’re responsible for choosing the list in h=. Commonly signed headers include From, To, Subject, and Date.

Don’t sign headers that your system might alter later. For example, if your ESP adds a Delivery-Date header during routing, don’t list it in h= unless you’re sure it won’t change. A mismatch here triggers a failure even if your email is legitimate.

Testing this is crucial. Use tools that simulate real-world delivery and check for header discrepancies. You can test your DKIM setup with inbox placement testing, which checks whether your full message—including headers—passes validation at major providers.

The Problem: Extra Headers Inadvertently Included in h=

You’re seeing DKIM validation failures not because your signature is wrong, but because headers added during email transit—like bounce tracking or routing metadata—are present in the original message when signed. If those headers were in the body at signing time, they get included in the h= tag. Even if they’re unsigned, their presence in h= breaks DKIM validation. This commonly happens with platforms that modify the message without re-signing it.

Why Headers Get Included Without Your Control

When your email passes through intermediaries—such as email service providers (ESPs), load balancers, or spam filters—additional headers are often injected. These might signal routing paths, spam scores, or delivery status. If your original message included a header like Received: or X-Message-Id: at the time of signing, and you didn't specifically exclude it in the h= tag, it becomes part of the DKIM signature.

This is a known issue in email infrastructure. The DKIM specification does not mandate which headers must be included, only that the list in h= must match exactly what was signed. If a third party adds a header you didn’t expect, and it wasn’t accounted for during signing, the validation fails.

How Platform Behavior Exacerbates the Issue

Many email platforms, including some marketing automation tools and SMTP gateways, reprocess messages and insert their own headers—like Auto-Submitted:, Delivered-To:, or X-Spam-Flag:. If your system signs the message before it reaches these services, and those headers were part of the initial body, they are still considered signed. But when the receiver validates, the header has been modified or added, so the signature no longer matches.

Even if the original signing included only From: and To:, any header present at signing time is implicitly part of the signature set unless you explicitly control the list in h=. This is why some DKIM failures occur inconsistently—even with the same message, different routing paths can trigger different results.

Let’s say you’re using an ESP that adds tracking identifiers. If you sign the message before it hits that ESP, and they add a header, your signature still expects that original header list. When the receiving server checks the signature, it finds an extra header in the h= list, and validation fails. You could catch this earlier with a real-time deliverability test.

Test inbox placement with tools that simulate the full delivery path, so you can see if headers inserted during transit cause a DKIM validation issue before sending to real recipients.

How to Fix: Control Which Headers Are Listed in h=

Ensure your DKIM signature only includes headers that are actually signed. The h= tag in DKIM must list only those headers your signing process covers. If a header is added during transit (like a delivery timestamp or routing header) but isn’t part of the signature, excluding it from h= prevents parsing errors and reduces the risk of signature failure. Always align the h= list with your actual signing policy.

How to audit and apply this correctly

  • Review every header present in the final email before signing. Tools like RFC 6376 define the structure and intent of DKIM headers, so reference it to confirm what belongs in the signature.
  • Only include headers in h= that your signing mechanism actually signs. If your system signs only From, Subject, and Date, then list only those — nothing more.
  • Remove any headers from h= that get added during transit (e.g., X-Received, Message-ID derived by MTA, or Authentication-Results) unless you explicitly sign them. Including them falsely increases the risk of a signature mismatch.
  • Use a strict header policy: sign only From, Subject, Date, To, and Content-Type by default, unless your workflow requires additional headers. This reduces complexity and aligns with standard best practices.
  • Test your signed emails using a real delivery checker. The inbox placement tool can help confirm that your DKIM signature remains valid after transit and doesn’t break due to header misalignment.

Why this matters in practice

Even small deviations in the h= tag can cause DKIM verification to fail. Receiving servers validate that every header listed in h= was signed in the same order and with the same content. If one header is missing or modified unexpectedly, the whole signature fails, even if the core content is correct.

Many email platforms (like SendGrid, Mailchimp, or HubSpot) automatically append headers during routing. If you don’t control these or include them in h= without signing them, you risk breaking the DKIM chain. Always verify your signing process matches your h= list, and audit headers before signing.

Step-by-step: Verify and Clean Headers Before DKIM Signing

Before signing an email with DKIM, extract the raw message and inspect all headers. Remove any non-signing headers like X-Queue-ID or X-Spam-Flag from the h= tag. Only include headers present in the signed body to avoid signature mismatches. Test the final result with a deliverability checker to ensure authentication passes.

Inspect and Clean Headers

  1. Extract the raw message before signing — Use a mail server log, MTA dump, or email testing tool to capture the full header and body before DKIM is applied. This gives you a clear baseline of what’s being signed.
  2. Check all headers with a tool like MxToolbox — Tools like MxToolbox or a raw email debugger reveal every header in a message. Look for non-standard or transient headers (e.g., X-Queue-ID, X-Spam-Flag) that shouldn’t be signed.
  3. Identify headers not meant for signing — Headers added by internal mail servers, spam filters, or routing systems often aren’t part of the original message. They vary per delivery path and can cause DKIM failures if included.
  4. Update the DKIM h= tag to only include valid signing headers — Set the h= tag to list only the headers you want signed. Make sure these headers are present in the message body and consistent across all messages from your domain.
  5. Resign the message with the corrected h= list — Re-sign the email using your DKIM key with the cleaned header list. This ensures the signature matches only the intended content.
  6. Test the signature using MailTester’s inbox placement test — Send a test email through a service like MailTester’s inbox placement test to validate that the DKIM signature is valid, accepted by receivers, and not blocked due to header mismatches.

Why Clean Headers Matter

DKIM verifies headers and body content as a whole. If the h= tag includes headers that aren’t in the final message (or weren’t signed), the signature fails. This isn’t a problem with your key — it’s a misalignment in what’s being signed vs. what’s checked. RFC 6376 (Section 5.5) defines how header selection works — but implementation often assumes consistency you may not have.

Why Your DKIM Signature Might Still Fail Even After Fixing h=

Even when you’ve corrected the h= tag to include only signing headers, DKIM can still fail due to timestamp skew, misconfigured domain key rotation, or an incorrect selector setup. The signature might be valid on paper, but if the signing time is too far in the past or future, or if the DNS TXT record for the selector doesn’t match the key, the mail server will reject it outright.

Common Hidden Failures Beyond h=

Time drift between your server and receiving mail servers can break DKIM. Most mail receivers expect the signature’s timestamp to be within a 10-minute window, not much more. If your server clock is off by even a few minutes, the signature will fail. This isn't about the h= tag—it's about the t= field.

Domain key rotation—changing your signing keys over time—can also cause issues if you forget to update the DNS record. A new key might be used in the signature, but the old TXT record remains, and receivers won’t know how to verify it. Double-check that your DKIM selector (the part before .domainkey in the DNS name) matches both the key used in the signature and the one published in DNS.

Verify Your DKIM Records and TTL

Make sure your DKIM TXT record exists and is correctly formatted. A missing or malformed record causes immediate failure. You can use tools like MXToolbox’s DKIM Lookup to check how your record appears from the outside.

Also, ensure the DNS record has a TTL (Time to Live) that allows it to propagate. While most systems accept records with TTLs between 10 and 60 minutes, too low a TTL can cause caching issues, and too high a TTL delays updates. A well-structured record with a stable TTL helps maintain signing consistency across global mail servers.

Let’s say your DKIM signature uses a selector like 2024q2._domainkey.example.com. You must confirm the record exists at that full name and contains the correct public key, not just a placeholder or a typo.

Use MailTester’s verification API to test SPF, DKIM, and DMARC records in real time. It checks not just the presence of records, but their alignment, syntax, and consistency with the sending domain. This helps you spot issues before they hit deliverability.

Use of Automated Platforms? Watch for Hidden Header Injection

When using email platforms like SendGrid or Mailchimp, hidden headers—like Received or Message-ID—can sneak into the DKIM h= tag during delivery, breaking the signature unless explicitly excluded. These headers are added by the provider before signing, so if you don’t configure the signing process to ignore them, your email may fail validation.

Headers Added by Providers Can Invalidate Signatures

You might not realize it, but services like SendGrid inject several headers during outbound delivery. These are part of the infrastructure, not your content. If your DKIM signature includes h=... values that cover these dynamically added fields, even a small change breaks the cryptographic check. Your email could end up in spam or rejected outright.

For example, a Received header added by a relay server may differ between recipients, making a static DKIM signature invalid. This is why proper h= alignment is not just a best practice—it's required for deliverability.

Configure Header Lists in Your Email Platform

Most platforms let you define custom header lists for DKIM signing. Look in your provider's documentation for terms like “DKIM header whitelist” or “header override.” You want to include only headers you control—like From, To, Date, Subject, and any custom headers—while explicitly excluding any automatic, non-deterministic fields.

Some providers, like SendGrid, allow you to specify a list of headers to sign. Others, like Mailchimp, use a fixed list but can be configured at the domain level. Always verify your configuration matches the actual headers in your message, especially if you’re using templates or automated workflows.

For deeper insight into how DKIM works and why header consistency matters, see RFC 6376, the foundational specification for DKIM. The standard explicitly requires that only a defined set of headers are signed, and that any addition or change must be accounted for in the signing process.

Proactively verify your emails before sending to catch DKIM misconfigurations. Use MailTester’s email checker to validate headers and signature alignment in real-world conditions. This helps avoid delivery failures before they impact your campaign.

Best Practices for Preventing Header Inclusion Errors

To prevent DKIM from including non-signing headers in the signature, you must sign only the headers you explicitly intend to include, in the exact order they appear. Use consistent casing, avoid adding unsigned custom headers, and filter out unnecessary ones before signing. This ensures your DKIM signature matches the final message, preventing verification failures.

Order and Naming Matter

  • Always sign headers in the same order they appear in the final email—changing order invalidates the signature.
  • Use lowercase for standard headers (from, subject, date, to) to avoid case-sensitive mismatches during verification.
  • Standardize header names across your email system to prevent inconsistencies caused by tools or libraries normalizing case differently.

Filter and Control What Gets Signed

  • Only sign headers you need to protect. Never include unsigned or transient headers like X-Message-ID or X-Original-To in the signature.
  • Use a pre-signature header filter to strip out any headers not meant to be part of the DKIM signature—this prevents accidental inclusion.
  • If you must add custom headers, explicitly include them in your signing list. Otherwise, they will be excluded from the signature, causing a mismatch.
  • Check your email delivery tools’ documentation; some frameworks automatically add headers that aren’t meant to be signed. Review the full header list before signing.

DKIM is strict about header order and content. A mismatched header—even one not in use—can cause rejection by receiving servers. For example, a widely used email infrastructure provider (like Google) will reject DKIM-signed mail if the signed headers don’t match the final delivered headers.

For validating your signing setup before sending to real users, test your email headers with Inbox Placement Testing, which shows how your message appears to major providers. You can check how your DKIM and SPF are seen in practice: test inbox placement and signature alignment.

How to Test Your DKIM Configuration Works Correctly

Use a known valid domain to send a test email, then examine the full header output. Check that the DKIM-Signature header has a h= tag listing only the headers you intended to sign—and ensure it passes verification. A mismatch here means unintended headers are being signed, which breaks validation. Use MailTester’s inbox-placement test to simulate real-world delivery conditions and confirm the signature is valid in practice.

Step-by-step verification checklist

  • Send a test email from a domain with a valid DKIM record using a trusted email client or SMTP service.
  • Access the full email headers—most email clients show this under "Show original" or "View source."
  • Locate the DKIM-Signature header and examine the h= field. It must list only the headers your signing key is supposed to cover (e.g., from:to:subject:date:content-type).
  • Ensure no unintended headers—like Received, DKIM-Signature, or Message-ID—appear in the h= list. These are not signed and are added after the signature is created.
  • Use MailTester’s inbox-placement test to verify the email delivers to inboxes and the DKIM signature passes under live conditions.
  • Review the result: a Pass status means your signing headers match exactly and no extra ones are included.
  • If you see h= mismatch, go back to your signing configuration. Confirm your mail server or email service is not including unintended headers in the signature scope. This is common with poorly configured MTAs or tools that auto-add headers.
  • For bulk testing, use MailTester’s bulk verification to check a list of domains or addresses for DKIM alignment issues at scale.
  • Use MailTester’s real-time API in your workflow to validate DKIM alignment before sending.

Why this matters

DKIM is only effective if it signs exactly the headers you control and nothing else. If the h= list includes headers that change across delivery (like Received), the signature will fail. The RFC 6376 specification explicitly states that only stable, predictable headers should be included. Misconfigurations lead to rejection by receivers—even if the domain is legitimate. A single misaligned header invalidates the signature. Use tools like MailTester's inbox-placement test to catch these issues before they degrade sender reputation.

Why DKIM Failures Hurt Deliverability

DKIM failures don’t just mean a technical glitch—they signal to Gmail, Outlook, and other major email providers that your sending practices aren’t reliable. Even one failed signature can lower your sender reputation, increasing the odds your emails land in spam or are blocked entirely. Reputable providers treat persistent DKIM issues as a red flag, especially when they’re tied to misconfigured headers like h= tags that include non-signing fields.

How DKIM Signatures Influence Inbox Placement

When a receiving server validates DKIM, it checks whether the headers listed in the h= tag were actually signed. If the signature doesn’t cover every header in that list, the check fails. This isn’t just a parsing error—it’s a credibility issue. Google’s research shows that consistent authentication failures correlate with lower inbox placement rates across their systems. Even if messages still deliver, reputation scores drop, making future campaigns more likely to be filtered.

Let’s say your system includes Received-SPF or Authentication-Results in the h= tag. If those headers aren’t included in the signature, the check fails. It’s like signing a contract but adding a clause that wasn’t in the final agreement. That mismatch triggers suspicion. Major email providers use such signals to assess sender trustworthiness. A single misconfigured h= tag might not block delivery—but repeated failures build up and eventually impact reach.

Fixing the Root Cause: Clean Sender Identity

Correcting the h= tag means aligning the list of headers in the signature with only those that are actually signed. You don’t sign Received or Authentication-Results—those are added by intermediaries after signing. Including them in h= breaks the chain. Properly configured DKIM ensures the receiver knows exactly what was signed. It’s not just compliance; it’s identity integrity.

Think of DKIM as your digital handshake. A failed handshake means the other party hesitates. With consistent failures, that hesitation turns into distrust. To maintain deliverability, your sending infrastructure must treat every header listed in h= as part of the signed payload. Any deviation creates risk. You can test this before sending with tools that check your full envelope, headers, and signature alignment.

Use the inbox placement tester to verify how your emails are received across real inboxes, including Gmail and Outlook. It checks for DKIM, SPF, and DMARC alignment, giving you a realistic picture of your sending health. Preventing h= mismatches isn't magic—it’s a matter of precision and consistency.

Conclusion: Clean Headers, Reliable DKIM

DKIM’s h= tag must list only the headers actually included in the signature. Any mismatch — especially including headers not signed — breaks the cryptographic validation.

Even a single non-signing header in the h= list can cause verification failure, leading to spam filtering, reduced inbox placement, and sender reputation damage.

Use MailTester’s real-time verification and inbox-placement testing to catch header misconfigurations before messages are sent. Consistent header control is not optional—it’s foundational to reliable email authentication.

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= tag do in DKIM?

The h= tag lists the header names that were included in the DKIM signature. Receiving servers verify that only those headers were actually signed.

Can I include any header in the DKIM h= tag?

Only headers that are actually signed must be included. Adding a header not in the signature causes a validation failure.

Why does DKIM fail even with valid keys and DNS records?

DKIM can fail due to mismatched headers in the h= tag, header encoding issues, or incorrect date/timestamps, even with correct keys.

How do email platforms affect DKIM h= tags?

Many platforms inject headers like X-Message-ID or X-Queue-ID. If these are in h= but not signed, DKIM fails unless explicitly filtered.

Can I use MailTester to check my DKIM configuration?

Yes. MailTester’s inbox-placement testing includes full header analysis and DKIM signing validation.

What happens if h= contains too many headers?

It can lead to signature rejection if any listed header wasn’t signed, even if only one is out of place.

Is there a maximum number of headers allowed in h=?

No technical limit, but each header must be valid, signed, and included in the correct order to pass validation.

How often should I audit my DKIM header list?

Before major campaigns or when adding new email tools. Audits help catch hidden header injection before delivery issues occur.

What’s the difference between SPF, DKIM, and DMARC?

SPF verifies sender IP legitimacy, DKIM authenticates the message content, and DMARC defines policy for handling failed authentication.

Can a single missing header break DKIM?

Yes. If a header in h= was not signed or was altered, the signature fails — even if only one header is incorrect.

Do all email providers check DKIM h= tags?

Yes. Major providers like Gmail, Outlook, and Yahoo validate h= to ensure message integrity and prevent spoofing.

Should I sign all headers in an email?

No. Only sign headers you control and that are relevant to the message’s authenticity. Signing unnecessary headers increases risk of failure.