Why is DKIM failing due to bh= value or showing as not verified, and is Proofpoint involved?
Updated on 17 Oct 2026: We clarified DKIM verification results, Proofpoint URL rewriting, and how to confirm a body hash mismatch.
A DKIM bh= error means the body checked by the receiver does not match the canonicalized body hashed when that DKIM signature was created. Proofpoint is involved only when the evidence shows that its handling changed the signed body. For example, Proofpoint Essentials can be configured to rewrite URLs in DKIM-signed messages, which invalidates the existing body hash. Banners, MIME changes, and other edits can have the same effect.
A body hash failure alone does not identify the system responsible. Prove where DKIM was checked, whether the body changed after signing, and whether failures cluster at Proofpoint-protected destinations. Start with DMARC aggregate data and full message headers before changing DNS, because a body hash failure usually points to message handling rather than a published key.
- The bh= tag contains a Base64-encoded hash of the signed message body after DKIM canonicalization.
- Proofpoint becomes a clue when URL Defense or another policy changes the body after signing.
- A "not verified" label can cover an unsigned message, a lookup error, or a failed signature. Read the exact header result.
- Confirm the cause with trusted headers and raw message captures; use DMARC reports to find affected reporting receivers.
What the bh= value means
A DKIM signature has two related checks. The bh= tag contains the body hash. The b= tag contains the cryptographic signature over the selected headers and the body hash. The receiver canonicalizes the body, hashes it, and compares the result with bh=. A mismatch makes that signature fail.
Illustrative DKIM-Signature, b= abbreviated
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date:mime-version:content-type; bh=z6TUz85EdYrACGMHYgZhJGvVy5oQI0dooVMKa2ZT7c4=; b=AbCdEf123456...
The c= tag sets header canonicalization first and body canonicalization second. If it is absent, both use simple; c=relaxed alone means relaxed headers and a simple body. Relaxed body canonicalization normalizes spaces and tabs within lines and removes trailing whitespace and empty lines. Simple body canonicalization ignores trailing empty lines and ensures a final CRLF. With the whole body signed, neither mode protects against URL substitution, footer insertion, MIME reconstruction, or transfer-encoding changes. These rules are defined in RFC 6376.
A bh= failure has a different root cause from a missing public key. A key lookup failure points to the selector or its DNS publication. A body hash mismatch points to message mutation in a sending platform, gateway, forwarding route, mailing list, or receiving security layer. If a capture immediately after signing already fails, check whether the signer hashed a different MIME serialization or non-SMTP line endings.
Read the failure text carefully
The phrase "DKIM not verified" is broad and does not always mean a body hash mismatch. Use the exact result in the Authentication-Results header added by a system you trust, then match it to the relevant DKIM-Signature fields. Results copied from an earlier untrusted hop are not reliable evidence by themselves.
If the question concerns the published selector, check the public key first with the DKIM checker. If the selector validates but receivers report body hash failures, inspect the mail route next.
What "DKIM not verified" means in the headers
"Not verified" is a display label, not a standard DKIM result. Read the trusted Authentication-Results header and its explanation. RFC 8601 distinguishes the results below.
|
|
|
|---|---|---|
dkim=none | No DKIM signature was found. | Confirm that this sending route signs messages. |
dkim=fail | An evaluated signature failed. | Use the reason to separate body hash mismatches from header or key failures. |
dkim=temperror | Verification encountered a temporary error. | Retry and investigate DNS timeouts or public-key lookup availability. |
dkim=permerror | An unrecoverable processing error prevented verification. | Inspect the stated error, including missing required fields. |
dkim=neutral | The signature was malformed or otherwise unprocessable. | Inspect signature syntax and the verifier explanation. |
dkim=policy | The verifier rejected an aspect of the signature under local policy. | Check the stated algorithm or key requirements. |
Standard DKIM results behind a broad not verified label
An absent Authentication-Results header does not establish a DKIM failure. Check the receiving system logs. A passing DKIM signature also needs a signing domain that matches the visible From domain under DMARC rules to satisfy DMARC.
Why DKIM can show pass and fail together
One message can contain several DKIM-Signature headers. A sending platform can add one signature and a later gateway can add another. Receivers evaluate each signature independently, so dkim=pass and dkim=fail can both be accurate for the same message.
Mixed DKIM results example
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=selector1; dkim=fail reason="body hash did not verify" header.d=relay.example header.s=gateway; dmarc=pass header.from=example.com
- Match every result to header.d and header.s instead of reading the results as one combined verdict.
- For DMARC, identify whether at least one passing signature uses a domain that matches the visible From domain under the domain's DMARC mode.
- Use Received headers and gateway logs to establish signing order. DKIM-Signature header order alone does not prove which system signed first.
- Investigate the failed signature only if its loss affects DMARC, routing policy, or a required trust decision.
How Proofpoint URL Defense affects DKIM
Proofpoint can occupy different positions in the route, and the position changes the diagnosis. If Proofpoint Essentials handles inbound mail and URL Defense is configured to rewrite URLs in DKIM-signed messages, Proofpoint can verify the original message and then alter its body. A later check in Google Workspace or Microsoft 365 can then report a body hash failure for the original signature.
Proofpoint's presence alone does not prove that it caused the change. Proofpoint's URL Defense documentation describes the Essentials setting "Re-write URLs that are located in DKIM signed messages". Confirm its state for the affected policy and compare captures before and after the gateway. Other Proofpoint products have different controls, so confirm the product before applying these steps.
If Proofpoint handles outbound mail, any content changes caused by scanning, URL rewriting, footer insertion, tracking, or MIME cleanup need to occur before the final DKIM signature. The last system that changes the body should apply a signature using a domain that DMARC accepts for the visible From address, or it should leave the signed body unchanged.
Inbound Proofpoint
- Proofpoint can validate first and then rewrite links for the protected mailbox.
- The final mailbox can fail the original signature because it receives the changed body.
- Check whether rewriting DKIM-signed messages is required by the active security policy.
- Where the gateway supports ARC sealing, preserve the earlier result in an ARC chain that the final receiver validates and trusts.
Outbound Proofpoint
- A sender can sign before a gateway edits links, banners, or MIME content.
- The external receiver then sees a body hash mismatch for that earlier signature.
- Apply the final signature after every expected edit and verify its domain against DMARC rules.
- Retest every policy route because only some routes can invoke message modification.
Proofpoint Email Protection URL Defense settings for URL rewriting.
How to prove the failure path
Group failures by receiver and route before making a DNS change. Test whether the same message passes at a controlled destination without Proofpoint and fails only after a Proofpoint route. Preserve the original message file because forwarding a sample can add another set of modifications.
- Send controlled tests through the normal and suspected routes, then download each original .eml file with full headers. Do not forward the samples inline.
- Match every dkim= result to its signing domain and selector, then note body hash, key lookup, syntax, or signature errors.
- Check ARC for evidence that a trusted earlier hop validated the message. ARC does not repair the failed DKIM signature, and the final receiver decides whether to trust the chain.
- Compare rewritten links, footers, MIME boundaries, content-transfer encoding, line endings, and inserted banners.
- Use DMARC aggregate data to group failures by observed source IP and reporting organization, then confirm the suspected route with per-message headers.
Compare captures of the same signed message at successive hops. Separately generated messages can have different personalization or MIME boundaries, so different hashes alone do not prove a gateway edit. Preserve raw MIME bytes and CRLF line endings. When recomputing bh=, use the body canonicalization in c=, the hash algorithm in a=, and any l= limit. Hash the encoded body, including MIME parts and encoded attachments, without decoding and resaving it.
Header evidence to look for
Authentication-Results: mx.example.net; dkim=fail reason="body hash did not verify" header.d=example.com header.s=selector1; spf=pass smtp.mailfrom=bounce.example.com; dmarc=pass header.from=example.com
The dmarc=pass line matters in this example. DKIM failed, but DMARC still passed because SPF passed and bounce.example.com matches the visible example.com domain under relaxed DMARC rules. If forwarding breaks SPF too, the same body hash problem can produce DMARC failure.
Do not treat a mailbox banner as the whole result
Mailbox labels compress several checks. A message can show DKIM failed after inbound rewriting even when an earlier trusted hop recorded a pass. DMARC aggregate reports show the broader pattern across receivers. Suped's DMARC monitoring workflow helps separate isolated receiver behavior from a sender-side regression.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
What to check when DNS looks correct
A correct DKIM DNS record does not guarantee DKIM pass. DNS publishes the public key, while the message must also arrive with the signed body intact and its signed headers valid. A selector can validate cleanly while the receiver still reports a bh= failure.
|
|
|
|---|---|---|
Body hash fail | Body changed after signing, or the signer hashed different bytes | Header states body hash did not verify |
Key not found | Missing or incorrect selector TXT record or CNAME target | Query s._domainkey.d using the signature's actual s= and d= values |
Signature fail | Signed header changed or signing key mismatch | Compare signed fields and public key |
Intermittent fail | Route-specific edits, inconsistent signing, or intermittent DNS errors | Compare exact errors by route, selector, and source IP |
DKIM symptoms and likely causes
Illustrative DKIM TXT record, public key abbreviated
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
If the signing domain, selector, and public key are correct, inspect message handling. Common causes include URL Defense rewriting, unsubscribe link substitution, open tracking, link branding, disclaimer insertion, HTML normalization, line-ending conversion, and gateways that rebuild MIME content.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
That widget answers the DNS portion of the question. It cannot prove that a later hop changed the body, because that proof is in message headers and controlled captures. For a broader authentication check, use the domain health checker after confirming that the DKIM selector is reachable.
When it matters for DMARC
A DKIM failure does not always produce DMARC failure. DMARC passes when at least one DKIM signature passes with a signing domain that matches the visible From domain under the published DKIM matching mode, or when SPF passes with an envelope domain that meets the SPF matching mode. A Proofpoint-induced body hash failure matters most after forwarding breaks SPF or when DKIM is the only method that can satisfy DMARC for that route.
|
|
|
|---|---|---|
Direct delivery without changes | Remains valid if it was valid when sent. | A passing signature satisfies DMARC when its domain matches the From domain under DMARC rules. |
Inbound body rewriting | Fails when a later verifier hashes the changed body. | SPF or another passing signature must satisfy DMARC. |
Forwarding with body changes | Fails; original-envelope SPF usually fails too. | DMARC fails unless another qualifying signature or SPF result passes. |
Qualitative outcomes, not measured failure rates
Forwarding alone does not break DKIM if the signed content survives. ARC carries earlier authentication results and can inform the final receiver's handling of a DMARC failure, but it does not repair the original DKIM signature or guarantee delivery. This distinction is described in RFC 8617.
Watch strict policies during investigation
If the domain already publishes p=reject and forwarded traffic loses both SPF and DKIM, legitimate mail can be rejected. Use aggregate reports to confirm affected receivers before changing policy or asking a gateway owner to adjust message handling.
How to fix the DKIM failure
The correct fix depends on whether the message changes before it leaves the sending environment or after it reaches the recipient's gateway. Apply the final DKIM signature after every expected body edit. Avoid later body changes unless the receiving route records and preserves the earlier authentication result in a way the final receiver trusts.
- Apply DKIM at the last outbound system that modifies the message body.
- Move tracking, footers, disclaimers, link rewriting, and MIME normalization before final signing.
- For inbound Proofpoint Essentials, review the documented URL Defense setting for rewriting DKIM-signed messages. Disabling it prevents that rewrite when policy permits; other body modifications still need investigation.
- Use ARC where the gateway supports it: record authentication before edits, seal after all modifications, and verify that the final receiver trusts the sealer and validates the chain.
- Use the body hash guide when the same failure appears across unrelated receivers.
Recommended outbound signing order
Create message Add tracking and unsubscribe links Add footer or compliance text Route through final outbound gateway Apply DKIM signature Send to recipient MX
A common mistake is signing inside the sending application and then allowing a downstream gateway to add compliance text or rewrite content. The failure can look intermittent because only certain campaigns, destinations, attachments, or policy routes trigger the modification. Relaxed body canonicalization helps with permitted whitespace changes, not rewritten content. Do not add an l= body-length limit to hide footer changes; bytes beyond that limit are unsigned.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When to contact Proofpoint
Contact Proofpoint or the Proofpoint administrator when captures point to a Proofpoint policy, route, or signing order. For inbound URL Defense, first confirm whether rewriting DKIM-signed messages is enabled and required. If policy permits an exception, preserving the original body can preserve the original signature.
- Provide the original message as an attached message file rather than forwarding it, plus a controlled pre-gateway sample when available.
- Include full headers, the Proofpoint message permalink for Essentials, timestamps with time zones, and affected policy routes.
- State whether Proofpoint handles inbound mail, outbound mail, or both for the affected traffic.
- List affected domains and receivers, then ask which policy changed the body and whether that change occurred before or after the final DKIM signature.
The Microsoft Q&A example shows mixed results for the same signing domain: one signature passed while another failed its body hash check. Match each result to its selector and verifying hop before assigning the failure to Proofpoint.
Use Suped to narrow DKIM failures
Suped's DMARC reporting and email authentication platform helps identify whether DKIM failures cluster by sending source and reporting receiver. Compare those groups with known forwarding routes. Filter aggregate data for DKIM failures, compare SPF on the same traffic, and use alerts to catch a change in failure rate after a routing or signing change.
DMARC aggregate reports do not contain message bodies or full headers. They can include per-signature domains and selectors plus optional human_result diagnostics, but a body hash reason is not guaranteed. RFC 9990 defines this optional field. Reporting organizations are not a list of individual destination mailboxes. Use Suped to narrow the affected traffic, then use original message headers and controlled captures to prove the modifying hop.
Use reports before changing records
When a sender reports a bh= failure, compare reporting receivers and sending sources in Suped, then check whether the pattern began after a routing or signing change.
Frequently asked questions
Usually no. A bh= failure means the body hash did not match. Check that the selector is reachable, but investigate post-signing body changes first.
The message has more than one DKIM signature, and receivers evaluate each signature separately. Match each result to its header.d domain and header.s selector.
Yes. If a Proofpoint policy rewrites URLs or changes other signed body content before delivery to Google Workspace, Gmail can evaluate the modified body and fail the original signature.
Not when Proofpoint changed the body inside the recipient's environment after recording the original result. Confirm the active URL Defense setting and the order of authentication checks before assigning ownership.
Yes. DMARC can pass through SPF when SPF succeeds and its envelope domain matches the visible From domain under DMARC rules. DMARC can also use another passing DKIM signature with a suitable signing domain.
Collect the original message file, full headers, every DKIM-Signature field, trusted Authentication-Results fields, a Proofpoint message permalink when available, timestamps with time zones, and controlled samples from affected routes.
