DKIM h= Tag Error & Deliverability

What causes a DKIM h= tag error in email authentication?

You’ve checked the SPF, set up DMARC, and even tested inbox placement—yet your emails still land in spam or bounce silently. The culprit might be hiding in plain sight: a DKIM h= tag error.

DKIM signs specific parts of an email header using the h= tag. If that tag lists a non-signable header—like a custom tracking parameter or dynamically generated metadata—the signature fails, even if the email is valid. This can silently hurt deliverability without any obvious warning.

Understanding how the h= tag works, and why including the wrong headers breaks the signature, isn’t just technical trivia. It’s critical when your campaign relies on inbox placement and sender reputation.

Key takeaways

The DKIM h= tag specifies which headers are signed, and must exclude non-signable fields like custom or auto-generated metadata.
Including dynamic or non-standard headers in the h= list causes signature validation to fail, even if the email body and core headers are correct.
Common causes include tracking parameters added by marketing platforms, automated systems, or poorly configured email services that inject non-signable headers into the signing list.

Why is a DKIM h= error with non-signable headers a deliverability risk?

DKIM h= errors occur when your email’s signing process references headers that aren’t meant to be signed—like MIME version, content-type, or encoding fields—causing validation to fail. Even if SPF and DMARC pass, Gmail and Outlook will reject or flag the message. This failure breaks trust with receiving servers, erodes your sender reputation, and significantly increases the chance your emails land in spam folders or get rate-limited.

How DKIM failures break trust with email providers

Receiving providers like Google and Microsoft use DKIM as a core signal of authenticity. When a message fails DKIM—especially due to incorrectly signed headers—the provider treats it as a red flag, even if SPF and DMARC are valid. These systems assume that misconfiguration can indicate either poor technical setup or, worse, an attempted spoofing attempt.

Repeated DKIM failures don’t just result in hard bounces. They can slowly degrade your sender reputation score. Over time, this lowers trust, making it harder to land in inboxes. The same servers that once sent your emails to the primary inbox now treat your traffic with suspicion.

The real-world consequences of ignored DKIM errors

When a DKIM h= error persists, even with correct SPF and DMARC, you may face greylisting—where the receiving server delays delivery to verify legitimacy. In severe or repeated cases, domain-based rate limiting kicks in, reducing the number of emails you can send per hour. Some providers may even permanently block your mail server or IP if the behavior continues.

According to the DMARC specification (RFC 7208), “DKIM-Signature headers must only sign specific, defined headers.” When the h= tag incorrectly references non-signable fields—like those in the MIME structure—validation fails. This isn’t a minor glitch; it’s a structural break in the email’s cryptographic chain.

Let’s be clear: you can’t rely on SPF and DMARC alone. They’re not enough. A single misconfigured DKIM signature with an invalid h= tag can trigger a cascade of deliverability issues. Use your email verification tool to catch these issues before they hit the inbox.

Test your inbox placement and DKIM compliance directly in real inboxes across Gmail, Outlook, Apple Mail, and more. Catch problems like misaligned DKIM headers before they affect your delivery.

How does a non-signable header break the DKIM h= tag?

When a DKIM signature includes a header in the h= tag that’s either missing, altered, or stripped during transit—like a custom X-Tracking-ID or a URL parameter such as ?source=webhook—the verifier expects that exact header to exist exactly as listed. Any mismatch, even a case difference or whitespace change, causes the signature to fail. Since DKIM requires an exact match between the signed headers and the ones in the final message, including non-signable or transient headers in the h= list is a common cause of deliverability problems.

The h= tag lists headers by name—exactly as they appear

DKIM’s h= tag specifies which headers are included in the signature, using names in lowercase and without leading or trailing spaces. It’s case-insensitive, but the values must match exactly. If your email service adds or modifies a header like Disposition-Notification-To or strips a tracking parameter like ?utm_source=api before sending, but the h= list still references it, the signature will fail during validation.

For example, if h=from:subject:x-tracking-id is included in the signature but your ESP removes X-Tracking-ID before delivery, the verifier sees the header as missing. The signature is no longer valid—even if the From and Subject are intact—because the header list doesn’t match.

Why non-signable headers cause signature mismatches

Headers like X-Tracking-ID, Return-Path, or Received are often added or changed by MTAs, ESPs, or inbox providers. They’re not part of the original message and can’t be reliably signed. Including any such non-signable or transient header in the h= list makes the signature unpredictable and prone to failure. Many deliverability issues stem from this oversight.

