Why is DKIM failing due to bh= value or showing as not verified, and is Proofpoint involved?
DKIM fails because of the bh= value when the message body that the receiver checks is not the same body that was hashed when the sender signed the email. Proofpoint is involved when it rewrites links, inserts safety text, adds banners, changes MIME boundaries, or otherwise edits the body after the original DKIM signature was created. If Proofpoint is an inbound gateway in front of Google Workspace or Microsoft 365, the final mailbox can show DKIM as failed or not verified even though the original sender configured DKIM correctly.
The answer is not automatically "Proofpoint broke DKIM." The answer is: prove where DKIM was checked, prove whether the body changed after signing, and prove whether the failures are isolated to Proofpoint-protected destinations. I start with DMARC aggregate data and the full message headers before changing DNS, because a body hash failure is usually not a DNS problem.
- Body hash: The bh= tag is a hash of the signed message body after DKIM canonicalization.
- Proofpoint clue: Link rewriting or body modification after signing breaks the body hash.
- Not verified: This label covers several failures, including missing keys, bad signatures, and changed bodies.
- Fastest proof: Compare headers and DMARC results by receiver before opening a support case.
What the bh= value means
A DKIM signature has two hash checks. The bh= tag is the body hash. The b= tag is the cryptographic signature over selected headers plus that body hash. The receiver canonicalizes the body, hashes it, and compares the result to bh=. If the values differ, the body changed after signing.
DKIM-Signature body hash example
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=V7Qm9fK5Z9C7nM9M3Jk0k2Qy6f3v8x0x6o2b9uE=; b=AbCdEf123456...
That means a bh= failure has a different root cause than a missing public key. A missing key points at the selector, DNS record, or publishing domain. A body hash mismatch points at message mutation. That mutation can happen in a sending platform, an outbound gateway, a forwarding path, a mailing list, or an inbound security gateway.
Read the failure text carefully
The phrase "DKIM not verified" is broad. It does not always mean a body hash mismatch. I treat the exact receiver wording as evidence, then confirm it against the Authentication-Results header and the DKIM-Signature fields.
If the question is whether the published selector is valid, check the public key first with the DKIM checker. If the selector validates but receivers report body hash failures, the investigation shifts away from DNS and into the mail path.
Where Proofpoint fits
Proofpoint can be in several places in the path, and the position matters. If Proofpoint receives mail inbound, checks it, rewrites URLs for click protection, and then hands the modified message to Google Workspace, Gmail is checking a message body that no longer matches the original DKIM body hash. Gmail can show DKIM as failed, while Proofpoint already accepted the original signature earlier in the path.
If Proofpoint is part of the outbound sending path, the correct design is different. Any content scanning, URL rewriting, footer injection, tracking pixel insertion, or MIME cleanup needs to happen before the final DKIM signature is applied. The last system that changes the body should either sign the message or leave the body untouched.
Inbound Proofpoint
- Common pattern: Proofpoint validates first, then rewrites links for the protected mailbox.
- Mailbox result: The final mailbox can show DKIM failed because it sees the changed body.
- Risk level: This is usually expected when security rewriting happens after DKIM verification.
Outbound Proofpoint
- Common pattern: The sender signs, then a gateway edits links, banners, or MIME content.
- Receiver result: The external receiver sees a body hash mismatch and treats DKIM as failed.
- Fix path: Move signing later, stop post-signing edits, or re-sign after all edits.
Proofpoint Email Protection settings showing URL rewriting controls.
How to prove the failure path
The fastest way to avoid guesswork is to group failures by receiver and path. I do not start by editing DKIM records when the reported error says body hash. I first ask whether the same campaign passes at receivers without Proofpoint and fails only at recipients behind a Proofpoint gateway.
- Compare receivers: Send the same message to controlled mailboxes at different providers and compare headers.
- Read results: Look for body hash, selector errors, or key lookup errors in the receiver header.
- Check ARC: ARC can show that a trusted hop verified DKIM before the body was changed.
- Inspect changes: Compare links, footers, MIME structure, transfer encoding, and appended banners.
- Segment reports: Use DMARC aggregate data to find the receivers and source IPs where DKIM fails.
Header evidence to look for
Authentication-Results: mx.example.net; dkim=fail reason=body hash did not verify header.d=example.com spf=pass smtp.mailfrom=bounce.example.com dmarc=pass header.from=example.com
The dmarc=pass line is the clue that matters in this example. DKIM failed, but DMARC still passed because SPF passed for a domain relationship that DMARC accepts. If forwarding breaks SPF as well, then the same body hash problem becomes a DMARC failure.
Do not treat a mailbox banner as the whole truth
Mailbox UI labels compress a lot of detail. A message can show DKIM failed after inbound rewriting, while an earlier hop already verified it. DMARC aggregate reports give the broader pattern across receivers. Suped's DMARC monitoring workflow helps separate isolated receiver behavior from a real 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 will pass. DNS only publishes the public key. The message still has to arrive with the same signed body and the signed headers in a valid state. That is why a selector can validate cleanly while the receiver still reports bh= failure.
|
|
|
|---|---|---|
Body hash fail | Body changed | Header says bh= |
Key not found | Bad selector | Check s= and d= |
Bad signature | Header changed | Compare signed fields |
Intermittent fail | Some path edits | Group by receiver |
DKIM symptoms and likely causes
DKIM DNS record shape
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
If the selector, domain, and public key are correct, look at message handling. Common causes include URL defense rewriting, unsubscribe link substitution, open tracking, link branding, disclaimer insertion, HTML normalization, line ending changes, and forwarding systems that repackage 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 lives in the message headers and receiver data. For a broader check across SPF, DKIM, and DMARC, use the domain health checker after you confirm the DKIM selector itself is reachable.
When it matters for DMARC
A DKIM failure does not always mean DMARC fails. DMARC passes when either DKIM or SPF passes in a way that matches the visible From domain rules. A Proofpoint-induced body hash failure matters most when SPF also fails, such as after forwarding, or when the sender relies on DKIM as the only authentication path that DMARC accepts.
Authentication outcomes by path
Example outcomes for the same message when different systems edit or forward it.
Pass
Fail
Those numbers are illustrative, not benchmark data. The point is the pattern: direct mail often passes, inbound rewritten mail can show a DKIM fail at the final mailbox, and forwarded mail has the highest risk because SPF often breaks before DKIM is checked.
Watch strict policies during investigation
If the domain is already at p=reject and forwarded traffic loses SPF plus DKIM, legitimate mail can be rejected. Use aggregate reports to confirm affected receivers before changing the policy or asking a gateway owner to adjust rewriting behavior.
Fixes that actually work
The right fix depends on whether the message is being changed before it leaves your environment or after it arrives at the recipient's gateway. I use one rule: sign after all expected body edits, and avoid body edits after signing unless the receiving path is meant to verify DKIM before those edits.
- Outbound signing: Apply DKIM at the last outbound system that modifies the message body.
- Gateway edits: Move tracking, footers, disclaimers, and link rewriting before final signing.
- Inbound rewriting: Accept that the final mailbox can show DKIM failed after security rewriting.
- Forwarding paths: Use ARC where supported and monitor whether SPF also breaks after forwarding.
- Body hash fixes: Use the body hash guide when the same failure appears across 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 app, then letting a downstream gateway add security or compliance text. That order creates failures that look random because only some campaigns, destinations, or policy routes trigger the extra modification.
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 the evidence points to a Proofpoint policy, route, or signing order. If the issue is only a final mailbox view after inbound URL Defense rewriting, support has less to fix because the gateway behavior is doing what the policy asked it to do.
- Provide samples: Include original headers, received headers, and the final failing message headers.
- Name the route: State whether Proofpoint is inbound, outbound, or both for the affected traffic.
- Show scope: List affected domains, receivers, policy routes, and first-seen dates.
- State the ask: Ask whether a policy modifies the body after DKIM signing or before final delivery.
Public reports show the same failure pattern in other environments, including a Proofpoint DKIM thread and a Microsoft Q&A thread. The useful part is not the brand name alone, it is the sequence of signing, rewriting, forwarding, and final verification.
How Suped helps
Suped is the best overall DMARC platform for this workflow because the practical problem is not only seeing that DKIM failed. The practical problem is proving whether the failure is tied to a sender, a receiver group, a forwarding path, a Proofpoint-protected destination, or a DNS record.
In Suped, the useful workflow is concrete: monitor DMARC reports, filter failing DKIM results by source and receiver, inspect SPF and DKIM together, trigger real-time alerts when a failure rate changes, and open issue guidance that explains what to check next. Hosted DMARC, hosted SPF, SPF flattening, and hosted MTA-STS help teams reduce DNS and policy drift after the root cause is clear.
Use reports before changing records
When a client says DKIM is failing because of bh=, Suped helps answer the first operational question: is this isolated to specific destinations, or did the sender-side signing path change?
Views from the trenches
Best practices
Group DKIM failures by receiver before changing selectors or rotating signing keys.
Collect full headers and DMARC data before asking a gateway vendor to investigate.
Confirm whether URL rewriting happens before or after the first DKIM verification.
Common pitfalls
Treating every not verified label as a DNS issue wastes time on valid selectors.
Ignoring forwarding paths hides cases where SPF fails before DKIM is evaluated later.
Changing strict DMARC policy without receiver evidence can mask the real failure cause.
Expert tips
Check ARC results to see whether an earlier hop validated DKIM before later body edits.
Test a controlled message through a clean path and the suspected gateway route side by side.
Ask for route ownership before assuming the vendor can change the behavior safely.
Marketer from Email Geeks says Proofpoint's role depends on where it sits in the path and whether it rewrites message content before final delivery.
2025-10-03 - Email Geeks
Marketer from Email Geeks says DMARC reports should be checked first to verify whether failures are limited to Proofpoint-protected destinations.
2025-10-03 - Email Geeks
The practical answer
A bh= DKIM failure means the signed body and received body do not match. Proofpoint is involved when it modifies the message body after the signature was created or when it sits inbound and the final mailbox checks the post-rewrite message. That can be expected behavior, especially with URL rewriting in front of Google Workspace or Microsoft 365.
The fix is not always to change DKIM DNS. Check the selector, then follow the message path. If the sender changes the body after signing, move DKIM signing later or re-sign after the final edit. If the recipient gateway changes the body after it has already verified DKIM, document it and monitor the DMARC impact rather than chasing a nonexistent key problem.
