Why Does an Email Verification Tool Report h= Tag Failures?

You just verified a list of emails, and one valid address failed — not because it’s fake, but because of a h= tag in the domain’s DKIM signature. The tool flagged it as invalid, but your inbox still received the message. Why?

The issue isn’t the email address. It’s the way the sending domain signs its mail. DKIM uses h= tags to specify which headers are included in the digital signature. If a tool doesn’t recognize a header field used in that list — like list-unsubscribe or Precedence — it fails the verification, even if the email is perfectly valid and delivered.

This failure is a common reason why some valid addresses are rejected during bulk verification — especially in transactional or high-volume newsletters where non-standard headers are common. Understanding this helps you distinguish between real invalid addresses and false positives caused by technical misalignment.

Key takeaways

  • Email verification tools may reject valid addresses due to non-standard or unsupported header fields in DKIM h= tags, not because the email is invalid.
  • Failures linked to h= tags are caused by domain-level DKIM configuration, not the recipient address itself.
  • Verification tools that check DKIM syntax but lack up-to-date header field support may generate false negatives, especially with headers used in marketing or automated email flows.

What Is the h= Tag in DKIM, and Why Does It Matter?

The h= tag in DKIM specifies which email headers are included in the digital signature. If any of those headers are modified in transit—by a relay, filter, or gateway—the signature fails, signaling tampering or misconfiguration. Most verification systems, including MailTester, only validate h= lists that use standard, widely supported header names. Using unsupported or custom fields causes a verification fail, even if the signature is mathematically correct.

How h= Affects Verified Deliverability

DKIM’s h= tag isn’t just about technical correctness—it’s about reliability. When the header list is non-standard, it breaks compatibility with email validators, mail servers, and spam filters. This can lead to a failed verification, even if the email address itself is valid. You might have a perfectly signed message, but the wrong fields in h= trigger rejection during checks.

For instance, only a small set of header names—like From, To, Subject, Date, and Message-ID—are considered standard across systems. If h= references a non-standard header like X-My-Custom-Field, most verification tools will reject the signature immediately. This is not a flaw in your email system; it’s a misalignment with industry-wide expectations.

MailTester detects these issues automatically during email verification. If your DKIM signature includes an unsupported header field in the h= tag, the tool flags it as a failure, so you can fix it before sending. This prevents send failures, improves sender reputation, and reduces the risk of being routed to junk folders.

It’s important to remember that DKIM is not foolproof. Even with a valid signature, mismatched or invalid h= values can cause deliverability problems. You should always validate both the signature and the header list in your DKIM configuration. Tools like MailTester’s bulk verification test for this in real-world conditions, simulating how major providers like Gmail and Outlook actually process messages.

For deeper insight, refer to RFC 6376, which defines the technical specifications of DKIM, including header handling. The standard emphasizes consistency and interoperability—core principles that verification systems enforce to protect users.

Let’s be clear: a technically correct DKIM signature is not enough. The h= tag must follow widely accepted standards. Use only standard header names. Avoid custom or poorly documented header fields. You can test this in a real deliverability environment with MailTester’s inbox placement tool, which checks how your message lands across major email providers.

How Does an Unsupported h= Field List Cause Verification to Fail?

When a domain signs a header like List-ID or X-Feedback-ID using DKIM with an h= tag that includes fields not on the accepted list, the verification engine treats this as a failure—even if the email address itself is valid. This is a strict parsing rule in DKIM validation: only headers explicitly allowed in the h= parameter pass. If the domain’s signing policy includes unsupported fields, verification fails regardless of the message’s content or delivery path.

DKIM’s Strict Field List Enforcement

DKIM relies on a precise list of allowed header fields in the h= tag. The specification, defined in RFC 6376, states that only specific headers—like From, To, Date, and Subject—can be signed unless explicitly defined in the signature. Including a custom or non-standard header such as List-ID or X-Feedback-ID without it being part of the allowed list breaks the signature validation.

