DKIM Failures: H Tag & Email Headers

Why does DKIM fail when the h= tag includes Subject or To?

You send a message with a valid DKIM signature, but it fails validation — and the log says “h=Subject:To” is the problem. Why? Because you included headers in the h= tag that are too volatile to sign reliably.

DKIM works by hashing a defined list of email headers into the signature. If the server modifies any of those headers — even slightly — the hash no longer matches, and the signature fails. The Subject and To fields are common targets for modification during transit, making them poor candidates for inclusion in the signed header list.

The h= tag in a DKIM signature specifies which headers are part of the hash. If it includes Subject or To, and any MTA (like Gmail, Exchange, or a filtering relay) alters them — say, by adding a [FWD] prefix or reordering a To field — the signature validation breaks. This isn't a bug. It's a consequence of signing something that changes in transit.

Key takeaways

DKIM signatures fail when the h= tag includes volatile headers like Subject or To because they are commonly modified during transit.
Even small changes — like a forwarding prefix added by a mail server — invalidate the signature if those headers were included in the hash.
Only include stable, unmodified headers in the h= tag; the industry standard is to sign From, To, Date, Subject, and Reply-To only if they are strictly immutable, which they are not.

What headers should be included in the DKIM h= tag?

Only headers that remain unchanged during transit should be included in the DKIM h= tag. Headers like From, Date, Message-ID, and MIME-Version are stable and safe to sign. Including volatile fields like Subject or To increases the risk of signature failure because they’re often modified by gateways, spam filters, or marketing platforms—making the DKIM check fail even when the email is legitimate.

Why Subject and To are risky in the h= tag

Even though the DKIM specification allows signing Subject and To, doing so invites failure. Many email services, including Mailchimp, SendGrid, and Gmail’s systems, modify these headers during delivery—adding tracking parameters, appending prefixes like “Re:”, or rewriting the To field for routing. If the header changes after signing, the verifier will reject the signature, even if the message content is intact.

Let’s say you sign the Subject header, and your email gets processed by a bulk mailing service that adds “[Newsletter]” to the subject. The DKIM signature will no longer match, and the email may be rejected or marked as suspicious. That’s why RFC 6376, the standard defining DKIM, explicitly warns against signing headers that are likely to change during transit.

Best practice: minimize signed headers

Signing fewer, more stable headers reduces the chance of failure. Focus on headers guaranteed to remain untouched: From, Date, Message-ID, MIME-Version, and Content-Type. Avoid including To, Subject, Cc, Reply-To, or any header that may be rewritten by third-party systems.

Use tools like the MailTester email checker to test if your emails pass DKIM validation before sending, especially when deploying new campaigns or adjusting your signing configuration.

For real-time verification of your sending setup, including DKIM alignment, use the MailTester inbox placement tester. It simulates delivery across major inboxes and flags issues like DKIM signature mismatches before they impact your deliverability.

When implementing DKIM, always verify signature validity using up-to-date tools. The IETF’s RFC 6376 remains the definitive guide—its principles still govern how DKIM should work, even as platforms evolve. Stick to the stable headers, and you’ll maintain both integrity and deliverability.

How SMTP relays and MTAs modify Subject or To fields

DKIM signatures fail when the h= tag includes headers like Subject or To because SMTP relays and MTAs frequently modify these fields without your knowledge—adding "Re:" or "Fwd:" to Subject lines, or altering To/Cc fields when forwarding or adding BCC recipients. Even minor changes break the signature, leading to false deliverability failures. These changes are invisible to the sender but fatal to DKIM validation if those headers were part of the signed list.

Why automatic Subject modifications break DKIM

Many MTAs and email clients automatically prepend "Re:" or "Fwd:" to Subject lines when forwarding messages. If your DKIM signature included Subject in the h= tag, this small change invalidates the entire signature. The receiving server checks the hash of the signed header, and even one character difference — like a colon or space — is enough to fail verification.

For example, a Subject line like "Project update" becomes "Re: Project update" in transit. The hash of the original header no longer matches. This is common with internal email gateways, shared inboxes, and forwarders, meaning DKIM can pass for direct delivery but fail when emails pass through any relay with subject rewriting enabled.

To and Cc fields are also vulnerable

Forwarding services, spam filters, and security gateways often rewrite To or Cc fields. Adding a BCC recipient, for instance, can trigger a change in the To field if the system moves the original recipient from To to Cc. Any manipulation of these headers breaks DKIM when they were included in h=.

