Correcting DKIM h= Tag to Exclude Unsupported Fields for Better Deliverability

Why is your DKIM h= tag hurting email deliverability?

You sent a perfectly valid message. The content is clean. The sender reputation is solid. But it still bounced—or landed in spam. You double-checked SPF and DMARC. Everything looks correct. Then you realize: your DKIM h= tag might be the silent culprit.

The h= tag defines which headers are included in the DKIM signature. If you’re signing non-standard or unsupported headers—like custom tracking tags, X- headers, or obsolete fields—strict receivers may reject the signature entirely. Even one misaligned header can break validation. Correcting the h= tag to exclude unsafe or irrelevant fields boosts consistency, reduces failures, and keeps mail out of junk folders.

Key takeaways

• Malformed DKIM h= tags that include unsupported headers cause validation failures even with legitimate emails.
• Receivers like Gmail and Microsoft perform strict header checks—only signing essential, standardized headers improves deliverability.
• Manually refining the h= tag to exclude fields such as X- or custom tracking headers reduces bounce risk and improves inbox placement.

How does the DKIM h= tag work in email authentication?

The DKIM h= tag specifies which email headers are included in the cryptographic hash used to verify an email’s authenticity. Only headers listed in h= are checked by the receiving server; if a listed header is missing or malformed, the signature fails. This matters most when automated systems add dynamic headers not present during signing, a common issue in transactional email workflows.

Why header listing in h= affects deliverability

Let’s say you sign an email with headers like From, To, and Date in your h= list. If a service later adds a custom X-Message-ID header, it’s not in the hash — that’s fine. But if your h= includes Received and a system dynamically adds a Received: header during transmission, the receiving server expects it to be present and unchanged. If it's altered or missing, DKIM validation fails, even if the content is correct.

This is especially common in large-scale email setups using tools that insert headers like Precedence, Thread-Index, or DKIM-Signature as part of routing or tracking. Each one must be explicitly accounted for in the h= list — or excluded entirely. Including unsupported or dynamically added headers without accounting for their variability is a leading cause of DKIM failures.

How to fix h= when headers change unpredictably

If you’re seeing consistent DKIM failures, audit your h= list against actual headers in delivered emails. Use tools that capture the full message as it's sent, including server-side additions. The goal is to match h= to headers that are static and predictable. Remove any that are added dynamically or inconsistently.

For example, the Received header is added multiple times during email transit, making it unreliable to include. Similarly, Message-ID may change during retry mechanisms. Omitting these from h= prevents unnecessary failures. The DKIM RFC recommends selecting only headers that remain unchanged throughout delivery, a principle that holds even in complex environments.

Once you’ve adjusted your h= list, test the results with a real-world inbox placement tool. Use MailTester’s inbox placement tester to verify whether your emails now reach inboxes consistently. This step validates both DKIM integrity and broader deliverability health — the real goal behind signing.

Which header fields are commonly incompatible with DKIM signing?

You should avoid signing fields like Received, X-headers, MIME-Version, and Content-Transfer-Encoding in DKIM because they’re added or altered by intermediate mail servers, not preserved consistently across the delivery path. Signing them leads to verification failures. Let’s break down why each causes issues and how to fix it.

Fields that change during transit

• Received: Added by every MTA that handles the message. These headers change with each hop and differ between servers. Signing them breaks verification when the message is relayed.
• X-headers (e.g. X-Envelope-ID, X-Message-Id): Often internal to the sending server or email platform. They’re not standardized and are frequently modified or stripped by middleboxes or filtering systems. Including them in DKIM signatures creates mismatches.
• MIME-Version: Rarely signed and often stripped or rewritten during transit. The standard doesn’t require it to be preserved, so signing it risks validation failures.

Fields with variable or redundant content

• Content-Transfer-Encoding: Changes based on message content (e.g., base64, quoted-printable). Since this field varies between delivery paths, signing it doesn’t add consistency and can cause alignment errors.
• Message-ID: While sometimes included in DKIM, it’s often regenerated by gateways or spam filters. If your signature includes it and the ID changes later, DKIM fails. Best left out unless you control the entire delivery chain.

