DKIM Body Hash Mismatch: How to Fix bh= Verification Failures

Understanding DKIM Body Hash

When your email server signs a message with DKIM, it:

1. Takes the email body
2. Applies canonicalization (normalizing whitespace, etc.)
3. Hashes the result using SHA-256
4. Includes this hash as the bh= tag in the DKIM-Signature header

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    h=From:To:Subject:Date;
    b=...

When a receiving server verifies DKIM:

1. It hashes the received body using the same method
2. Compares the result to the bh= value
3. If they match, body verification passes
4. If they don't match, DKIM fails with "body hash mismatch"

Common Causes

1. Mailing List Software

Mailing list managers (Listserv, Mailman, Google Groups) often:

• Add footers with unsubscribe links
• Add list headers
• Wrap the message in a new MIME structure

Any of these changes break the body hash.

Example: You send to a mailing list, the software adds "To unsubscribe, visit..." at the bottom, and DKIM fails for all recipients.

2. Corporate Email Gateways

Many corporate email systems:

• Add legal disclaimers ("This email is confidential...")
• Append compliance notices
• Insert tracking pixels

If these are added after DKIM signing (which is almost always the case), body hash fails.

Practitioner note: I see this constantly with B2B email. Company A sends properly signed email, Company B's email gateway appends a disclaimer, DKIM fails. Company B's IT department wonders why all email from Company A "fails authentication" — it's their own system breaking it.

3. Antivirus/Security Scanners

Security appliances that scan email content may:

• Rewrite URLs to go through a safe-link service
• Remove attachments
• Modify HTML to strip scripts
• Add "Scanned by" notices

4. Email Forwarding

When email is forwarded:

• Fwd: prefix may be added to subject (handled by header hash, not body)
• Original message wrapped as attachment (changes body)
• Forward adds "---------- Forwarded message ----------" (changes body)

5. Content Modification by Sender's Infrastructure

Sometimes the issue is on the sending side:

• Marketing platform rewrites tracking links after signing
• Outbound security gateway modifies content
• Email goes through multiple hops before leaving your infrastructure

6. Character Encoding Issues

Conversion between character encodings:

• UTF-8 to ISO-8859-1
• Line ending changes (CRLF vs LF)
• Quoted-printable encoding changes

These are rarer but can cause hash mismatches.

Diagnosing the Problem

Step 1: Check DKIM Results in Headers

Look at the Authentication-Results header:

Authentication-Results: mx.google.com;
    dkim=fail (body hash did not verify) header.d=example.com;

The "(body hash did not verify)" confirms it's a bh= mismatch, not a signature or key issue.

Step 2: Compare Original and Received Message

On the sending side:

1. Send a test email to yourself
2. Check your "Sent" folder for the original
3. Save the exact content

On the receiving side:

1. View the raw message source
2. Compare to original
3. Look for any additions or changes

Step 3: Trace the Message Path

Examine Received headers (read bottom to top):

Received: from gateway.recipient.com (handling mail for recipient.com)
Received: from filter.securityvendor.com (security scanning)
Received: from outbound.yourdomain.com (original sender)

Each hop is a potential modification point.

Step 4: Test Direct Delivery

Send a test email that bypasses intermediaries:

• Direct to a personal Gmail account (not through corporate gateway)
• Not through mailing lists
• Not through forwarding rules

If DKIM passes on direct delivery but fails through intermediaries, you've identified the cause.

Solutions

Solution 1: Accept That Intermediaries Break DKIM

This is the reality of email. Mailing lists, forwarders, and corporate gateways will modify messages. You can't prevent it.

What you can do:

• Ensure SPF is also configured (provides alternative authentication path)
• Set up DMARC with both SPF and DKIM alignment options
• Use ARC (Authenticated Received Chain) if intermediaries support it

Solution 2: Fix Sender-Side Modifications

If your own infrastructure modifies messages after signing:

1. Move DKIM signing to the final hop — Sign at the last server before the message leaves your network
2. Disable post-signing modifications — Configure security tools to not modify outbound email
3. Audit your email pipeline — Map every hop and identify where content changes

Practitioner note: A client once had DKIM failing on all marketing email. Turns out their outbound security gateway was rewriting tracking URLs to go through their corporate proxy — after the ESP had already signed. Moving the gateway rewrite to before the ESP fixed it.

Solution 3: Use DKIM Body Length Limit (l=)

DKIM allows a l= tag to specify how many bytes of the body to hash:

DKIM-Signature: ... l=1234 ...

This means only the first 1234 bytes are hashed. If modifications happen after that point (like appended footers), the hash still matches.

Warning: This weakens security. Attackers could theoretically append malicious content after the signed portion. Most security experts recommend against using l=.

Solution 4: Configure ARC on Intermediaries

ARC (Authenticated Received Chain) allows intermediaries to preserve authentication results. If a mailing list or forwarder supports ARC:

1. It records the original DKIM/SPF/DMARC results
2. Signs this record with its own key
3. Downstream servers can see the original authentication passed

You can't force intermediaries to implement ARC, but you can:

• Choose mailing list providers that support it
• Ask corporate partners to enable it on their gateways

Solution 5: Separate Signing for Different Channels

If certain channels always go through modifying intermediaries:

• Use a subdomain for mailing list posts
• Accept DKIM failure there
• Rely on SPF for that subdomain's authentication

Prevention Checklist

• Sign email at the last possible point in your infrastructure
• Audit outbound email path for any content modification
• Configure both SPF and DKIM (redundancy)
• Set up DMARC monitoring to catch failures
• Test email to multiple destinations (direct Gmail, corporate addresses, mailing lists)
• Document known DKIM failures from specific channels

If you're seeing consistent DKIM body hash failures and can't identify the cause, schedule a consultation — I'll trace your email path and find where modifications happen.

Sources

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8617: Authenticated Received Chain (ARC)
• Google: DKIM authentication
• DMARC.org: Mailing Lists and DKIM

---

v1.0 · March 2026