DKIM Body Hash Did Not Verify: What Broke?

Your message changed after it was signed

A DKIM body hash failure means the receiver got a message body that no longer matches the body your sender signed. One added footer, one rewritten link, or one rewrapped MIME part can be enough.

DKIM signs selected headers and a hash of the message body. That body hash is stored in the bh= tag of the DKIM-Signature header. When Gmail, Outlook, or another receiver checks the message, it rebuilds the body using the canonicalization named in the signature, then compares the hash. If the values differ, you see errors like dkim=fail (body hash did not verify).

This error points to the body, not the DNS key. Most cases come from a service that changed the body after signing: a footer, tracking link, MIME rewrite, quoted-printable rewrap, charset change, or security gateway rewrite. A bad selector or public key can also break DKIM, but that is a different failure. RFC 6376 defines DKIM selectors, canonicalization, body hashes, and the optional l= body length tag.

Check the message path first

Do not start by editing DNS. First find the last system that touched the message before it reached the receiver.

• Open the raw message and find the Authentication-Results header. Confirm the exact DKIM result and the signing domain in d=.
• Find the matching DKIM-Signature. Note s= for the selector, d= for the signing domain, c= for canonicalization, and bh= for the body hash.
• Trace the Received headers from bottom to top. Look for a gateway, CRM, ticketing tool, forwarding service, mailing list, antivirus scanner, or footer tool after the signer.
• Send the same message directly from the signing service to a test mailbox. If DKIM passes direct but fails through another hop, that hop is changing the body.
• Check whether the message is signed before tracking links, unsubscribe text, legal disclaimers, or open tracking pixels are added. Sign after those changes whenever you control the system.

Common body changes include HTML minifiers, click tracking rewrites, list footers, quoted-printable rewrapping, charset conversion, and security gateways that rewrite links. A DKIM signature with c=simple/simple is strict. relaxed body canonicalization ignores some whitespace at line ends, but it will still fail when real content changes.

Rule out a second DKIM problem

A body hash mismatch is usually a changed message, but the same test message can also expose selector or key mistakes.

The selector is the s= value. The lookup name is usually selector._domainkey.example.com, using the selector and the d= domain from the signature. That name should resolve to the DKIM public key, often as a TXT record and sometimes through a provider CNAME. If your email provider rotated keys, changed selectors, or signs as a different domain than you expected, old records can cause a separate DKIM failure.

• Confirm the selector from the failed message resolves to the public key your sender uses now.
• Confirm the signing domain in d= is a domain you control or a domain your provider is allowed to use.
• Use 2048-bit DKIM keys when your provider and DNS host support them. Google requires at least 1024 bits for mail sent to personal Gmail accounts and recommends 2048 bits.
• Remove stale selectors only after old mail has aged out and no sender still uses them.
• Avoid relying on the DKIM l= tag as a fix. It can leave added body text outside the signed part, which weakens the promise DKIM makes.

A bad selector record can cause DKIM verification to fail, but it does not explain the body hash text by itself. If the body hash failed, keep looking for body changes before you blame the key.

Make sure SPF and DMARC still protect you

DKIM can fail on forwarded or modified mail. DMARC decides whether another aligned authentication result can still carry the message.

DMARC passes when SPF or DKIM passes and aligns with the visible From domain. A domain can start with p=none to collect reports, then move to p=quarantine or p=reject after all real senders pass. Add a rua=mailto: address so aggregate reports show which systems pass, fail, and drift over time. RFC 7489 defines those policy values and reports.

SPF still matters when DKIM breaks, but SPF has its own traps. Publish one SPF TXT record for the domain. Use ~all while you are still finding every real sender. Use -all only when the list is complete. RFC 7208 sets a 10 DNS lookup limit for SPF mechanisms and redirects that cause DNS queries. Too many nested include: records can turn SPF into a permanent error.

MX records do not make DKIM pass, but missing or broken MX can hurt replies and domain trust. Blocklists can also affect placement, especially when a shared IP or compromised sender has a poor history. Gmail says authenticated mail is less likely to be rejected or marked as spam. Microsoft says high-volume senders to Outlook.com, Hotmail.com, and Live.com must meet SPF, DKIM, and DMARC requirements. Authentication proves identity. Reputation, complaints, content, volume, and list quality still decide inbox versus spam.

A practical fix order

Use the error as a trail. The fastest fix is usually to move DKIM signing later in the sending path.

• Send a fresh test message and save the raw source from the mailbox where DKIM failed.
• Identify the signing domain and selector from the failed DKIM-Signature.
• Bypass each middle service until DKIM passes, then fix the service that changed the body.
• Configure your ESP, CRM, or gateway so it signs after it adds links, pixels, footers, and unsubscribe text.
• If a mailing list must alter messages, have the list sign the final message and make DMARC pass with an aligned From, SPF, or DKIM setup.
• Check SPF, DMARC, MX, and common blocklists so one DKIM issue does not hide a larger deliverability problem.

You can run a free domain scorecard in InboxRadar to check the public SPF, DKIM, DMARC, and MX records that receivers see. For the message-level failure, keep the raw failed message. DNS alone cannot prove who changed the body.