Why is DKIM failing on Gmail, and is Proofpoint causing it?
Published 16 Apr 2025
Updated 4 Oct 2026
15 min read
Summarize with
Updated on 4 Oct 2026: We clarified inbound and outbound Proofpoint causes of Gmail DKIM failures and tightened the verification steps.
Yes, Proofpoint can cause DKIM to fail in Gmail. One failure pattern is: the message is DKIM-signed by the original sender, Proofpoint validates it and then modifies the message, and Gmail validates the modified message later. Gmail then reports body hash did not verify because the body Gmail received no longer matches the body that was signed.
A documented Proofpoint-specific cause is URL Defense rewriting. Other gateway changes, including external sender banners, disclaimer insertion, body re-encoding, and MIME boundary changes, can also cause a body hash mismatch. Subject tagging affects signature verification when the Subject header is signed. A corporate mail gateway can break DKIM even when the sender published the right DKIM key and the message passed DKIM before the gateway touched it.
- Direct answer: If Gmail shows dkim=neutral or dkim=fail with body hash, test for message modification before changing DNS.
- Fast test: Send an equivalent message to a personal Gmail mailbox that does not sit behind Proofpoint. If DKIM passes there, the inbound gateway path is the likely cause.
- Key caveat: Proofpoint is not the only cause. Any system that changes signed headers or the signed body can produce the same Gmail result.
Do not start by changing DKIM DNS records. When Gmail says body hash did not verify, the public key can be perfectly valid. The failure often means the message changed after signing.
Read Gmail and Proofpoint authentication results
When DKIM fails only inside a work Gmail or Google Workspace mailbox, separate two questions. First, did the sender sign the message correctly? Second, did something change the message before Gmail checked it? In Proofpoint environments, the second question often identifies the cause.
A useful header clue looks like this: Proofpoint records DKIM pass in its own Authentication-Results header, then Gmail records DKIM neutral or fail with a body hash error. Map each result to its Received hop and authentication service identifier. Do not assume the order in which header fields appear is the processing order. Compare results for the same signing domain and selector. If multiple signatures share both, compare their signature values too.
Header pattern that points to modificationtext
Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.d=example.com header.i=@example.com header.s=s1; Authentication-Results: ppe-hosted.com; dkim=pass header.d=example.com header.s=s1; spf=pass smtp.mailfrom=example.com; dmarc=pass header.from=example.com;
That is different from a missing selector or broken DNS record. A missing selector usually shows as a DNS lookup problem, not a body hash mismatch. The body hash error means Gmail found a DKIM signature but rejected the signed body comparison. This error alone does not confirm public-key validity or identify the hop responsible for the mismatch.
Use a DKIM checker to confirm that the selector and public key exist, but do not stop there. DNS validation proves the key is published. It does not prove that the message Gmail received still matches the signed content.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
What Gmail is actually checking
DKIM signs selected headers and a canonicalized version of the message body. Gmail reads the DKIM-Signature header, looks at the selector in s=, the signing domain in d=, and the body hash in bh=. It then rebuilds the body hash from the received message. If that calculated value does not match bh=, DKIM fails.
This matters because DKIM is intentionally sensitive to content changes. It tells a receiver whether the signed content survived transit. If a security gateway rewrites links, injects a warning banner, adds a footer, or changes MIME boundaries, the original signature fails when those edits change the canonicalized signed content. A new signature applied afterward is checked independently.
The c= tag shows header and body canonicalization. Relaxed body canonicalization ignores trailing whitespace, compresses spaces and tabs within a line, and ignores empty lines at the end of the body, but it does not tolerate rewritten URLs, inserted text, re-encoding, or changed MIME boundaries. The h= tag lists signed headers. Changing a signed header value beyond the permitted canonicalization changes breaks that signature. Multiple DKIM signatures are checked independently. One failed signature does not cancel a separate passing signature. For DMARC to pass through DKIM, at least one passing signing domain must meet the visible From domain's matching requirement. See the DKIM specification for canonicalization rules.
Google documents a limit of five DKIM signatures checked per message, so confirm that Gmail checks the signature needed for DMARC. Avoid using the DKIM body length tag l= to work around appended footers; it leaves the remainder unsigned and vulnerable to abuse. See Google's DKIM troubleshooting guidance for both limitations.
Proofpoint URL Defense settings screen showing inbound URL rewriting policy controls.
|
|
|
|---|---|---|
bh mismatch | Received body does not match the signed body hash. | Compare raw message source across delivery paths. |
NXDOMAIN | The queried DKIM key name does not resolve. | Verify d= and s=, then publish the correct key if missing. |
A trusted gateway reported a pass for that signature. | Check post-scan edits. | |
Signature did not validate; the error identifies the failure type. | Read the error, then compare delivery paths. |
Common header clues and what they mean.
A selector check is still useful. In one common pattern, the first read of the header makes the selector look missing because the signing domain was misread. Once the actual header.d domain is checked, the key exists. Read header.s and header.d together before touching DNS.
How Proofpoint breaks DKIM
A body hash mismatch after an earlier Proofpoint pass points to content changes after validation rather than a missing DNS key. The change can support a security control, but the original DKIM signature cannot treat a different signed body as harmless.
Proofpoint Essentials documents a specific URL Defense control for this case. Under Security Settings, Malicious Content, and URL Defense, clear Re-write URLs that are located in DKIM signed messages to prevent URL Defense from rewriting signed messages. Other body or signed-header changes still need to be checked. Product editions and policy labels differ, so confirm the equivalent control in the deployed edition. Disabling rewriting reduces click-time inspection for those links, so review narrow sender or URL exceptions before applying a broad change.
Message before Proofpoint
- Signature: The sender signs headers and body with its private DKIM key.
- Validation: Proofpoint checks the public key and records a DKIM pass.
- DMARC: DMARC passes when SPF or DKIM passes and its domain meets the visible From domain's matching requirement.
Message after Proofpoint
- Rewrite: Proofpoint changes links, HTML, warning text, or MIME structure.
- Gmail check: Gmail calculates a new body hash and gets a different value.
- Result: Gmail reports DKIM neutral or fail even though the sender key exists.
The same pattern applies to other secure email gateways and corporate mail controls. If a gateway adds an external sender warning, appends a confidentiality footer, rewrites tracking links, or changes the subject after signing, DKIM fails when those edits change the canonicalized signed content.
This is why the phrase Gmail says DKIM failed is incomplete. Gmail reports the state of the message at Gmail's validation point. A previous hop can have a different, valid result because it checked an earlier version of the message.
Flowchart showing Proofpoint checking DKIM, rewriting the message, and Gmail failing DKIM afterward.
How to prove the cause
The fastest proof is a controlled delivery comparison. Send the same representative message, including its links and attachments, to a mailbox that routes through Proofpoint and to a regular Gmail mailbox that does not. Then open Show original in Gmail and compare the DKIM result, the body hash error, and all Authentication-Results headers.
- Collect the source: Use Download original in Gmail to save the full message as an .eml file. Keep the headers and raw body; copying into an editor can change line endings or encoding.
- Map the hops: Pair each Authentication-Results entry with its authentication service identifier and nearby Received hop.
- Find the selector: Read header.s and header.d from Gmail's DKIM result. If either is absent, read s= and d= directly from DKIM-Signature.
- Check the key: Query selector._domainkey.domain and confirm the TXT record exists.
- Compare paths: Check whether DKIM passes in direct Gmail but fails in the Proofpoint-routed mailbox. Keep the sending route and selector consistent, and repeat the test to catch intermittent failures.
- Inspect edits: Look for rewritten URLs, added banners, subject tags, added footers, re-encoding, and MIME changes. Compare raw MIME content, not only the rendered email, because encoding changes can be invisible in Gmail.
DNS lookup pattern for a DKIM selectorbash
dig TXT s1._domainkey.example.com # Expected shape: # s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
A passing direct-delivery test and a failing gateway test point to processing after signing. Verify that both tests use the same sender route, signing domain, and selector before ruling out an intermittent signing or DNS issue. For a separate edge case where Gmail's summary view looks misleading, read the Gmail DKIM display explanation.
Do not trust a single pass or fail line without the receiving host name. ppe-hosted.com and mx.google.com can both be correct because they checked different versions of the message. Verify that gateway results were generated inside the trusted mail path; a matching host name alone does not establish authenticity. The Authentication-Results specification explains this trust requirement.
If Gmail rejects the message, read the complete SMTP bounce. 550 5.7.1 with "likely unsolicited" indicates spam filtering, while 550 5.7.26 identifies an authentication-related rejection. The accompanying text identifies the specific SPF, DKIM, or DMARC problem. A DKIM failure alone does not determine rejection or inbox placement. Check Google's SMTP error descriptions against the full bounce.
Check whether Proofpoint is on the outbound path
If mail sent through Proofpoint fails DKIM even at a personal Gmail address, check the sender's outbound gateway. Google Workspace can sign the message before it reaches Proofpoint. A disclaimer or URL rewrite applied afterward can invalidate that signature at every recipient. Google's outbound gateway guidance warns about this signing order.
Run the authorized DKIM signer after the final content-changing stage, or prevent later edits. If Proofpoint signs for a domain you control, publish the selector it uses and verify that d= meets the visible From domain's DMARC matching requirement. An inbound gateway normally cannot sign on behalf of unrelated external senders.
For this outbound path, authorize the final sending servers in the envelope sender domain's SPF record. Changing your organization's inbound gateway settings does not fix authentication at unrelated Gmail recipients.
Where SPF and DMARC fit
SPF checks the envelope sender domain against the source IP chosen by the receiver. It does not hash the message body, so URL rewrites and banners do not break SPF directly. In Google Workspace, a correctly configured inbound gateway list can make Gmail look past the Proofpoint connection and select an upstream public IP for SPF. The Automatically detect external IP option controls how far Gmail searches the Received chain for the first public IP not in the gateway list when the connecting IP is a configured gateway. If the gateway IPs or headers are wrong, Gmail can evaluate SPF against the wrong hop.
DMARC needs either SPF or DKIM to pass and match the visible From domain. That is why using both SPF and DKIM matters. If DKIM breaks because a gateway changes the body, SPF gives DMARC another route to pass when Gmail identifies the original source IP and the envelope sender domain matches the From domain. When neither mechanism produces a matching pass, DMARC fails. The DMARC specification distinguishes relaxed matching, which requires the same organizational domain, from strict matching, which requires identical domains. The adkim= and aspf= settings select the DKIM and SPF matching modes.
|
|
|
|---|---|---|
SPF | Envelope sender domain and source IP. | Wrong hop selected. |
DKIM | Signed content. | Body or header edits. |
DMARC | Authentication pass and From domain matching. | Both routes fail. |
How SPF, DKIM, and DMARC react to gateway modification.
Google Workspace inbound gateway settings can improve SPF source-IP selection and gateway handling, but they do not make a modified body match the original DKIM signature. Google's inbound gateway guidance states that Gmail does not enforce the sender's DMARC policy for messages arriving through a configured inbound gateway, although it still uses authentication data for compliance checks and protection against spam or impersonation. Keep the SPF fix and the DKIM fix separate during testing.
DMARC reports complement message-level diagnosis. Aggregate reports show sending IPs and authentication outcomes reported by participating receivers, but they do not reliably identify the gateway or modification behind a failure. Use DMARC monitoring to measure scope, and correlate the results with full headers and gateway logs.
For a wider check across DNS, DMARC, SPF, and DKIM, a domain health check is the right starting point. It catches obvious DNS problems before you spend time on gateway behavior.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
How ARC changes the diagnosis
Authenticated Received Chain (ARC) lets an intermediary record the authentication results it saw before it changed or forwarded a message. A verified ARC chain protects the intermediary's recorded authentication results, which Gmail evaluates using its own trust policy. This is useful when a gateway rewrites URLs or changes MIME content before Gmail performs its own checks. The ARC specification defines the chain and its verification.
- Look for ARC-Authentication-Results to see what each participating intermediary recorded on arrival.
- Check ARC-Message-Signature and ARC-Seal for each numbered instance in the chain.
- Read cv=pass as the sealer's report about the preceding chain. Check Gmail's arc=pass result separately; neither value repairs the original DKIM signature.
- Treat ARC as evidence for receiver policy. The final receiver decides whether to trust the sealer and how to use that evidence.
ARC does not repair the original DKIM signature and does not turn Gmail's body hash failure into dkim=pass. It preserves earlier authentication evidence that Gmail can consider when applying local policy.
Fix the gateway path or sender signing
Do not ask the sender to rotate DKIM keys until the path test proves a sender-side problem. For failures caused by an inbound gateway, the receiving team should prevent or narrow signed-content changes, configure the Google Workspace inbound gateway correctly for SPF source detection, preserve earlier authentication with ARC where supported, or add a new DKIM signature after modification when the gateway is authorized to sign for the required domain.
- Adjust URL rewriting: Disable rewriting in DKIM-signed messages or create narrow exceptions when preserving the original signature outweighs click-time rewriting.
- Re-sign only when authorized: Add a new DKIM signature after modification using a signing domain that matches the visible From domain for DMARC. A passing signature from an unrelated gateway domain does not satisfy DMARC through DKIM.
- Configure the inbound gateway: List every Proofpoint gateway IP that can deliver to the Google Workspace tenant and test external-IP detection so Gmail selects the intended source IP for SPF. This does not restore original DKIM.
- Preserve authentication evidence: Use ARC where both the intermediary and receiver support it, and keep full headers for verification.
- Keep a clean test route: Maintain a controlled mailbox path without content rewriting for comparisons.
- Check DMARC data: Compare available receiver-level reports with the controlled tests to assess how widely failures occur; reports alone cannot establish the exact gateway route.
If an equivalent message passes DKIM in a normal Gmail account and fails only after a corporate inbound gateway, the sender's DKIM setup is usually fine. Fix the gateway path before changing public DKIM records.
If the message fails on every recipient path, inspect the sender's complete outbound route, including Proofpoint where used. Verify the active selector and signing key, then check whether any stage changes the body after signing. For Google Workspace senders, publishing a TXT record alone does not enable signing; click Start authentication under Authenticate email. See Google's DKIM troubleshooting guidance for the setup steps.
If the error names bh= or says the body hash is not verified, the dedicated DKIM bh value failures page goes deeper on that exact signature field.
Where Suped helps
Suped's product helps when a single Gmail header cannot show the scope of a failure. Suped's DMARC monitoring groups SPF and DKIM outcomes by sending source and receiver, which helps identify failures concentrated in particular sources or reporting receivers. Use full headers to confirm whether Proofpoint is on the affected path.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A practical workflow is to verify the domain's DNS baseline, identify the affected source, compare receiver-level results, and inspect full headers for the failing path. Alerts can show when a gateway or DNS change affects authentication rates.
Aggregate DMARC data does not identify the exact content or MIME edit that broke one message, and report coverage depends on the receiving systems. Keep the original message source and controlled test deliveries as message-level evidence, then use Suped to assess how broadly the reported pattern occurs.
Views from the trenches
Best practices
Read the receiving host name before trusting a pass or fail result in raw headers.
Test an equivalent message through a clean mailbox before changing any DKIM DNS records.
Keep a direct delivery route available for comparing signed bodies without gateway edits.
Track receiver-level DMARC data to separate sender-side errors from gateway edits.
Common pitfalls
Treating every Gmail DKIM fail as a missing public key wastes time during triage.
Changing selectors before checking for URL rewrites creates avoidable new failures.
Ignoring Proofpoint pass headers hides the earlier successful validation step clearly.
Relying on screenshots instead of full headers removes evidence needed for proof.
Expert tips
Map Proofpoint and Gmail authentication results to Received hops using authserv-id.
Look for external banners, URL rewriting, subject tags, footer edits, and MIME changes.
Ask whether the gateway re-signs mail after modification before blaming DNS records.
Use DMARC aggregate reports to confirm whether real recipient traffic is affected.
Marketer view
Marketer from Email Geeks says the selector and signing domain should be read together because a misread domain can make a valid key look missing.
2024-01-26 - Email Geeks
Marketer view
Marketer from Email Geeks says work mailboxes often modify incoming messages, and those edits break DKIM when they touch signed content.
2024-01-26 - Email Geeks
Frequently asked questions
No. URL rewriting or other edits break the original signature when they change canonicalized signed content before Gmail checks it. Formatting changes tolerated by canonicalization leave the signature valid. A new valid gateway signature is checked independently after modification.
It means Gmail calculated the body hash from the received message and the value did not match the bh= value in the DKIM signature. The usual cause is body modification after signing.
Not first. Check the selector, signing domain, direct Gmail delivery, and gateway path. Republish the correct public key when DNS is missing or wrong. Rotate keys when the signing key needs replacement or the private key has been compromised; rotation does not fix message modification.
Yes, when SPF passes and its envelope sender domain meets DMARC's relaxed or strict matching requirement for the visible From domain. Configure Google Workspace's inbound gateway IPs carefully so Gmail selects the intended source IP for SPF.
They can be checking different versions or different signatures. If the same signature passes at Proofpoint and Gmail reports a body hash mismatch, inspect changes made after Proofpoint validated it.
No. ARC preserves a verifiable record of authentication at earlier hops, but it does not repair the original DKIM signature. Gmail can consider a valid ARC chain when applying local policy.