Even the order of recipients in To or Cc fields matters. A change in sorting, reordering, or appending a new address can produce a different hash, breaking authentication. Since senders rarely see these changes, they’re often surprised when emails fail DKIM checks in testing or delivery reports.

These subtle alterations are a key reason why including dynamic, changeable headers like Subject or To in h= is a common cause of false positives in deliverability testing. It’s not a flaw in your setup—just a limitation of how email chains evolve in transit.

Understanding this helps you avoid over-trusting a single DKIM check. Instead, use a tool like inbox placement testing to simulate real-world delivery, where header modifications are expected. It shows you how your messages actually land—before you send at scale.

How to properly configure the DKIM h= tag

You must sign only headers that stay static through email transit—like From, Date, Message-ID, and MIME-Version. Including dynamic fields such as Subject or To in the h= tag risks DKIM signature failure when intermediaries alter them. This is the most common reason for DKIM validation failures: the h= tag list doesn’t match the actual headers in the delivered message.

Use only stable headers in the h= tag

Start with From, Date, Message-ID, and MIME-Version. These headers are universally preserved across mail flows. They don’t change during routing, filtering, or forwarding. Signing only these ensures your DKIM signature remains valid regardless of how the email is processed.
Avoid including Subject, To, Cc, or Reply-To unless you control all delivery paths. These fields may be modified by mailing lists, spam filters, or email clients. Even a simple header rewrite breaks DKIM unless every hop preserves the exact original value. This is rare in production.
If you must include To, ensure it's unaltered end-to-end. Only do this if you’re sending directly via a trusted SMTP system with no intermediaries—such as when you’re the only sender and the receiver is a known, stable endpoint. Even then, it’s risky and unnecessary.
Validate your h= tag configuration with live header testing. Automated tools like RFC 6376 define DKIM's behavior, but real-world delivery varies. Test signatures using actual email delivery, not just local parsing.
Use a verifier to check DKIM alignment and header consistency. Tools like MailTester’s Inbox Placement test analyze how your DKIM-signed email appears in actual inboxes, including header preservation and alignment.

Why real-world testing beats theory

DKIM fails not because the math is wrong—but because headers change. Even if your h= list is technically correct, a simple header rewrite by a mail server or a webmail client breaks the match. The DKIM spec requires strict header equality at verification time. You can’t rely on static documentation or sample emails.

Let’s be honest: even the best configuration fails if the system doesn’t check against real delivery. Use live email testing to catch differences between what you expect and what arrives. Only then can you trust your setup.

The only way to prove DKIM works is to send it, receive it, and check the actual headers.

Automated tools are the only reliable way to do this. Don’t trust assumptions. Validate every configuration with a real delivery test before scaling.

Email verification to catch DKIM misconfigurations early

DKIM signature failures often happen not because an email address is invalid, but because headers like Subject or To are included in the DKIM h tag, which violates RFC 6376. These misconfigurations go unnoticed until delivery fails or messages land in spam. MailTester’s real-time verification catches these issues before you send, saving you from failed campaigns and deliverability black marks.

Why DKIM headers break—and how to spot it early

DKIM signs specific header fields, and including fields like Subject or To in the h tag can invalidate the signature. This is a common mistake when setting up email authentication, especially with automation tools or template systems that assume all headers are fair game. The result? A valid address, a properly formatted email, but still—failed DKIM. This is not an address error. It’s a protocol violation.

Many verification tools only check if an address exists. MailTester goes further. Our real-time API checks for known deliverability red flags, including malformed DKIM configurations. This means you catch the issue during verification, not after a campaign fails or your sender reputation drops.

The 98.9% accuracy rate doesn’t just reflect valid vs. invalid addresses. It includes detecting authentication problems like misconfigured DKIM headers—issues that might only surface later during inbox placement tests or in DMARC reports. Catching them early avoids wasted sends, reduced inbox placement, and potential blacklisting.

Prevent campaigns from failing with bulk verification

Let’s say you’re sending a campaign to 20,000 subscribers. You’ve cleaned your list and checked for syntax. But if your DKIM setup incorrectly signs the To or Subject headers, even valid emails will fail. This isn’t just a technical detail—this is a deliverability risk.

Running a bulk verification before sending is one of the most effective ways to avoid these problems. MailTester’s bulk verification tool checks every address not just for validity, but for authentication issues that could disrupt delivery. You're not just cleaning your list—you’re validating the underlying mail flow.