DKIM’s effectiveness depends on consistency. If the headers signed don’t match exactly at verification time, the signature is invalid. The DKIM specification outlines which headers should be signed, but not all implementations follow it strictly. Use tools like MailTester to validate your DKIM setup in real-world conditions.

Fixing the h= tag in your DKIM signature to exclude non-persistent fields isn’t just optional — it’s a key part of keeping your sender reputation intact. You can test your DKIM alignment with a real email before sending using our inbox placement tester or check whether individual addresses are deliverable with our email checker.

What happens when unsupported headers are included in h=?

If your DKIM signature includes a header in the h= tag that the receiving server doesn’t recognize or support—like a rarely used or custom header—many modern email providers (Google, Microsoft, Yahoo) will reject the DKIM check entirely. Even if SPF and DMARC pass, this single mismatch can cause your email to fail authentication, land in spam, or be blocked outright. This isn’t a minor technicality—it’s a top reason for sudden deliverability drops with no change in content or sender reputation.

Why unsupported headers in h= break deliverability

DKIM relies on strict header alignment. The receiving server verifies that every header listed in the h= tag was signed and unchanged. If your mail server signs a header the receiver doesn’t support—say, X-Company-Signature or a custom tracking field—the validation fails.

Google and Microsoft’s filtering systems are particularly strict. They don’t just ignore unsupported fields—they treat them as signs of misconfiguration or potential manipulation. A failed DKIM check means your email is treated like an unknown or suspicious source, reducing chances of landing in the primary inbox.

How this impacts your sending program

Even one misconfigured header in h= can cause a full DKIM failure, regardless of how clean your content or sender reputation looks. This often leads to sudden spikes in bounce rates and higher spam complaints, which can degrade sender reputation over time.

These issues are especially common after migration or integration changes—like switching ESPs, adding tracking headers, or using automation tools that add custom fields without proper DKIM configuration. You might see emails stop reaching inboxes overnight, with no change to content, timing, or list quality. That’s usually a red flag for incorrect DKIM header alignment.

Let’s be clear: you don’t need to sign every header in your message. Only the ones that matter to the receiver’s filtering logic. Stick to standard email headers like From, To, Subject, Date, and Message-ID. If a custom field isn’t essential to authentication, omit it from h=.

For a real-world check, you can test your DKIM signature’s alignment using tools that verify the full header set. MailTester’s inbox placement tool checks how your emails land across major providers—including DKIM alignment—so you can catch issues before sending to your entire list.

Correcting the DKIM h= tag: A step-by-step process

You fix DKIM deliverability issues by identifying non-standard or non-deterministic headers—like Received: or X- fields—in your DKIM signature and excluding them from the h= tag. Only include consistent, standardized headers such as From, To, Subject, Date, Message-ID, and Content-Type. This ensures the signature remains valid across mail servers. Use tools like MailTester’s inbox placement tester to validate changes and monitor delivery results directly.

Inspect and diagnose the current DKIM setup

1. Retrieve the raw email header from a delivered message using your email client or a mail server log.
2. Locate the DKIM-Signature header and examine the h= tag—it lists which headers are included in the signature.
3. Check if any fields in the h= tag are non-standard (e.g., X-MyCustomField, X-Forwarded-For) or non-deterministic (like Received: or X-MS-Exchange-Organization-Original-AuthAs).
4. These fields change unpredictably during transit, causing DKIM validation to fail even when the email is legitimate.

Update the DKIM signing configuration