Let’s say a domain signs a message with h=From:To:Subject:List-ID. If the receiving validator—like MailTester’s engine—doesn’t recognize List-ID as permitted, the signature fails. This isn’t about the email address being fake or malformed. It’s about misconfiguration in the signing policy.

Why This Is Not a Flaw in the Email Address

MailTester detects this mismatch during validation not because the recipient’s email is invalid, but because the domain’s DKIM policy is incomplete or non-compliant with industry standards. You’re seeing a failure in authentication, not delivery. A valid address can still fail verification due to this technical misalignment—especially if the domain signed a custom header with an unsupported field.

Importantly, this is not a rare edge case. It’s commonly seen in newsletters or automated systems that add custom headers to track campaigns or manage mailing lists. Even if those headers serve a purpose, they must not be included in the DKIM h= tag unless they’re part of the permitted set. The result? A DKIM failure, high bounce rates, and poor inbox delivery—even if the email is real.

MailTester identifies these failures during bulk verification and delivers a clear DKIM validation fail alert with the reason: “Unsupported h= field list.” You can then audit your sending setup, adjust your DKIM configuration, and verify that only approved headers appear in the signature list. If you're preparing a campaign or managing a high-volume list, verify your entire list upfront to catch these issues before deployment.

What Happens When h= Tag Uses Non-Standard Fields?

Using non-standard fields in the h= tag of a DMARC record can cause authentication failures, leading to email rejection by receiving servers—even if the address format is valid. The h= tag specifies which header fields are signed; using unsupported or unrecognized fields breaks DMARC validation, resulting in a policy failure. This is independent of the address itself, bounce rate, or whether it's a role account.

Why Non-Standard h= Fields Break DMARC

DMARC relies on strict alignment between the signed headers and the ones listed in the h= tag. If the tag includes fields not defined in the DMARC specification—like custom headers or misclassified standard ones—the receiving server rejects the authentication check. This isn’t about the email address being invalid; it’s about the SPF/DKIM alignment failing due to poor header signing configuration.

For example, if a domain uses h=From:Subject:Custom-Header without a standard definition, receiving mail servers may interpret this as a violation. The DMARC specification lists only a subset of header fields as acceptable in h=, and deviating from those can trigger rejection.

How MailTester Helps Identify the Risk

MailTester doesn’t validate the address alone—it evaluates the domain’s overall authentication health. When it detects an h= tag with non-standard fields, it flags the domain, not the individual email. This helps you catch issues that could cause mass delivery failures even with a clean list.

You won’t see this in traditional email validation tools that only check syntax or deliverability. But MailTester’s deep domain inspection catches these DMARC-level errors before they impact delivery. It’s not about one address—it’s about configuration risk across your sender infrastructure.

Let’s say your mailing list passes format checks and shows no bounces. But emails still don’t land in inboxes. The root cause might be here: an improperly configured h= tag. With bulk verification or our inbox placement test, you can uncover these hidden problems before they cost you reputation.

Check Your DKIM Record’s h= Field: Here’s How

If your email verification tool flags a DKIM h= tag with an unsupported field list, it’s likely signing non-standard headers. This can trigger delivery issues. You can fix it by checking your DKIM DNS record, reviewing each header in the h= list, and ensuring only standard fields like From, To, Subject, and Date are included. Many verification tools reject emails with custom headers to prevent spoofing.

Step-by-step: How to verify your DKIM h= field

  1. Retrieve your DKIM TXT record using a DNS lookup tool like MxToolbox or the dig command. Enter your domain and the selector (e.g. mail._domainkey.example.com), then examine the TXT value. This is where your DKIM configuration lives.
  2. Find the h= tag within the TXT record. It will look like h=From:To:Subject:Date:Message-ID;. This defines which email headers are signed during DKIM validation.
  3. Check each field listed in h= against the standard header set defined in RFC 6376. Common valid headers include From, To, Subject, Date, and Message-ID. These are the only ones widely accepted by email providers and verification engines.
  4. Remove or fix invalid fields. If you see non-standard fields like X-Campaign-Id, Priority, or Return-Path listed, remove them. The presence of such fields can cause verifiers to reject the signature, even if the technical signature is valid.
  5. Update your DNS record after removing unsupported fields. Wait for propagation (usually 0–30 minutes), then rerun the verification test. This ensures your domain no longer triggers red flags during checks.

