Why Does MailTester Show DKIM=fail for Valid Emails?

You send a clean email, it shows as deliverable in MailTester, and yet the DKIM=fail result makes you pause. Why? A valid address, properly signed, still fails verification—not because it's fake, but because of how headers are hashed in the DKIM signature.

DKIM=fail often points not to the recipient, but to a flaw in the signature’s header list. The h= tag in the DKIM signature includes which headers are part of the cryptographic hash. If the same header appears more than once, or if an unintended header is included, the hash no longer matches. Even a single repetition can break verification—even if the email is correctly signed and deliverable.

MailTester catches this mismatch accurately. It doesn’t flag the email as invalid—it highlights a technical flaw in how the signature was constructed. Fixing the h= tag ensures the DKIM check passes, even for valid, legitimate email addresses.

Key takeaways

  • DKIM=fail in MailTester does not mean the email is invalid—or undeliverable.
  • Incorrect or repeated headers in the h= tag are the most common cause of false DKIM failures.
  • Fixing the header list in the DKIM signature ensures correct verification, even for properly signed emails.

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

The h= tag in a DKIM signature specifies exactly which email headers are included in the hash calculation. If the receiving server re-hashes the listed headers and the result doesn’t match the signed hash, DKIM=fail. This happens when the list is incomplete, incorrect, or includes repeated headers—common issues that silently break email authentication.

How the h= Tag Works in Practice

Let’s say a DKIM signature uses h=From:To:Subject:Date:. The receiving mail server will recompute the hash using only those exact header names, in order. If even one header is missing, or if a header appears twice (like From: [email protected] and From: [email protected]), the hash will differ—even if the actual content is identical. That mismatch causes DKIM=fail, regardless of whether the message itself is legitimate.

This is why the h= tag is a cornerstone of DKIM validation. It’s not just about which headers are signed—it’s about exactly which ones, in exactly which order. A single misplaced or redundant header in the h= list breaks the chain.

Common Real-World Causes of h= Failures

Most h= tag issues stem from how mail systems process headers. For instance, some systems auto-add or normalize headers like Message-ID or Received, which aren't usually included in h=. But if your signing setup accidentally includes them—or duplicates any header—the hash will fail. Email tools with poor header handling may also rewrite or re-order headers before signing, causing mismatched h= values.

Another frequent problem is the use of non-standard or malformed headers. If your system includes a custom header (e.g., X-Campaign-ID) in h= but the receiving server doesn’t know about it, it won’t hash that field at all—rendering the signature invalid. The DKIM spec (RFC 6376) outlines this behavior clearly: only headers explicitly listed in h= are considered part of the signature.

You can test DKIM validity in real time using tools like MailTester’s inbox placement tester—it checks full authentication (SPF, DKIM, DMARC), header alignment, and delivery path in real mail servers like Gmail and Outlook. That’s a practical way to catch h= issues before sending to a live list.

Always verify your DKIM header selection against the actual message sent. A mismatched or duplicated header in the h= list is a silent kill switch for deliverability. It’s not a rare edge case—it’s one of the top reasons DKIM fails in production mail flows.

How Repeated Headers Break DKIM and Trigger MailTester DKIM=fail

You’re seeing DKIM=fail in MailTester not because the email is forged, but because one or more headers—like From:, Received:, or Message-ID—appear more than once in the h= tag of the DKIM-Signature header. DKIM requires each header name listed in h= to appear exactly once in the message. If a header is duplicated, the hash calculation fails, and the signature is deemed invalid, even if the email content and encryption are otherwise correct.

The Problem: Duplicate Headers in h=

Let’s say your email includes two Received: lines due to relay chains or mail server routing. If both are included in the h= tag—like h=from:received:subject:message-id—DKIM’s signing algorithm sees this as a conflict. The canonical header list must be unique. Even a single duplicate spoils the hash.

This is defined in RFC 6376, section 5.5: the header field names in the h= tag must be unique. Any duplicate entry disrupts the verification process. Receiving servers, including those run by Gmail, Outlook, and major ISPs, enforce this rule strictly. A failed hash means the signature is rejected, no matter how legitimate the sender appears.

Why MailTester Flags This Explicitly