5. Review your email system’s DKIM signing configuration—common in platforms like SendGrid, Amazon SES, or enterprise mail gateways.
6. Remove any non-standard or non-deterministic header names from the h= tag.
7. Keep only standardized, consistently present headers: From, To, Subject, Date, Message-ID, and Content-Type. These are defined in RFC 5322 and RFC 6376.
8. Save the updated configuration. Changes may take effect within 1–24 hours depending on your provider.
9. Verify the new signature using a real-time verification tool like MailTester’s inbox placement tester or API to simulate delivery and confirm DKIM passes.
10. Test with multiple recipients across major providers (Gmail, Outlook, Yahoo) to check consistency.
11. Monitor post-change metrics: reduced bounce rates, improved inbox placement, fewer DKIM failures in reports.
12. Repeat testing after 24–72 hours to ensure the fix is stable and widespread.

Even small misconfigurations in DKIM can block delivery. Aligning your h= tag with industry-standard practices reduces false negatives.

For context, RFC 6376 (the DKIM specification) clearly states that only headers with guaranteed consistency should be signed. Mail servers expect this behavior. Deviations—even minor ones—lead to rejection.

Use tools that check both syntax and real-world delivery. MailTester’s bulk verification and API allow you to validate sender reputation at scale. This includes checking whether your DKIM configuration, along with other sender signals, supports consistent inbox delivery.

Always test changes in staging before going live. A single malformed h= tag can trigger sender reputation penalties.

How to verify that your DKIM h= tag is correctly configured

You can verify your DKIM h= tag by testing email delivery using tools that simulate real-world conditions with your actual DNS records and signing setup. Use MailTester’s inbox-placement testing or real-time verification API to send test messages and check whether DKIM passes without warnings about unsupported header fields. Pay attention to delivery logs and sender reputation dashboards across different domains and client inboxes—Gmail, Outlook, Apple Mail—to catch inconsistencies early.

Step-by-step verification process

• Send a test email using your current DKIM signature and DNS configuration.
• Use MailTester’s inbox-placement testing to simulate delivery to major inboxes and check DKIM validation status in real time.
• Confirm that the DKIM signature passes without errors related to unsupported headers in the h= tag.
• Review the full message header output—especially in Gmail’s “Show original” or Outlook’s “View message source”—to verify that only supported header fields are listed in h=.
• Check for discrepancies in delivery logs: a mismatch between your expected h= fields and what’s actually signed may trigger rejection or filtering.
• Test across multiple domains (e.g., @gmail.com, @outlook.com, @icloud.com) because each client handles malformed DKIM records differently.
• Monitor sender reputation dashboards (e.g., Google Postmaster Tools, Microsoft SNDS) for any drop in alignment or increased failure rates tied to DKIM.
• If warnings appear, audit your signing process to ensure only standard, supported headers like From, To, Subject, Date, and Body are included in the h= tag—never custom or proprietary fields.

Why the h= tag matters for deliverability

DKIM’s h= tag defines which headers are signed. Including unsupported or non-standard fields breaks signing alignment. Even if the signature technically passes, some ISPs treat this as a red flag—especially Gmail and Microsoft, which enforce stricter validation. According to RFC 6376, the h= tag must only contain standard, registered header names. Including field types like X- or custom vendor-specific headers can cause silent fails or degraded trust metrics over time.

Let’s say you include h=From:To:Subject:X-Campaign-ID:—the inclusion of X-Campaign-ID is not standard. While some servers may still accept it, others will reject the signature or downgrade the message’s trust score. This can result in higher bounce rates or inbox placement delays, especially under load.

Best practices for maintaining a clean DKIM h= tag

Keep your DKIM h= tag focused on stable, standard headers—From, To, Subject, Date, Message-ID, and Content-Type—to avoid signature failures caused by dynamic or inconsistent fields. Limit the list to 4–7 core headers, test changes in staging, and document the approved set in your team’s senders’ guide to prevent drift. This reduces the risk of rejection by strict receivers and improves inbox placement over time.

What to include in your h= list

