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= |
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
“We absolutely love it. We are actively selling it and growing the usage.”
Ravi Ramharak — Co-Founder, MSP Corp
DMARC software that does the work
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.
1 domain free up to 1,000 emails/month
Questions readers ask