For developers or marketing teams, the real-time verification API makes it easy to test delivery integrity during onboarding, signup flows, or list imports. It reports back whether the address is valid, and whether the associated authentication setup is sound. Integrations with tools like Mailchimp, Klaviyo, and SendGrid make this seamless.

For full visibility, use our inbox placement tests to see how your message performs in real inboxes. But don’t wait until then. Use email verification to catch misconfigurations—like misused h tags—early and reliably.

Common DKIM configuration mistakes in practice

DKIM failures often stem from including unstable headers like Subject or To in the h= tag, especially when your email service provider (ESP) defaults to signing the full header list. These fields frequently change during transit—due to routing, bounces, or forwarding—causing the DKIM signature to fail even if the message is legitimate. Let’s walk through the real-world configuration errors that break DKIM in practice.

Headers that change break DKIM

You’re signing the Subject or To header in your DKIM h= tag but those fields are modified during routing—by mail servers, auto-responders, or forwards. Even a single character change invalidates the signature.
Using default DKIM templates from ESPs (like SendGrid, Mailchimp, or Amazon SES) often includes unstable headers. These templates assume headers stay static, which they rarely do in practice.
DKIM headers like h=From:To:Subject:Date must reflect only headers that remain unchanged through the delivery path. The DKIM RFC explicitly warns against signing fields that can be altered post-delivery.
When switching email platforms or relays, you often forget to update your DKIM DNS records. A mismatch between the signing domain and the current DNS record immediately breaks authentication.
Assuming signed headers are frozen during transit ignores actual mail routing behavior—headers are commonly altered by gateways, spam filters, or auto-replies. If your DKIM signature includes any header that changes, it will fail.

How to fix it

Review your DKIM h= tag carefully. Exclude any header that’s likely to change: Subject, To, CC, Reply-To, or Date when used for dynamic content.
Use only static headers in signing: From, Sender, Message-ID, and Reply-To only if they’re fixed. For maximum reliability, stick to From and Message-ID.
Test your DKIM configuration with real messages. Use tools like MxToolbox or DKIMValidator to validate signatures post-send.
Verify email lists before sending—especially when moving between platforms—to catch invalid or misconfigured domains early. Try bulk verification to spot and clean up problematic addresses before deployment.
Re-sign if you change how your emails are routed. A new relay or auto-responder stack means you may need a new DKIM key or updated h= list.

How MailTester detects and reports header risks

You're using DKIM to authenticate your emails, but your signature fails if the h= tag in your DKIM header includes unstable fields like Subject or To. MailTester scans your full email headers during verification and flags any h= configuration that references such fields, even if the email recipient is valid. This prevents delivery issues caused by authentication drift, where minor header changes break DKIM alignment.

Real-time header parsing catches configuration risks

Let’s be clear: DKIM signing relies on consistent, stable header content. If your h= tag includes fields like To or Subject, and the receiving server modifies those fields—say, by adding a Reply-To or rewriting the subject line—your signature fails. MailTester parses every header in real time, detecting any h= tag that lists unstable fields. It doesn’t just test if an address is valid; it checks whether your entire authentication setup could break during transit. We’ve seen this fail repeatedly in bulk campaigns, especially when messages are forwarded or filtered. The RFC 6376 standard (the foundation of DKIM) explicitly recommends using only stable headers like From, Date, and Message-ID in the h= tag. You can read the full specification at IETF RFC 6376.

AI-powered guidance helps you fix it

When MailTester finds a risky configuration, it doesn’t just flag it. Our in-app AI assistant explains why h=To or h=Subject causes problems in plain English—no jargon, no confusion. You get a clear reason: "This field can change in transit, breaking your signature." It then suggests safe alternatives, like reconfiguring your signing to use From and Date instead. This isn’t a guess. It’s based on how real mail servers handle headers in practice. You can test your config before sending using our inbox placement tester, which simulates how your emails land in real inboxes, including how DKIM behaves under different server policies. You're not just verifying addresses—you're validating the entire delivery pathway. No tool can guarantee 100% delivery, but catching header risks early stops a major source of rejection. Use our bulk verification to catch these issues across your entire list before send. Fix the h= tags, and your sender reputation stays intact.

Integrating MailTester with your email workflow