• Stick only to the internet-standard headers that remain unchanged across delivery paths: From, To, Subject, Date, Message-ID, and Content-Type.
• Avoid signing dynamic or route-dependent fields like Received, Return-Path, or DKIM-Signature—they vary per hop and break signature validation.
• Do not include headers that are frequently modified in transit, such as Received-SPF, Authentication-Results, or DKIM-Filter—these are neither reliable nor meant to be signed.
• Use only four to seven consistent fields. The fewer fields you sign, the less likely your signature will be invalidated by intermediate processing.

How to implement safely and sustainably

• Test any h= tag changes in staging first. Use the inbox placement tester to validate deliverability before rolling out to live traffic.
• Document your approved header set in your internal sender’s guide. This prevents accidental reintroduction of non-standard or volatile headers.
• Monitor bounce logs and feedback loops. If you see spikes in authentication failures or soft bounces, check whether header changes in the h= list might be the cause.
• Align your DKIM setup with RFC 6376, which defines DKIM’s structure and best practices for key and header signing.
• Use the email verification API to pre-check sender lists and detect malformed or unresolvable addresses that could interfere with signature workflows.

When your DKIM signing remains consistent and minimal, mail servers across the internet treat your messages with greater confidence. This isn’t about perfect scores—it’s about reducing the noise where a single inconsistent header can tip the balance toward spam.

How MailTester helps detect and fix DKIM h= issues

You can catch and fix incorrect DKIM h= tags—especially those including unsupported header fields—before they hurt deliverability. MailTester’s inbox-placement tests and real-time API scan message headers for malformed DKIM signatures, flagging when h= includes fields not allowed by the DKIM specification. This helps prevent bounces and inbox filtering caused by signature validation failures.

Full header analysis catches h= signature flaws

When you run an inbox-placement test, MailTester parses the full email header, including the DKIM signature. It checks whether the h= tag lists only fields that are part of the standard DKIM signing process. For example, fields like Delivered-To or Received are often included incorrectly and can break the signature if not excluded. The system flags this as a failure and provides a detailed breakdown so you know exactly which field caused the issue.

API and AI assist in diagnosing and remediating errors

With MailTester’s real-time verification API, you get granular diagnostics on each email, including whether the DKIM signature validates and exactly which fields are included in the h= tag. You can test individual addresses or process large lists to validate changes before deploying to production. The in-app AI assistant analyzes common patterns of DKIM misconfiguration and can proactively suggest corrections when it detects risky or malformed header field lists.

For example, if h=From:To:Subject:Date:Message-ID includes a nonstandard field like X-MyCustomHeader, the system highlights it as invalid. This stops you from sending messages that fail authentication even if other parts of your email appear normal. This level of visibility is critical—improper h= tags are a common cause of DMARC failures and reduced inbox placement, especially with providers like Gmail and Outlook.

By integrating MailTester with your email workflow—through our integrations with SendGrid, HubSpot, and others—you can catch these flaws early and fix them before sending to real users. You can test a single email using our email checker or verify entire lists with our bulk verification tool. This ensures your DKIM setup is consistently correct, improving sender reputation and reducing rejection odds.

For the technical details, the DKIM specification defines what header fields are valid for inclusion in the h= parameter. Sticking to those fields—like From:To:Subject:Date:Message-ID—is critical for signature success. MailTester helps you enforce that rule consistently.

What role does senders' reputation play when DKIM is misaligned?

Even a single DKIM failure due to an incorrectly configured h= tag can be flagged by receivers as a sign of poor sender hygiene, especially if that failure persists across multiple messages. If the same header is repeatedly included in the DKIM signature but not supported by the receiving server, it contributes to a pattern of technical misalignment that reputation systems like Microsoft SNDS or Google Postmaster Tools monitor closely. Over time, repeated failures—regardless of whether they’re due to a single flawed header—can trigger rate limiting, temporary blocking, or degradation in inbox placement.

How DKIM misalignment impacts sender reputation