Why unsupported h= fields break deliverability

Verification tools like MailTester detect non-standard header fields because they’re often used in spam or poorly configured campaigns. While RFC 6376 does not forbid custom headers, including them in the h= list increases the chance of failing authentication checks. This is especially true with bulk email systems where senders use custom metadata to track campaigns.

Using a real-time verification API lets you catch these issues early. Instead of guessing, you can test an individual address with MailTester’s API and see exactly why a signature failed. You’ll get clear feedback on rejected headers and can adjust your DKIM record before sending to large lists.

Always verify your DKIM configuration before sending critical messages. A single unsupported header in h= can result in your message being silently quarantined by receivers that enforce strict validation.

How MailTester Handles h= Tag Detection and Failures

MailTester detects unsupported or non-standard fields in the DKIM h= tag during real-time and bulk email verification. It flags domains with non-compliant signing policies as risky—never marks individual addresses as invalid—so valid recipients aren’t falsely rejected due to poor email signing practices. This maintains list accuracy while preserving deliverability.

Drafting a Realistic Signing Policy Check

DKIM signatures use the h= tag to define which header fields are included in the signature. While the standard allows specific, known fields, some senders add custom or non-standard fields. MailTester checks each h= list against a maintained set of known, accepted fields—based on RFC 6376 and industry practices—not an exhaustive list, since new fields emerge.

If an unsupported field appears, MailTester treats it as a policy-level issue. The domain is flagged as risky, not the specific email address. This means a single malformed header won’t cause a valid user to be rejected. It's a safeguard against false positives in large-scale verification.

Why It Matters for Deliverability

Domain-side DKIM misconfigurations can trigger mail server suspicion—especially if the signature covers non-standard fields. While the receiving server may still accept the message, it’s more likely to rate-limit or delay delivery. By identifying these signing quirks early, MailTester helps teams prioritize fixes.

For example, a domain signing with h=from:to:subject:custom-field when custom-field is not part of the standard set violates best practices. MailTester detects this and marks the domain as risky, giving you an actionable signal to assess your sending setup. This insight is critical for maintaining strong sender reputation and inbox placement.

The verification process runs automatically in bulk or in real time via our email verification API, so you don’t need to manually audit every signature. The full verification results—including risk verdicts and DKIM metadata—are available in the bulk email verification interface.

For more on email signing standards, see the DKIM specification and best practice guides from email security providers. These sources confirm that strict adherence to known header lists reduces delivery anomalies.

What Should You Do When an Email Verification Tool Reports h= Fail?

If your email verification tool flags an h= tag with an unsupported field list, don’t mark the email as invalid. The issue is almost certainly with the domain’s DKIM configuration — specifically, the h= list includes non-standard or unsupported headers. Fixing the DKIM record reduces false negatives and improves sender reputation. Let's go through the steps.

Check the DKIM Record for the h= List

  • Use a tool like MXToolbox or RFC 6376 to inspect the DKIM DNS record for the domain in question.
  • Look for the h= tag and verify which headers are listed. Common supported headers are from, to, subject, date, message-id, and mime-version.
  • If the list contains non-standard or custom header names like X-My-Custom-Header, these are not supported and will cause DKIM validation to fail.

Fix and Re-Test the Configuration

  • Update the DKIM record to include only standard, RFC-compliant header names in the h= list.
  • Remove any custom or non-standard headers unless absolutely required for your use case — and only if you’re certain the receiving mail server supports them.
  • After updating, wait for DNS propagation (typically 5–15 minutes), then re-test using a real-time validator like the MailTester API or bulk verification tool.
  • Verify the domain using MailTester’s email checker for a single address or bulk verification for larger lists.