DKIM’s requirements are strict: both the header names and values must match byte-for-byte. Even a single space, a line break, or a case difference breaks the signature. This is why it’s critical to review your h= list and verify that every listed header actually appears in the final email. Tools like RFC 6376 define these rules precisely, and violating them undermines your sender reputation.

Let’s not overlook the basics: if you’re sending email at scale, ensure your signing process only includes headers that remain unchanged from your original content to delivery. Use tools like MailTester’s email checker to validate that the signed headers are both present and unaltered in the final message—before sending, not after.

Detect DKIM h= tag errors before sending with real-time testing

You can catch DKIM h= tag errors—like misordered headers, missing signable fields, or non-signable header conflicts—before they hurt your deliverability. MailTester’s inbox-placement test simulates how major providers like Gmail, Outlook, and Yahoo validate your full DKIM signature, including the h= tag structure and header alignment. Run this test in staging, not after delivery.

How real-time testing surfaces DKIM h= tag issues

Use MailTester’s inbox-placement test to simulate real-world validation across multiple email providers—Gmail, Outlook, Apple Mail—before sending.
Test your full email header structure, including the h= tag, to ensure signable headers are properly listed and in the correct order.
Check for non-signable headers (like Received, Authentication-Results, DKIM-Signature) that shouldn’t be included in the signature—these break alignment and cause fails.
Verify header order isn’t altered during transport; even small changes like extra line breaks or missing CRLF can trigger signature mismatches.
Run tests on draft emails in your staging environment, not in production—find the error before it hits a real inbox.

Why timing matters for DKIM alignment

DKIM failure rates spike when headers are rearranged post-signing or when non-signable fields are unintentionally included. The DKIM specification requires strict header alignment—any deviation breaks the signature. Most providers check both the h= tag and the body hash, so a single misaligned field can invalidate the entire signature.

Let’s say your campaign sends with a DKIM h=From:To:Subject: but the actual email header order is Subject:From:To:. The alignment fails, even if the public key is valid. MailTester detects this at test time—no need to wait for bounces or spam complaints.

Proper DKIM alignment isn’t optional. It’s required for consistent inbox placement and sender reputation. Use real-time API verification in your workflow to catch these issues automatically before every send.

Steps to fix the DKIM h= tag error with non-signable headers

When your DKIM signature shows an h= tag error, it means one or more headers listed in the signature are missing, altered, or dynamic in transit—breaking validation. You must ensure every header in the h= list is stable and preserved from send to inbox. Remove non-signable headers like custom or session-based fields, then re-sign only with predictable, unchanging headers such as From, To, Subject, Date, and Message-ID. Test your revised signature using a tool like MxToolbox or verify it live with MailTester’s API before going to production.

Identify and validate the headers in your DKIM signature

Inspect your DKIM-Signature header (e.g., DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; h=from:to:subject:date:message-id;). Every header listed after h= must be present in the final message and unchanged during transit.
Check if any headers in the h= list are dynamic—such as X-Tracking-ID, Authentication-Results, or Content-ID. These often change during routing or are stripped by email gateways, causing signature failures.
Remove any non-signable or volatile headers from the h= list. Only include standard, immutable headers: From, To, Subject, Date, and Message-ID are reliably preserved across systems.
Re-sign your message using only these stable headers. This ensures the signature remains valid no matter which mail server processes the email.
Verify the new signature with a tool like MxToolbox’s DKIM debugger or MailTester’s real-time verification API, which can validate the full DKIM structure and detect signature inconsistencies before deployment.

Best practices to prevent future issues

Use a consistent canonicalization method (usually relaxed for both header and body) to tolerate minor formatting changes. Always test your DKIM setup on multiple providers and inbox types—especially with Gmail, Outlook, and corporate gateways. The DKIM RFC 6376 defines how signatures must be validated, including strict header preservation requirements.

Let’s be clear: DKIM is not just an authentication tool—it’s a trust signal. A broken signature weakens your sender reputation and increases the odds of your email landing in spam or being rejected entirely. Fixing the h= error is a non-negotiable step in maintaining inbox placement and deliverability.

Which headers are typically non-signable and should be excluded?