Reputation systems don’t just track spam complaints or bounces—they track technical consistency, too. When a header listed in the h= tag isn’t signed or isn’t supported by the receiver, the signature fails validation, even if the message content is clean. This looks like a misconfigured sender, which can reduce trust scores. Even if the issue is technical (like using Received-SPF in h= when receivers don’t expect it), it still signals a lack of diligence. The longer this persists, the more likely it is to be interpreted as a sign of poor operational hygiene.

Let’s be clear: DKIM isn’t just about authentication—it’s about signal trust. Receiving servers assume that if you’re signing headers, you’re doing it correctly. Including unsupported or unnecessary fields violates that assumption. For example, the DKIM RFC states that only headers explicitly named in h= should be included in the signature. If you include a header that doesn’t exist or isn’t valid in the domain’s policy, it breaks alignment.

Fixing DKIM alignment improves long-term deliverability

Correcting a flawed h= tag—by removing unsupported or invalid headers—is a direct way to reduce failure rates and stabilize your sender reputation. Even if the rest of your setup is solid, one misaligned signature can cause cascading issues. Once fixed, you’ll see fewer failures in logs, less fluctuation in SNDS or Postmaster Tool reports, and improved long-term inbox placement. This isn’t a one-time fix—it’s part of ongoing sender hygiene that prevents reputation damage before it starts.

If you're unsure whether your DKIM setup is misaligned, run a real-time validation on specific headers using our email verification API, which can test technical alignment during delivery simulation. It helps catch issues like unsupported h= values before they hurt your reputation.

Final takeaway: Don’t overlook the DKIM h= tag in your deliverability strategy

DKIM is only effective when correctly implemented. The h= tag controls which headers are signed, and misconfiguring it—especially by including dynamic or unsupported fields—can cause signature failures and reduce deliverability.

Excluding headers like Date, User-Agent, or Message-ID, which change per message, ensures your signature remains stable across sends. This simplicity improves verification rates and strengthens trust with receiving servers.

Use MailTester to audit your DKIM setup at scale. Real-time verification and inbox-placement testing expose misconfigurations before they impact your sender reputation.

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

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• DKIM q= Tag Value Mismatch Error & Email Deliverability Issues
• DMARC Record Validation Error: p=quarantine Not Recognized
• How to Convert IP4 Subnet 255.255.255.0 to CIDR Format for SPF
• How to Fix SPF Include Chain Loop with Self-Referencing Domain

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

Frequently asked questions

What does the DKIM h= tag do?

The h= tag specifies which email headers are included in the DKIM signature. Only those headers are verified during authentication.

Can the DKIM h= tag include any header?

No — only headers that are standardized and consistently present across all delivery paths should be included. Dynamic or non-standard headers often cause failure.

How do I find the current h= values in my DKIM signature?

Inspect the raw email header. Look for the dkim-signature field and examine the h= tag, which lists all signed headers.

Is it safe to remove Received: from the DKIM h= tag?

Yes — Received: headers are added by intermediate servers and are not consistent. Excluding them improves signature reliability.

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

Stick to standard, invariant headers: From, To, Subject, Date, Message-ID, and Content-Type.

How often should I audit my DKIM h= configuration?

At least every time you update your email infrastructure, or if you notice a drop in inbox delivery.

Can DKIM fail even if SPF and DMARC pass?

Yes — DKIM is independent. A misconfigured h= tag can cause DKIM failure even when other authentication methods validate.

Does MailTester test DKIM signatures?

Yes — MailTester’s real-time API and inbox-placement tests validate DKIM signatures, including h= field accuracy.

What happens if I include a non-standard header in h=?

The receiving server may reject the signature if it doesn't recognize or expect that header, causing delivery failure.

Can a typo in the h= tag break DKIM?

Yes — a typo in a header name listed in h= will cause the verification process to fail if that header is missing or differs in format.

Do I need to sign every header in the email?

No — only headers that are standardized and consistently present should be signed. Over-signing increases failure risk.

How do I fix a DKIM h= error in SendGrid?

Review your email template and outbound sending configuration. Exclude non-standard or dynamic headers from the DKIM signing list in SendGrid’s settings.