MailTester detects the structural flaw in your DKIM signature and returns DKIM=fail with clear insight into the root cause. It doesn’t just say “invalid” — it identifies that the h= tag contains a repeated header. This is critical for troubleshooting, because some tools only report “fail” without context.

For example, if your email client or ESP incorrectly adds a duplicate Received: or Message-ID: header during routing, the hash will not match. Fixing it means reviewing your email generation pipeline, removing duplicate header injection, and ensuring only one instance of each header is present before signing.

To verify your headers are clean before sending, you can run a real-time check using the MailTester email checker for individual addresses or integrate the verification API to validate hundreds at once. These tools help catch DKIM issues early, before they impact deliverability.

Always review your outbound email headers using tools like MXToolbox or ExtraHop to audit header structure. A clean header set is the foundation of a valid DKIM signature.

How to Diagnose h= Tag Issues in DKIM Signatures

When your MailTester DKIM=fail error mentions an incorrect h= tag, it usually means your DKIM signature lists headers that aren’t in the email, are duplicated, or include unintended ones. You need to inspect the raw email source, check the h= tag in the DKIM-Signature header, and ensure every listed header appears exactly once and only the ones you intended to sign.

Step-by-step diagnosis of h= issues

  1. Fetch the raw email source from your mail server or SMTP provider’s delivery logs. This is the unaltered version of what was sent—essential for accurate DKIM analysis.
  2. Locate the DKIM-Signature header. Find the h= tag—it lists all headers used in the signature, separated by colons. For example: h=from:to:subject:date:message-id.
  3. Check that each header name in the h= list appears exactly once in the raw email. Duplicate header names (like two From: or Date:) break DKIM verification. This is enforced by RFC 6376, the standard governing DKIM.
  4. Verify that only headers you intended to sign are listed. If your h= includes delivered-to, list-unsubscribe, or an X-header you didn’t sign, the signature fails. The signature must match the exact set of headers sent.
  5. Use a DKIM validator tool like MXToolbox’s DKIM Record Checker to test the signature with your email’s raw source. It will flag mismatches between the h= tag and actual headers.

Common pitfalls and fixes

  • Some SMTP providers or email templates automatically add headers (like feedback-id or Received) that weren’t in the original message. These can cause h= mismatches if not accounted for.
  • Double-check header order. Even if names are correct, misordering in the h= tag breaks verification. The order must match exactly.
  • If you’re using a third-party mailing service, confirm that it doesn’t inject headers during relay. This is common in cloud email platforms.

Once verified, you can test the fix using MailTester’s inbox placement tester to confirm your DKIM signature passes with the correct h= configuration.

Common Header Names That Break DKIM When Repeated

DKIM verification fails when you repeat certain header names—especially From, To, Subject, or Message-ID—because DKIM canonicalization processes these headers strictly. Repeating them violates RFC 5322’s single-value rule for these fields and triggers a DKIM=fail due to an incorrect h= tag. This is a common but avoidable issue in bulk emails or poorly formatted templates.

Headers That Must Appear Only Once

  • Use only one From: header. Multiple instances cause canonicalization errors—DKIM expects one source address. RFC 5322 explicitly defines this field as singular. You can fix this in your email client or library by ensuring only one is emitted.
  • Only one To: header should exist. Duplicate entries, often from misconfigured bulk tools, break DKIM. Let’s say you’re using a template system—check that it doesn’t add To: for every recipient. MailTester’s bulk verification can catch malformed templates before you send.
  • Subject: must be single. Appending multiple subjects (e.g., from merge fields) causes header duplication. DKIM’s h= tag includes Subject—repeating it invalidates the signature.
  • One Message-ID: per message. Generating multiple IDs (e.g., from a flawed queue system) breaks DKIM and triggers DKIM=fail. This is a common problem in email automation pipelines. Use a reliable MTA or library that ensures uniqueness.
  • Ensure Date: appears only once. Some systems append dates during relays or retries. DKIM’s canonicalization relies on one Date header. Too many break signature validation.
  • MIME-Version: should appear once at the top. Repeating it confuses parsing; it’s not meant to be duplicated. Most email libraries handle this correctly, but custom renderers can accidentally include it multiple times.
  • Content-Type: must not be repeated. This field is critical for MIME parsing. Multiple instances are invalid and break DKIM’s header hash computation.
  • Never repeat Received: headers unless explicitly added by intermediate servers. While some relays insert Received headers, multiple entries from one source (e.g., a misconfigured script) break DKIM. The h= tag in DKIM assumes a minimal, clean header set.

