Why is DKIM failing on Gmail, and is Proofpoint causing it?
Published 16 Apr 2025
Updated 25 May 2026
12 min read
Summarize with
Yes, Proofpoint can cause DKIM to fail in Gmail. The usual pattern is simple: 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.
The most common Proofpoint-related causes are URL Defense rewrites, Targeted Attack Protection scanning, external sender banners, disclaimer insertion, subject tagging, and other inbound gateway changes. 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, assume message modification until headers prove otherwise.
- Fast test: Send the same 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.
The direct answer
When I see DKIM failing only inside a work Gmail or Google Workspace mailbox, I 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 is often the answer.
A normal 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. That sequence says Proofpoint saw a valid message first, then Gmail saw a different message later.
Header pattern that points to modificationtext
Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) 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, found enough data to evaluate it, and rejected the signed body comparison.
Use a DKIM checker to confirm that the selector and public key exist, but do not stop there. DNS validation proves the key is publishable. 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 is meant to tell 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, DKIM validation at the next hop breaks unless the gateway preserves the original signed structure or adds a new matching DKIM signature.
Proofpoint URL Defense settings screen showing inbound URL rewriting policy controls.
|
|
|
|---|---|---|
bh mismatch | Body changed after signing. | Compare mailbox paths. |
NXDOMAIN | Selector DNS is missing. | Publish the key. |
 ppe pass | Gateway accepted original DKIM. | Check post-scan edits. |
 gmail fail | Gmail saw changed content. | Test direct delivery. |
Common header clues and what they mean.
A selector check is still useful. In one real pattern, the first read of the header made the selector look missing because the signing domain was misread. Once the actual header.d domain was checked, the key existed. That is why I always read header.s and header.d together before touching DNS.
How Proofpoint breaks DKIM
Proofpoint is usually not breaking DKIM because it cannot validate the sender. It breaks DKIM because it changes the message after validation. That change can be intentional and useful for security, but DKIM has no way to treat that as harmless once the signed body is different.
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 can pass at this stage when DKIM or SPF matches the visible From domain.
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 text like an external sender warning, appends a confidentiality footer, rewrites tracking links, or changes the subject after signing, DKIM loses its integrity match.
This is why the phrase Gmail says DKIM failed is incomplete. Gmail is reporting 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 message 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 headers: Copy the full original source, not a screenshot of the Gmail summary row.
- Find the selector: Read header.s and header.d from Gmail's DKIM result.
- 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.
- Inspect edits: Look for rewritten URLs, added banners, subject tags, added footers, and MIME changes.
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=..."
If the selector exists and the same message passes when sent outside the corporate inbound gateway, DNS is not the root cause. The failure is in the delivery path. For a separate edge case where Gmail's summary view looks misleading, read the Gmail DKIM display explanation.
I 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.
Where SPF and DMARC fit
SPF checks the envelope sender domain against the IP address that delivered the message to the receiver. It does not hash the message body. URL rewrites and banners do not break SPF directly, but an inbound gateway changes the final sending IP that Gmail sees. If Gmail evaluates SPF against Proofpoint's forwarding IP instead of the original sender's authorized IP, SPF fails unless the mail system is configured to treat the gateway path correctly.
DMARC needs either SPF or DKIM to pass and match the visible From domain. That is why having both SPF and DKIM is important. If DKIM breaks because a gateway changes the body, SPF still gives DMARC another route to pass when SPF survives forwarding and still matches the From domain. If SPF fails because the forwarding gateway is now the connecting IP, DKIM becomes the backup. When both fail, DMARC fails.
|
|
|
|---|---|---|
SPF | Sending IP. | Forwarding IP mismatch. |
DKIM | Signed content. | Body or header edits. |
DMARC | Matching pass. | Both routes fail. |
How SPF, DKIM, and DMARC react to gateway modification.
This is also why DMARC reports matter more than a one-off Gmail screen. A single Gmail message tells you one delivery path. Aggregate DMARC data tells you which sources, domains, and receivers fail over time. If the issue appears only for mail routed through one corporate gateway, the pattern becomes obvious in DMARC monitoring data.
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 I would fix it
I would not ask the sender to rotate DKIM keys until the path test proves a sender-side problem. In most Proofpoint-to-Gmail cases, the fix belongs to the receiving environment, not the sender. The receiving team needs to decide whether Gmail should validate before or after modification, whether Proofpoint should add its own DKIM signature after modification, or whether Gmail should trust the inbound gateway path.
- Adjust rewriting: Reduce URL or body rewriting for mail that must preserve original DKIM validation.
- Re-sign mail: Have the gateway add a new DKIM signature after it modifies the message, using a domain the receiver expects.
- Configure gateway trust: Set the mailbox platform to treat the secure gateway IPs as the inbound path and avoid duplicate scanning outcomes.
- Preserve originals: Keep a test route that receives mail without security rewriting for clean comparisons.
- Check DMARC data: Confirm whether failures affect real recipient traffic or only internal review mailboxes.
If the 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.
There is one sender-side exception: if the message fails everywhere, including direct Gmail, then inspect the sender platform. Common sender-side causes include the wrong selector, an expired or removed public key, a platform signing with a subdomain that lacks DNS, a broken MIME generator, or a mailing system that changes the body after signing.
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 is useful here because this problem is hard to diagnose from one Gmail message. Suped brings DMARC, SPF, DKIM monitoring, blocklist (blacklist) monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and deliverability signals into one place. The practical benefit is that you can see whether DKIM failures are isolated to one receiver path or spread across all mail.
For most teams, Suped is the strongest practical choice because it turns authentication data into fix steps instead of leaving you to compare raw XML reports and headers by hand. The real-time alerts are especially useful when a gateway change, sender migration, or DNS edit starts changing failure rates.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The workflow I like is straightforward: verify the domain's DNS baseline, identify the affected source, compare receiver-level results, then inspect the headers for the failing path. For agencies and MSPs, the multi-tenancy dashboard helps keep this clean across client domains without losing source-level detail.
Suped does not remove the need to read headers when a single message is weird. It does make the larger decision clearer: whether you have a DNS problem, a sender configuration problem, or an inbound gateway problem that only appears after message modification.
Views from the trenches
Best practices
Read the receiving host name before trusting a pass or fail result in raw headers.
Test the same 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
Compare Proofpoint and Gmail Authentication-Results in chronological order first.
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 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 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
My practical take
If Gmail says DKIM is failing and Proofpoint sits in front of Google Workspace, I treat Proofpoint modification as the leading cause when the error is a body hash mismatch. That does not mean Proofpoint is malfunctioning. It means the gateway changed the message after the original sender signed it.
The right fix depends on ownership. If you control the receiving environment, tune the gateway path, preserve a clean test route, or re-sign after modification. If you control the sending environment, prove the message passes direct Gmail before you chase DNS. If you own the domain program, monitor DMARC over time so one noisy internal mailbox does not drive unnecessary sender changes.
