DKIM glossary
What are the b= and bh= tags in a DKIM signature?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
In a DKIM-Signature, bh= is the hash of the canonicalized message body, and b= is the cryptographic signature over the selected headers (which include bh=). So tampering with the body breaks bh, and tampering with the headers breaks b. The infamous 'body hash did not verify' error points straight at bh.
b= / bh= at a glance | |
|---|---|
| Tag | b (signature) and bh (body hash) |
| Valid values | Base64 values — bh= is the body hash, b= is the header signature |
| Default | Both are required; a DKIM-Signature is incomplete without them. |
| Where it goes | In the DKIM-Signature header; b= is conventionally last. |
How b= / bh= works
A DKIM signature has two hashes doing two jobs. bh= is the hash of the canonicalized message body. b= is the cryptographic signature over the signed headers — the fields named in h=, plus the DKIM-Signature header itself, which contains bh= (with b= blanked during signing).
Because of that split, the two failure modes are distinct. Tamper with the body and bh no longer matches — the body hash fails. Tamper with a signed header and b no longer verifies — the header signature fails. The famous 'body hash did not verify' error means the body changed after signing, full stop.
In practice, body-hash failures almost always come from something rewriting the body in transit: a mailing list appending a footer, a security gateway adding a disclaimer, or an encoding change (for example, re-wrapping or re-encoding the text). The content still looks fine to a human, but the bytes changed, so bh breaks.
Correct record vs common mistake
Correct
DKIM-Signature: ...; bh=2jUSOH9NhtVGCQ...; b=AuUoFEfDxTDkHlLX...bh= holds the body hash and b= holds the header signature. Body untouched and headers intact means both verify and DKIM passes.
Common mistake
DKIM-Signature: ...; bh=2jUSOH9NhtVGCQ...; b=AuUoFEfDxTDkHlLX... [footer appended in transit]A mailing list appended a footer, changing the body. bh no longer matches the delivered body, so verification fails with 'body hash did not verify'.
Troubleshooting b= / bh=
| Issue | Likely cause | Fix |
|---|---|---|
| 'body hash did not verify' | The body was modified after signing — often an appended footer or disclaimer | Stop the gateway or list from altering the body, or have it re-sign after modifying |
| Header signature (b=) fails | A signed header was changed in transit | Sign only stable headers and use relaxed header canonicalization |
| DKIM fails only through a mailing list | The list appends footers or rewrites the subject after signing | Rely on the list's own DKIM/ARC, or exclude modified headers from h= |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
Client mail that flows through mailing lists, ticketing systems, or gateways that append disclaimers will hit body-hash failures — DKIM breaks even though the mail is genuine. Across tenants this masquerades as an authentication problem when it's really a mail-flow one, and it can stall a domain short of reject.
Trusted by MSPs
“Their responsive support, agent task lists, white-label reporting, and centralized dashboard make managing our customer domains, effortless.”
Bobby Ghoshal — CEO, dupe.com
Enforce it — don't just monitor it
Palisade reads whether DKIM is failing on the body hash versus the header signature straight from the reports, so a footer-appending gateway is diagnosed as mail flow — not treated as a reason to hold the domain back from reject.
Free 15-day trial · No credit card · Your own domain free forever (NFR)