How to Catch and Fix These Issues

Most DKIM failures from repeated headers are not detected during delivery but only in email analysis tools or inbox placement tests. Let’s say you send 1,000 emails and get a 30% bounce rate—the root cause may be hidden in header inconsistencies.

Use the inbox placement tester to simulate delivery with real mailbox filters. It will flag DKIM issues from bad header formatting, including repeated field names. If you're using a script or API, validate header output against RFC 5322 before signing. Always canonicalize headers using the relaxed mode (recommended for most use cases) to avoid unnecessary failures.

Why MailTester Flags These Errors—And Why It Matters

MailTester catches DKIM=fail errors caused by repeated headers in the h= tag because it validates the signature by reconstructing the email’s header layout exactly as it was signed. Even if the email arrives, a mismatch between the signed headers and the actual message structure breaks DKIM, risking reputation and inbox placement. You can’t trust deliverability if your signature doesn’t match reality.

How MailTester Validates DKIM Signatures

Unlike some tools that accept a raw DKIM result at face value, MailTester rechecks the h= tag by parsing the entire header block and verifying the order and presence of each listed header. It compares this against the real-time header layout in the incoming message. If a header appears more than once in h=, or if a header listed in h= is missing, the signature fails.

For example, if the h= tag includes to:from: but the actual email has two From: headers (which is invalid), MailTester flags it as DKIM=fail. That's not just theoretical — it’s how DKIM is designed to work. See RFC 6376 for the spec. The standard requires the signed headers to match exactly, so any deviation invalidates the signature.

Why This Matters for Deliverability

DKIM=fail doesn’t just stop a single email. It degrades sender reputation over time. ISPs like Gmail and Microsoft track signature consistency, and repeated failures signal poor sending hygiene — often leading to filters or rate limiting.

Let’s be clear: an email can be delivered even with a failed DKIM signature. But it lands in the “suspicious” category. This reduces inbox placement, delays delivery, and increases the risk of being quarantined. Fixing h= issues before sending prevents this — not after you’ve already built up a bad history.

Use MailTester’s bulk verification to test your entire list before sending. It checks DKIM, MX, syntax, and server responses in real time, catching header layout errors early. This means fewer bounces, cleaner data, and better long-term sender reputation.

How to Fix h= Tag Errors in Your Email Infrastructure

If your DKIM signature shows DKIM=fail due to an incorrect h= tag with duplicated headers, you're likely signing the same header multiple times during the signing process. This violates the DKIM specification, which requires each header to appear only once in the h= list. Fix it by ensuring your signing logic processes headers in a single pass and includes each name exactly once.

Identify and Fix the Root Cause

  1. Review your DKIM signing logic to confirm it doesn’t loop over the header list multiple times. Repeated iterations can cause the same header to be added to the h= tag more than once. Use a set or map to track which headers have already been included during signing.
  2. Use a single pass through the header list when generating the h= tag. Looping over the list more than once—especially if done recursively or in a faulty order—introduces duplicates. A single, deterministic traversal avoids this issue entirely.
  3. Check for duplicate headers injected by third-party services like SendGrid, Mailchimp, or Amazon SES. These services can prepend or append headers (e.g., X-Feedback-ID, Feedback-ID) that may be treated as unique, but if your signing process doesn’t filter or normalize them, you risk duplication. Verify your email’s raw payload matches what’s expected.
  4. Validate signatures using raw email dumps before sending. Extract the raw message (including all headers and body) before delivery and test it against a DKIM validator. Services like MXToolbox’s DKIM checker can help confirm the h= tag is correctly formatted and free of duplicates.

Test and Verify Correctly

Even if your code seems right, unintended side effects from email routing, MTA processing, or header normalization can still inject duplicates. Always inspect the full email as it's being sent, not just the original template or API request.

Let’s say you're using a mail service that adds multiple Received headers—these must be excluded from the h= list unless explicitly required. The DKIM standard, defined in RFC 6376, specifies that only a predefined list of headers may be included, and they must not repeat.