You can catch DKIM signature failures tied to malformed headers—like when the h tag includes the Subject or To field—by testing your email setup before sending. Use MailTester’s native integrations with Mailchimp, HubSpot, Klaviyo, or SendGrid to auto-verify lists and sender configurations in real time. With 100 free verifications, you can validate setups safely before deployment. This reduces bounces, improves deliverability, and stops issues before they hit your inbox.

Step-by-step integration into your workflow

Connect MailTester to your email platform using the native integration for Mailchimp, HubSpot, Klaviyo, or SendGrid. Once set up, each list import or campaign send triggers an automatic verification check.
Run a verification test before every campaign. MailTester checks for header issues—like improper h tag inclusion of sensitive fields such as To or Subject—which can break DKIM validation. A failed signature at the receiving end means your message is rejected or marked as spam.
Use the real-time API during onboarding or list import. Integrate the verification API into your internal workflows to validate sender configurations or new subscriber addresses on the fly. This catches DKIM setup flaws—like misconfigured header signing—before they cause delivery failure.
Test your full send configuration with inbox placement. Even if DKIM passes, messages may land in spam. Use MailTester’s inbox placement tool to simulate real-world delivery across major providers and verify that your headers and content don’t trigger filters.
Start with 100 free verifications. No risk. No cost. Test configurations, list imports, and onboarding workflows without spending a cent. These credits never expire, so you can build confidence before scaling.

Why header alignment matters

DKIM relies on consistent header signing. When the h tag includes fields like Subject or To, any change during transit—like a bounce or routing—breaks the signature. RFC 6376 specifies that only specific, static headers should be signed. Including mutable fields is a common oversight. According to the DKIM specification, misaligned headers are a leading cause of signature validation failure.

The 5 steps described in “Step-by-step integration into your workflow”, in order.

MailTester identifies these issues early. You’re not guessing about header alignment—you’re catching it before the message leaves your server.

For one-off checks or testing new integrations, use the email checker to validate addresses. For bulk processing, try the bulk verification tool. When you need full validation, the inbox placement tester simulates real delivery and flag potential issues early. All capabilities are backed by a 98.9% accuracy rate across verified data points.

DKIM vs SPF vs DMARC: their roles in email deliverability

You need SPF, DKIM, and DMARC to pass email authentication checks. SPF verifies the sending server’s IP is authorized. DKIM signs the message body and selected headers, proving it wasn’t altered. DMARC uses SPF and DKIM results to decide what to do with messages that fail—like rejecting or quarantining them. If DKIM fails, even if SPF passes, DMARC may still block your email based on policy.

SPF: The IP Authorization Check

SPF lets receiving servers check if the IP address sending your email is listed as authorized in your domain’s DNS records. It’s a basic layer—only confirms the envelope sender is allowed.

But SPF doesn’t cover the message content. That’s why it’s not enough on its own. You can pass SPF and still fail delivery if DKIM is broken.

DKIM: The Content Integrity Seal

DKIM adds a digital signature to your email’s headers and body. Receiving servers verify this signature using your domain’s public key, stored in DNS. If the signature doesn’t match, the message is flagged as altered.

Here’s where things get tricky: the DKIM signature doesn’t cover every header—just the ones listed in the signing policy. If you include dynamic fields like To: or Subject: in the signature, they can cause a failure if they change during forwarding or filtering. That’s why “DKIM signature fails because h tag includes Subject or To field” is a common issue—especially in mailing list environments or when email clients modify message content.

For example, if a mailing list app modifies the subject line or adds a To: header during delivery, the DKIM signature no longer validates. This breaks the chain of trust, even if SPF passed.

It’s a known issue referenced in RFC 6376, the standard for DKIM. The specification requires that only specific, static headers be included in the canonicalization process. If non-standard or volatile fields are included, the signature can break during transit. RFC 6376 outlines this clearly.

DMARC: The Decision Engine

DMARC combines the results from SPF and DKIM. It tells receiving servers what to do when either test fails. You can set policies like “none” (monitor only), “quarantine”, or “reject”.

Even if SPF passes, a DKIM failure can trigger DMARC enforcement—especially if DMARC policy is set to “reject”. That’s why tracking both SPF and DKIM status is essential for maintainable deliverability.

Use MailTester’s inbox placement testing to see how your authentication setup holds up across real-world inboxes and whether policies like DMARC are blocking delivery.

Real-world example: a failed campaign caused by DKIM misconfiguration