You should exclude headers like X-Tracking-ID, X-Mailer, X-Message-ID, List-Id, Precedence, Auto-Submitted, MIME-Version, Content-Type, Content-Transfer-Encoding, and User-Agent when signing emails with DKIM. These headers often change per message or are added by mail clients, making them non-signable. Including them in the DKIM signature causes a h= tag error, leading to failed authentication and poor deliverability.

Why these headers break DKIM signing

DKIM requires a consistent set of headers to be signed. If a header isn’t fixed across all messages (e.g., X-Tracking-ID or User-Agent), the signature will fail on delivery. The receiving mail server checks that the signed headers match the ones sent, and any mismatch — even a minor one — invalidates the signature.

Headers like MIME-Version and Content-Type are technically signable but are usually excluded by convention. They don’t carry sender identity or content authenticity value, and their presence can trigger h= mismatches if altered by forwarders or email services.

Standard list of non-signable headers and how to handle them

Here’s a practical list of commonly non-signable headers you should not include in the DKIM signature:

X-Tracking-ID – Added by analytics tools. Changes with every send.
X-Mailer – Identifies sending tool; varies by client.
X-Message-ID – Unique per message; not standardized.
List-Id – Changes with mailing list or campaign.
Precedence – Set by user or system; unpredictable.
Auto-Submitted – Set by autoresponders; inconsistent.
MIME-Version – Always present, but not necessary to sign.
Content-Type – Can change due to encoding or rendering.
Content-Transfer-Encoding – Varies by MIME encoding.
User-Agent – Reflects user’s client; highly variable.

Item	Details
X-Tracking-ID	Added by analytics tools. Changes with every send.
X-Mailer	Identifies sending tool; varies by client.
X-Message-ID	Unique per message; not standardized.
List-Id	Changes with mailing list or campaign.
Precedence	Set by user or system; unpredictable.
Auto-Submitted	Set by autoresponders; inconsistent.
MIME-Version	Always present, but not necessary to sign.
Content-Type	Can change due to encoding or rendering.
Content-Transfer-Encoding	Varies by MIME encoding.
User-Agent	Reflects user’s client; highly variable.

The 10 items listed under “Standard list of non-signable headers and how to handle them”, side by side.

These are the headers that are typically excluded from DKIM signing. RFC 6376, section 3.6, outlines that only headers listed in the h= tag are included in the signature, so you must ensure that list aligns with headers that remain constant.

Let’s not forget: even if you’re using a tool like MailTester's email checker to validate addresses, the DKIM setup remains your responsibility. A single wrong header in the h= tag can still block delivery, despite a valid address. Always review your DKIM header list in the email headers sent to your inbox or use a mail trace tool like MxToolbox to verify the signature match before launch.

What does a failed h= tag mean during DKIM validation?

When a DKIM signature includes an h= tag, the receiving server checks that every header listed in it is present in the exact form it was when signed. If any header is missing, altered, or even differs in case (like From vs from), the signature fails. This failure doesn’t just trigger a bounce—it’s logged by the recipient, and repeated issues slowly damage your sender reputation, harming long-term deliverability.

How the h= tag works in practice

Let’s say your DKIM signature lists h=from:to:subject:date. The receiving server will verify that those four headers exist and haven’t changed from the original message. Even minor changes—like a newline in the Date header, or a capitalization tweak—break the signature.

This is why headers like Received or Return-Path are typically excluded from the h= list. They’re added by mail servers during transit and can’t be trusted as static. If your signing process includes headers that are modified during delivery, the failure is inevitable.

Why repeated failures hurt your sender reputation

Each failed DKIM validation is recorded by the recipient’s system. If you send to a domain that performs strict filtering (like Gmail, Yahoo, or Microsoft), repeated DKIM issues are flagged and used in their reputation scoring. A consistent pattern of h= tag mismatches tells them your sending infrastructure isn’t reliable—this reduces inbox placement over time.

While a single failure might not cause an immediate block, consistency matters. The same behavior that triggers a temporary bounce today may, over weeks, lead to inbox filtering or outright rejection. This isn’t just about one email—it’s about your brand’s credibility in the eyes of spam scoring systems.

You can test whether your emails are properly signed by using a real-time verification tool. MailTester checks DKIM, SPF, and header alignment before you hit send—helping you catch issues like incorrect h= tags early. Try a real-time check on a single address to see how your setup holds up: verify a single email address.