Use tools like MailTester’s Inbox Placement test to simulate delivery and check whether your DKIM signature passes in real-world inboxes. It captures the full delivery stack, including all MTA-processed headers, so you can spot issues before they affect your sender reputation.

How MailTester Prevents Delivery Failures Before They Happen

You're sending emails with a DKIM=fail, but the real issue isn’t just the signature—it’s that the h= tag in your DKIM signature is misaligned with the actual headers in your message. MailTester’s real-time verification API catches this before you send by inspecting your email’s exact header structure. It flags mismatches in the h= tag—like repeated or missing headers—so you can fix them before delivery fails or your sender reputation is hurt. This proactive check helps you avoid bounces, spam folder placement, and long-term deliverability damage.

DKIM Signature Validation With Real Header Inspection

DKIM signatures rely on a precise header alignment. If the h= tag lists headers that aren’t in the actual message—or lists them multiple times—the signature fails, even if the cryptographic key is correct. MailTester’s API doesn’t guess. It parses your complete email as it would be delivered, verifying that every header counted in the h= tag is present exactly once and in the right order.

This process mirrors how receiving mail servers validate DKIM, based on the standards outlined in RFC 6376. A mismatch here is a common root cause of failed authentication, especially in automated or templated campaigns. MailTester surfaces the issue immediately, so you aren’t left wondering why your carefully crafted message is getting rejected.

Inbox Placement Testing Confirms Real-World Delivery

Even with a DKIM=fail, some messages still land in inboxes—especially if the receiving server relaxes checks or sees other positive signals. But you can’t rely on that. MailTester includes inbox-placement testing, which sends your message to actual inboxes across Gmail, Outlook, Apple Mail, and other major providers. It reports whether your email arrived, flagged as spam, or blocked—all based on real-world results, not assumptions.

With this, you can test whether a message that fails DKIM due to an h= misalignment still reaches its intended recipients. That’s critical for deciding whether to fix the issue or accept the risk. You’ll see the outcome in seconds, not days. Use this to test your email before sending to a full list. Test your email in real inboxes to validate deliverability—before you send.

By catching h= tag errors early and validating deliverability in context, MailTester doesn’t just verify addresses—it prevents failures before they happen. You gain precise clarity without guesswork, and send with confidence.

What Happens If You Ignore h= Tag Repeats in DKIM?

If you ignore malformed DKIM signatures caused by repeated headers in the h= tag, your emails may be rejected by receiving servers—even if the cryptographic signature is technically valid. This happens because email security systems like DKIM validate the exact header list used in the signature. Repeated or incorrectly ordered headers break the verification process, leading to DKIM=fail. Even one failure can trigger DMARC policies that quarantine or reject your message, reducing inbox placement. It’s not just a technical glitch—it erodes sender reputation over time.

Receiving Servers Can Reject Validly Signed Messages

DKIM is designed to verify that headers haven’t been tampered with during transit. The h= tag specifies exactly which headers are included in the signature. If the same header appears more than once in that list—say, Received or Date—the receiving server sees this as a mismatch between the expected and actual header set. Even if the signature matches the content, the validation fails. This is governed by RFC 6376, which defines how DKIM signatures are processed and validated.

DMARC Enforcement Amplifies the Impact

Most domains with DMARC set to policy=reject or quarantine will act on DKIM failures, regardless of whether the message was actually forged. If your DKIM check fails due to a malformed h= tag—such as duplicate or improperly ordered headers—your email gets treated as untrusted. Over time, repeated failures like this degrade your sender reputation. Even if the next email is perfectly signed, the cumulative history of failures can result in consistent filtering or rejection by major providers like Gmail, Outlook, or Yahoo.

Let’s be clear: a single signature failure doesn’t crash your deliverability. But when it happens at scale—across thousands of messages—it compounds. One repeated header in the h= tag might go unnoticed in a single test, but in bulk sends, it becomes a systemic issue. Use tools like MailTester’s inbox placement tester to see how emails are being processed and flag such issues before they affect your sender reputation.

How to Test and Validate Fixed DKIM Signatures

Run an inbox-placement test via MailTester to verify that emails with corrected DKIM signatures now pass filtering and land in inboxes. Check the full DKIM result in the detailed report—ensure you see DKIM=pass after fixing the h= tag to avoid repeated headers. Then, monitor deliverability metrics across your campaigns to confirm long-term improvements.