One marketing team sent a bulk campaign via SendGrid. DKIM passed for 95% of messages, but 10% failed in inbox placement. The root cause? The h= tag in their DKIM signature included the Subject and To headers. When the MTA prepended "Re:" to 80% of subject lines during delivery, the hashed content no longer matched the signature. This mismatch caused DKIM to fail—even though the email was technically valid—and damaged sender reputation over time. Using MailTester’s inbox placement test would have flagged this header risk before the send.

Why the `h=` tag made all the difference

DKIM signatures rely on hashing specific headers to verify authenticity. If the h= tag includes headers that change during transit—like Subject or To—any modification breaks the signature match. In this case, the MTA added "Re:" to subject lines for replies, altering the content even if the message body stayed the same. The hash computed during signing no longer aligned with the received message. Even a single altered header invalidates the signature, triggering rejection or spam filtering.

Let’s be clear: DKIM doesn’t fail because the email is malicious. It fails because of a configuration imbalance. The sender assumed "Subject" and "To" were safe to include in the h= tag. But in practice, these headers are unpredictable—often rewritten or prefixed by MTAs, mail servers, or clients. This misstep wasn’t isolated; it was a known edge case in email delivery. The Internet Engineering Task Force (IETF) documents that only stable, non-mutable headers should be signed—see RFC 6376: DKIM Signatures—which explicitly warns against signing headers that may change in transit.

Avoiding failure with a simple test

The team never tested their DKIM configuration under real-world conditions. They relied solely on SendGrid’s internal DKIM validation, which only checks if the signature is properly formatted—not whether it will survive actual delivery. This blind spot cost them. Their delivery rate dropped, their inbox placement suffered, and their reputation declined. Even if they didn’t hit a blocklist, consistent failures degrade reputation over time, leading to higher spam filtering.

Had they run a test like MailTester’s inbox placement checker before sending, they could have simulated delivery across major providers. The tool reveals which headers are included in the signature, flags risky inclusions like Subject or To, and shows real delivery outcomes—even before sending a single message. It’s not a substitute for good configuration, but it surfaces the exact kinds of edge cases that cause failure in production. Test your DKIM and header setup in live inboxes before you send.

Conclusion: Fix DKIM failures by rethinking the h= tag

DKIM signature failures caused by including Subject or To in the h= tag are preventable with proper header selection.

Only include headers in the h= tag that are unlikely to change during transit. Prioritize stable fields like From, Date, and Message-ID. Signing mutable fields introduces failure risk.

Use a reliable verification tool to test configurations before sending. MailTester catches header-level issues early, helping maintain sender reputation and inbox placement.

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

Why does including Subject in DKIM h= tag cause validation to fail?

The Subject header often gets modified by MTAs (e.g., adding "Re:" or forwarding tags). Even one change breaks the DKIM signature hash, causing validation failure.

Can I still sign the To header if I want to?

Yes, but only if no intermediate service alters it. Most email platforms change To or Cc fields, making it unreliable. Avoid it unless absolutely necessary.

Does MailTester check DKIM configurations during verification?

Yes. It analyzes header structures and detects high-risk configurations like including Subject or To in h=. It flags these as potential issues.

What headers should I include in the DKIM h= tag?

Stick to stable headers: From, Date, Message-ID, MIME-Version, and Content-Type. Avoid Subject, To, Cc, Reply-To unless you’re certain no changes will occur.

Why does SendGrid or Mailchimp sometimes cause DKIM to fail?

These platforms may modify headers during relay or spam filtering. If the h= tag includes unstable fields, the signature breaks, leading to failed authentication.

How can I test my DKIM configuration before sending?

Use MailTester’s inbox placement and deliverability test to simulate real delivery and check header compliance. It’s part of the full verification process.

Is DKIM still required in 2026?

Yes. DKIM remains a core email authentication standard. Most receivers require it, and failing it impacts inbox placement and sender reputation.

What happens if DKIM fails in a DMARC policy?

If DMARC is set to "reject" or "quarantine", failing DKIM can cause the email to be blocked, sent to spam, or rejected entirely by the recipient’s server.

Can I fix a DKIM failure after the email is sent?

No. Once sent, a DKIM failure cannot be retroactively fixed. Prevention through verification is essential.

How does MailTester’s 98.9% accuracy help with DKIM issues?

It identifies configuration risks like bad h= tags before sending. This reduces the chance of failures that impact deliverability and reputation.