For more details on how DKIM works and what header fields are safe to include, refer to the official specification at RFC 6376. This document outlines the precise requirements for signature validation, including the role of the h= tag in ensuring header consistency.

When your signing process includes only stable, immutable headers, you reduce the risk of failure. This is especially important when using third-party tools or ESPs that may add headers. Always audit your signing setup to ensure the h= tag reflects only headers unchanged from when the signature was created.

How to test your email’s DKIM header alignment in real time

You can test DKIM header alignment—including h= tag errors and non-signable header inclusion—within seconds using MailTester’s real-time verification API. The API analyzes your email’s full authentication stack, flags misaligned headers, and shows if non-signable headers like Received or Message-ID were mistakenly signed, all without manual parsing.

Run a live DKIM header alignment test in under 2 seconds

Send a sample of your email (raw message or MIME) to MailTester’s real-time verification API at https://mailtester.com/api-email-checker/.
Within 1–2 seconds, receive a full breakdown of SPF, DKIM, and DMARC alignment status.
Check for h= tag mismatches by comparing the listed headers in the DKIM signature’s h= field against the actual headers in your message.
Look for non-signable headers (such as Received, Message-ID, Date) included in the signed list—these cause DKIM verification failures, even if the signature is technically valid.
Use this data to adjust your signing configuration before sending to production lists.

Why this matters for deliverability

DKIM signatures with incorrect or mismatched h= tags—especially when they include non-signable headers—are flagged by receiving mail servers as suspicious. Even small misalignments can reduce inbox placement rates, especially with strict filters used by Gmail and Outlook.

DMARC aligns authentication results only if both SPF and DKIM pass and the domain in the from header matches. A DKIM h= mismatch breaks that alignment, triggering rejection even if the signature is cryptographically sound. This is why RFC 6376 (the DKIM standard) explicitly prohibits signing non-signable headers.

Testing early with a tool like MailTester helps catch these issues before they impact sender reputation or cause hard bounces. This is an industry-standard practice for any senders operating at scale.

For teams using SendGrid, Mailchimp, or HubSpot, integrating MailTester’s API allows automatic verification during onboarding or campaign setup—ensuring only valid, properly structured mail gets sent.

Once you identify the source of the h= tag error—whether it’s a misconfigured signing library, a tool adding extra headers, or a script not filtering non-signable ones—you can fix it in code or your email platform’s settings.

How MailTester helps prevent DKIM issues before email sends

You don’t need to wait for bounces or inbox placement failures to find out your DKIM signature is flawed. MailTester’s inbox-placement testing catches DKIM h= tag errors, header order issues, and missing essential headers before you send — simulating real delivery through Gmail, Yahoo, Outlook, and other major providers. It gives you a full signature audit, not just a pass/fail, so you fix root causes, not symptoms.

Spot DKIM issues early, before they hurt your sender reputation

MailTester’s Inbox Placement Test sends a real message through major email providers' filters — including Gmail, Yahoo, and Outlook — to assess how it would be received in real-world conditions.
It flags DKIM signature problems like incorrect h= tag values, header order mismatches, or missing required headers such as From, To, or Date that break the verification chain.
Unlike tools that just say "valid" or "invalid," MailTester shows you exactly which header is out of order, which one is missing, or which one was signed incorrectly — so you know what to fix.
It checks the full signature chain, including DKIM alignment (SPF/DKIM/DMARC), validating that the h= tag properly covers all signed headers and that they match the actual message body.
For instance, if your email includes a Reply-To header that wasn’t included in the signature, MailTester will detect that misalignment — a common cause of delivery failures.

Seamless integration with your email workflow

Integrate MailTester directly with SendGrid, Mailchimp, Klaviyo, or HubSpot to validate every email before it leaves your system — no manual checks required.
Use the real-time verification API to check DKIM headers at scale, ensuring your entire list meets technical standards.
Automate inbox tests for every campaign, or use the inbox-placement tester to simulate delivery on a per-message basis before you send.
With over 98.9% accuracy, MailTester helps you avoid reputation-damaging failures due to misconfigured DKIM, especially when sending to sensitive domains or high-volume campaigns.
Refer to the DKIM specification (RFC 6376) to understand how the h= tag works and why header ordering matters in practice.

Pro tip: Avoid over-signing headers to reduce DKIM failure rates

Only include headers in your DKIM h= tag that are stable across every message—like From, To, Subject, and Date. Including dynamic fields (e.g., campaign IDs, session tokens) causes DKIM validation to fail, even if the message is legitimate. This undermines your sender reputation and increases inbox placement risk.

