A body-hash mismatch points to changed signed body content. Compare a controlled message before and after each processing hop, then move the change before DKIM signing or stop it.
A message leaves your sending service with a DKIM signature, but the receiver reports dkim=fail with a body-hash error. The first useful question is not whether the DNS key is missing. It is: what touched the body after it was signed?
DKIM puts a hash of the canonicalized body in the signature's bh= tag. The receiver calculates that hash again from the body it actually received. If the two differ, verification fails before the receiver checks the header signature in b=. This sequence is defined in RFC 6376, Section 6.1.3. A body-hash error therefore narrows the search, but it does not identify the system that made the change.
Read the signature before changing DNS
Save the raw message from a mailbox you control. In the receiver's trusted Authentication-Results, find the failing DKIM result and its signing domain. Then inspect the matching DKIM-Signature header: d= is the signing domain, s= is the selector, bh= is the body hash, and c= names the header and body canonicalization modes. A message can carry more than one DKIM signature, so do not assume the first header is the one that failed.
A missing key, revoked selector, or malformed signature is a different investigation. If the receiver explicitly reports a body-hash mismatch, changing the TXT key record will not restore the original body bytes. The exact error wording varies by receiver; preserve the raw message and the receiver's result as your evidence.
What can change the body?
- A forwarding service or mailing list adds a footer, unsubscribe text, or subject and content wrapper after the original sender signed.
- An outbound gateway appends a legal disclaimer, rewrites links, or changes a MIME part after an upstream service applied DKIM.
- An integration changes HTML, text, attachment encoding, or line breaks between its signing stage and delivery. Diagnose this with actual message copies; a dashboard template preview is not the transmitted MIME body.
DKIM's relaxed body canonicalization tolerates certain whitespace changes, including trailing whitespace and runs of spaces within a line. It does notmake an added footer or rewritten URL harmless. simple body canonicalization tolerates only empty lines at the end. The exact rules are in RFC 6376, Section 3.4.
Isolate the hop that changes it
- Send a small, unique test message through the normal route to a mailbox you control. Retain its raw source, complete headers, and the timestamp.
- Send the same content through a controlled route that bypasses one downstream processor at a time. Compare the raw MIME body and DKIM result for each route. Keep the sending domain, signer, and template fixed so the comparison is meaningful.
- Where you operate the gateways, capture a safe pre-change and post-change copy at the suspected hop. Compare line endings, MIME boundaries, transfer encoding, text, HTML, footers, and URLs. Avoid circulating real customer messages for this test.
- Move legitimate content changes before the final DKIM signing step, disable the downstream rewrite, or arrange a new aligned signature after that change where you control the signer. Retest the complete production path.
Do not use the optional DKIM l= body-length tag as a quick workaround. It can let appended content sit outside the signed portion; receivers may treat that unsigned content as suspicious. RFC 6376 explicitly warns about this in Section 8.2.
Check the DMARC consequence separately
A failed DKIM signature does not automatically mean DMARC fails. An aligned SPF result can still satisfy DMARC. Conversely, SPF can break on forwarding, leaving a passing aligned DKIM signature especially valuable. Check the receiver's DMARC result and the visible From domain, rather than inferring policy outcome from one DKIM line. The current DMARC evaluation rule is in RFC 9989, Section 5.3.5.
Finish by sending a fresh message through every affected path. Confirm a passing, aligned DKIM signature at the receiver, and monitor the corresponding aggregate-report rows for recovery. The useful fix is the one that survives the real route, not merely the provider's signing test.
Disclosure: AI tools were used in the process of creating this blog post.