DKIM failures due to invalid h= lists are not indicators of poor email quality — they’re technical misconfigurations. Correcting them ensures authentication succeeds, lowers bounce rates, and improves inbox placement. This is especially critical when using services like SendGrid, Mailchimp, or Klaviyo, where DKIM is enforced. Never assume an email is invalid just because an h= check fails. Focus on the domain’s DKIM setup first. The fix is simple — but it’s easy to overlook.

Why Some Tools Miss h= Tag Issues — and Why MailTester Doesn’t

Many email verification tools only check if an address is syntactically valid and can receive mail. They don’t examine DKIM headers, so they miss issues like h= tags with unsupported field lists that break authentication. MailTester goes deeper: it validates DKIM policy compliance at the header level, catching problems that can harm sender reputation over time.

Not All Tools Check DKIM Headers

Most email verification tools stop at format, MX lookup, or SMTP delivery tests. They’ll tell you if an address exists, but not if the domain’s DKIM policy is violated. For example, a h= tag listing fields not allowed in the signature—like h=from:to:subject when only from:subject is permitted—will still pass on basic tools.

This doesn’t cause immediate delivery failures. But it can lead to inconsistent authentication results, making your domain look unreliable to receivers. ISPs like Gmail and Microsoft use DKIM validation to assess trustworthiness over time. A signature with non-standard field lists risks being treated as unverified or even suspicious.

MailTester Checks What Others Ignore

MailTester’s 98.9% accuracy comes from validating actual email header policies, including DKIM. It checks not just if a domain signs mail, but whether the h= list is valid per RFC 6376—the standard governing DKIM. This includes verifying that only allowed headers are listed, and that the list matches the signed headers.

For example, if a domain includes h=x-mailer:content-type in its DKIM signature without those fields being in the allowed list, MailTester flags it as a failure. These issues can cause inconsistent authentication results across providers, which harms long-term deliverability.

Let’s say you’re sending to a list with 100,000 contacts. Most tools will say 95% are valid. But if 3% have invalid DKIM field lists—hidden in headers—those emails might get deprioritized or rejected later. MailTester catches those early.

You can test your list with our bulk verification tool or validate individual addresses before sending using our email checker. These services include header-level validation, not just basic format or SMTP checks.

Is This a Problem Only for Large Senders?

No — this issue isn't limited to enterprise senders. Even small businesses, freelancers, or individuals using custom email services can trigger h= tag failures if their DKIM signing process includes non-standard or unsupported header fields. The problem arises from improper header canonicalization during DKIM signing, not volume or infrastructure complexity.

Why Smaller Senders Are Just as Likely to Hit This

When you set up a domain-based email system—say, using a self-hosted mail server, a custom-built CRM, or a template in a newsletter platform—the DKIM signature generation can get misconfigured. If the signing tool includes header fields not listed in the h= tag, or adds unsupported ones (like custom X-headers), the receiving mail server may reject the signature outright.

Many automated systems, such as email workflows in HubSpot, Mailchimp, or Klaviyo, use templates that sometimes embed non-standard headers. If those templates are used without validation, even a single misconfigured header can break DKIM. This isn’t about scale—it’s about configuration.

How This Shows Up in Practice

Let’s say you’re sending transactional emails via a custom Node.js script or a Zapier automation. If the script signs the DKIM header with h=from:to:subject:date:custom-header, but the server only permits h=from:to:subject:date, the signature will fail. The receiving mail server will see the mismatch and reject the message—often silently.

According to RFC 6376 (the DKIM standard), only explicitly listed headers in the h= tag should be included in the signature. Any field not included in that list, even if present in the email, can invalidate the signature if the signing process includes it.

Using an email verification tool like MailTester’s email checker can surface these issues early. It reviews the technical structure of the email, including header signing, and flags unsupported field lists in the h= tag before you send to real recipients.

How to Prevent h= Tag Failures After Fixing the Record

After fixing a DKIM record with an unsupported h= field list, prevent reoccurrence by signing only standard headers—From, To, Subject, Date, Message-ID—and validating every new policy with an independent tool before going live. This avoids mismatches that trigger rejection.