What to include in the DKIM `h=` list

Stick to headers that remain unchanged across all sends: From, To, Subject, Date, Message-ID.
If you use Reply-To, include it only if it's consistently applied and does not vary per send.
Never include headers with temporary or session-specific values—such as X-Campaign-ID, X-Session-Token, or Track-Click-ID.
DKIM validation fails if the signed header’s value differs between signing and verification. A dynamic value breaks the math.

Why over-signing hurts deliverability

When your DKIM signature includes unstable headers, the receiving server sees a mismatch during validation—even if other parts of the message are correct. Some providers treat this as a sign of misconfiguration or potential spoofing, which can lead to increased spam filtering or reduced trust from mailbox providers.

Per standards, DKIM signatures should only cover content that’s consistent. The DKIM RFC states that signing unstable fields defeats the purpose of authentication. It’s not just about compliance—it’s about maintaining sender reputation over time.

Let’s be clear: you’re not protecting your emails by including more headers. You’re increasing the odds that a single variable breaks the entire signature. That’s why email verification isn’t just about catching invalid addresses—checking for valid, stable headers in your outbound messages is another layer of protection.

Use tools like inbox placement testing to validate how your messages land across inboxes, including whether DKIM verification passes. It’s not enough to sign headers—your signing strategy must align with real-world email routing logic.

Keep your sender reputation healthy by fixing h= tag errors

DKIM h= tag errors caused by non-signable headers are a frequent technical hurdle that leads to email rejection or spam filtering. These failures often go unnoticed until deliverability drops, making proactive detection critical.

MailTester identifies these issues before they impact your campaigns, reducing bounce rates and improving inbox placement across Gmail, Outlook, and other major providers. Real-time verification and bulk list checks ensure your sender reputation stays intact.

With 98.9% accuracy, MailTester minimizes false positives and ensures no risky emails slip through. You’re not penalized by missed errors or unnecessary rejections.

Sources

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)
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)

Keep reading

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

Frequently asked questions

What is the DKIM h= tag?

The h= tag in a DKIM signature lists the headers of an email that were included in the digital signature. It defines the order and names of the headers that must remain unchanged during transit for validation to pass.

Can a header be non-signable and still be included in h=?

No. Including a non-signable header—such as one that changes per send or is not standardized—in the h= list causes DKIM to fail unless the value is guaranteed to be identical across all messages.

Why does DKIM fail if a non-signable header is in the h= list?

DKIM requires exact header names and values to match the ones signed. If a dynamic or non-existent header is included in the h= list, the receiving server finds a mismatch and rejects the signature.

How can I find which header is causing a DKIM h= error?

Inspect the DKIM-Signature header in the email source. Compare the h= list with the actual headers in the message. Any in the h= list that are missing or altered is the culprit.

Does MailTester test DKIM alignment?

Yes. MailTester’s inbox-placement testing includes full DKIM signature validation, checking alignment, h= tag accuracy, and header presence.

Can SPF or DMARC fix a DKIM h= error?

No. SPF and DMARC do not validate DKIM signatures. A DKIM failure due to h= issues will not be resolved by SPF or DMARC, even if those records are correct.

Why is DKIM important for deliverability?

DKIM verifies that the email was not altered in transit and confirms the sender's identity. A failed DKIM signature lowers sender reputation and increases the risk of being marked as spam.

Is it safe to remove headers from h= during DKIM signing?

Yes, if the removed headers are non-signable or dynamic. Only include headers that are stable and consistent across all messages to prevent signature failure.

Does MailTester support bulk DKIM testing?

Yes. Use MailTester’s bulk list verification or real-time verification API to scan multiple emails for DKIM issues, including h= tag errors, across different sending domains.

Are non-standard headers always non-signable?

Not always, but they are often dynamic or not guaranteed to be present in every email. Use only standard, stable headers for DKIM signing to ensure reliability.

How often should I test DKIM configuration?

Test every time you update your sending infrastructure, change email templates, or modify the signing process. Regular testing prevents deliverability issues before they impact campaigns.

What is the benefit of using MailTester’s AI assistant for DKIM issues?

The AI assistant analyzes email source code and flags problematic h= tags, missing headers, and non-signable entries in real time, offering actionable fixes without manual inspection.