Test the Fix in Practice

  1. Use MailTester’s inbox-placement test to send a sample email through real inboxes (Gmail, Outlook, Apple Mail). This simulates how your email behaves when sent at scale—especially important after adjusting DKIM. Unlike basic syntax checks, this shows whether the fix actually allows delivery. Test inbox placement to see real results.
  2. Review the full DKIM result in the detailed report. Look for DKIM=pass in the raw results, not just a status light. If you still see DKIM=fail, the h= tag likely still includes duplicate or incorrectly ordered headers. The DKIM RFC specifies that h= must list only unique, canonicalized header names—repetition breaks validation.
  3. Verify the header list in the h= tag matches your email’s actual headers. Use a tool like MxToolbox to analyze an email’s raw source. Compare this to your DKIM signature’s h= value. Any extra or duplicated header names here will trigger a DKIM=fail.

Confirm Lasting Deliverability

After validation, track deliverability trends across your campaigns. Look for drops in hard bounces, improvement in open rates, and reduced time to inbox. A fix that passes one test doesn’t guarantee ongoing success—spammers often use valid-looking headers. Monitor for long-term stability.

  • Check deliverability via your ESP (SendGrid, Mailchimp) or a third-party tool like Spamhaus—it tracks sender reputation and blocklisting in real-time.
  • Use the bulk verification feature to clean your list before sending, ensuring future emails have valid DKIM signatures from the start.
  • Automate validation using the real-time verification API to catch invalid or improperly signed addresses before they reach your mail server.

Conclusion: Fixing DKIM=fail Starts With Header Integrity

DKIM=fail due to incorrect h= tags is a frequent but solvable problem. The root cause often lies in repeated header names during signing, which breaks the cryptographic validation process even if the signature itself is correct.

Even minor issues—like duplicate header fields or improperly ordered headers—can trigger rejection. MailTester identifies these errors early by testing the full email envelope, including header structure, before delivery.

Proactive header validation isn’t just about compliance—it keeps sender reputation intact and inbox placement high. With 98.9% accuracy, MailTester catches these flaws before they impact deliverability.

Sources

Keep reading

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

Frequently asked questions

What does DKIM=fail mean in MailTester?

It means the DKIM signature verification failed. This often stems from incorrect header hashing, including repeated header names in the h= tag.

Can an email pass DMARC if DKIM=fail due to h= tag issues?

No. DMARC requires either SPF or DKIM to pass. A DKIM=fail from a header error will trigger DMARC failure and may result in email rejection or quarantine.

How do I check the h= tag in a DKIM signature?

View the raw email source. Look for the DKIM-Signature header. The h= tag lists the headers used in the hash calculation.

Are repeated headers in h= tag common in email systems?

Yes. Some email providers or custom routing logic add header names multiple times during signing—especially in complex pipelines or third-party integrations.

Can MailTester detect malformed DKIM signatures?

Yes. MailTester validates the structure and integrity of DKIM signatures, including header hashing and the h= tag, reporting issues like repeated or missing headers.

Does MailTester work with SendGrid and Mailchimp?

Yes. MailTester integrates with SendGrid, Mailchimp, Klaviyo, and HubSpot to verify email lists and test deliverability, including DKIM validation.

What’s the difference between DKIM=fail and DKIM=pass in MailTester?

DKIM=pass means the signature and header hash match. DKIM=fail means they don’t—often due to incorrect h= tag configuration or repeated headers.

How accurate is MailTester’s DKIM verification?

MailTester’s email verification has 98.9% accuracy in identifying valid, invalid, and risky addresses—including issues like incorrect DKIM header hashing.

Can I fix DKIM=h= tag issues without changing my email provider?

Yes. If you have control over the signing process—via a custom SMTP, API, or email gateway—you can correct header duplication manually.

How many free verifications does MailTester offer?

MailTester provides 100 free verifications to start, with purchased credits that never expire.

Do DKIM failures affect sender reputation?

Yes. Repeated DKIM failures signal misconfiguration. Over time, this harms sender reputation and increases the chance of email being blocked by receivers.

What headers should be in the h= tag for a standard email?

Typically: From, To, Subject, Date, Message-ID, MIME-Version, Content-Type. Avoid duplicates, and never include headers like Received or Return-Path twice.