Stick to Standard Headers in DKIM Signatures

  • Use only From, To, Subject, Date, and Message-ID in your DKIM h= tag. These are the only headers universally recognized and verified by email receivers.
  • Any other header—like X-Original-To, List-ID, or custom tracking fields—can cause the h= tag to fail if the receiving server doesn’t expect it.
  • Follow RFC 6376, the standard for DKIM, which explicitly lists these five headers as the minimal expected set for validation. IETF RFC 6376 defines the scope of what receivers should expect.

Validate Before Deployment

  • Never deploy a new DKIM policy without testing it using an independent DKIM validator. Tools like MXToolbox's DKIM Validator or DMARC Analyzer's DKIM checker simulate real-world validation.
  • If your email platform or ESP allows, test signatures on a small, real list of recipients before full rollout. Monitor bounces and feedback loops to catch failures early.
  • Use MailTester’s inbox placement tester to verify that email delivery succeeds post-signature change—this catches issues that plain DKIM validators miss.
  • When adding new headers, consult the RFCs and check if the header is listed in the accepted headers list for your receiver's mail filter. If in doubt, exclude it from the signature.

Summary: h= Tag Failures Are About Policy, Not Addresses

An email verification tool detecting h= tag issues with unsupported fields isn’t rejecting a bad email address. It’s identifying a misconfiguration in the domain’s DMARC policy that can prevent legitimate messages from being trusted.

These failures stem from overly restrictive or malformed alignment rules in the DKIM signature. When the h= tag includes fields not supported by the domain’s policy, it triggers a DMARC failure — even if the email itself is valid. This affects inbox placement and sender reputation over time.

MailTester flags these issues not to block valid senders, but to help you identify and fix domain-level signing problems that undermine deliverability. Proactive detection prevents hard bounces and increases inbox placement for real messages.

Sources

Keep reading

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

Frequently asked questions

Does an h= tag failure mean the email address is invalid?

No. The issue is in the domain’s DKIM signature policy, not the email address. Valid addresses can fail if the signing header list contains unsupported fields.

Which headers are considered standard in DKIM h= tags?

Standard headers include From, To, Subject, Date, Message-ID, and Reply-To. Non-standard or custom headers like List-ID or X-Campaign-Id are not universally supported.

Can I use custom headers in DKIM h= tags?

Yes, but only if the receiving server explicitly allows them. Most email providers reject DKIM with non-standard fields unless they're widely accepted.

How does MailTester detect h= tag problems?

It parses the domain’s DKIM DNS record and checks the h= field list against known standards. Unsupported fields trigger a warning, not a full address rejection.

Do all email verification tools check for h= tag issues?

No — many only validate address syntax and basic deliverability. Only tools with full DKIM and DMARC inspection, like MailTester, detect these policy-level flaws.

What happens if I ignore h= tag warnings?

Mail delivery may fail on servers that enforce strict DKIM validation, especially for high-volume senders. It can also hurt sender reputation over time.

Can I fix this without changing DNS?

No — the h= tag is part of the DNS-based DKIM record. You must update the record to remove unsupported fields and re-sign messages.

Is there a tool to verify DKIM h= fields before sending?

Yes — MailTester’s real-time API and inbox-placement testing include DKIM header checks. You can validate domain policy before sending campaigns.

How often should I check my DKIM h= tag?

Check after any major change to email infrastructure—new sender, template, or automation platform. Do it quarterly as part of list hygiene.

Does MailTester flag other DKIM misconfigurations?

Yes — beyond h= fields, it checks signature length, key presence, selector validity, and alignment with DMARC policies.

Can disposable or role accounts cause h= tag issues?

No — h= tag issues are independent of the recipient. They relate only to the sender’s DKIM signing policy.

How accurate is MailTester’s DKIM validation?

Its verification engine achieves 98.9% accuracy by combining real-time checks, DNS inspection, and header-level analysis across all verified addresses.