Why is DKIM failing when sending from Salesforce via Gmail?
Published 21 Jul 2025
Updated 20 Oct 2026
12 min read
Summarize with
Updated on 20 Oct 2026: We clarified Salesforce DKIM key checks and how to trace body hash failures through Gmail.
A DKIM body hash failure means the receiver did not calculate the same canonicalized body hash recorded in bh=. It does not prove by itself that Salesforce or Google changed the body. Start by identifying the Salesforce sending mode, the domain in d=, the selector in s=, and the systems listed in the Received headers.
The same message can show SPF pass and DMARC pass while one DKIM result shows dkim=neutral with body hash did not verify. SPF can pass when the sending IP is authorized for the Return-Path domain. DMARC passes when SPF or another DKIM signature also matches the visible From domain. The failed signature still needs investigation because it shows that its signed body did not survive verification.
Direct answer
Gmail is not the DKIM signer just because the header says Authentication-Results: mx.google.com. That line says Gmail evaluated the message. Use d= and s= in each DKIM-Signature to identify its signing domain and selector. A message can carry more than one signature, so diagnose the exact signature marked neutral or fail.
First identify the sending path
Salesforce uses Send through Gmail and Email Relay for different flows. Send through Gmail sends a message composed in Salesforce through the user's connected Gmail account using OAuth. Email Relay sends Salesforce-generated mail to a configured SMTP server, which can be Google Workspace. The phrase "Salesforce via Gmail" can describe either flow, but the expected DKIM signer and available logs are different.
|
|
|
|
|---|---|---|---|
Send through Gmail | Connected Gmail account | Google outbound signature | Google Workspace Email Log Search |
Email Relay to Google | Salesforce MTA to SMTP relay | Salesforce signature and any Google signature | Salesforce logs and Google Workspace Email Log Search |
Salesforce direct | Salesforce MTA to recipient | Salesforce signature | Salesforce email logs |
Route identification for Salesforce and Google Workspace mail.
Do not mix user mail with automated mail
Enabling Send through Gmail does not move every Salesforce email to Gmail. Messages from triggers, workflow rules, list email, and organization-wide addresses can still use Salesforce or Email Relay. Confirm the route for the exact message type that failed.
Salesforce requires a custom sending domain used by Salesforce direct or Email Relay mail to be verified with an active Salesforce DKIM key or a verified Authorized Email Domain. Individual sender verification is also required. Send through Gmail is excluded because the connected Google account sends the message. This Salesforce authorization check is separate from recipient-side DKIM body verification.
Why a relay can break DKIM
This failure pattern applies after the headers or logs prove that Salesforce signed the message before a Google Workspace relay handled it. A relay can preserve the signed body. When it changes body bytes beyond canonicalization's tolerances, the original body hash no longer matches.
Salesforce signs an email before Google Workspace relays it and Gmail checks DKIM.
DKIM signs selected headers and a canonicalized body hash. With relaxed body canonicalization, runs of spaces or tabs within a line become one space, trailing whitespace is ignored, and empty lines at the end are ignored. Re-encoding the MIME body or adding a footer after signing can invalidate DKIM even when the email looks the same. Check c= for the header/body modes; if it is absent, the default is simple/simple. The DKIM specification defines these rules. When Gmail reports body hash did not verify, investigate post-signing body changes or signing/verification errors before replacing DNS keys.
- Salesforce signed: The d= and s= values lead to a Salesforce-managed custom DKIM key.
- Google relayed: The Received chain and route logs, rather than SPF alone, show that Google Workspace handled the outbound copy.
- Hash mismatch: The receiver's calculated body hash differs from bh=.
- DMARC passed: SPF or another DKIM signature matched the visible From domain.
Read Gmail's DKIM results and selectors
Start with the raw source of a copy delivered to another mailbox, not only the copy saved in the sender's Sent folder. In Gmail, use Show original, then inspect the receiving system's Authentication-Results, every DKIM-Signature, and the Received chain. Earlier Authentication-Results headers describe earlier checks and are not substitutes for the final receiver's result. A DKIM checker confirms that a selector record can be retrieved, but it cannot prove that the body stayed unchanged in transit.
Illustrative headers with two DKIM results (values abbreviated)text
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=google header.b=xyz789; dkim=neutral (body hash did not verify) header.i=@example.com header.s=sf1 header.b=abc123; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com DKIM-Signature: v=1; d=example.com; s=google; c=relaxed/relaxed; bh=...; b=xyz789... DKIM-Signature: v=1; d=example.com; s=sf1; c=relaxed/relaxed; bh=...; b=abc123...
The common mistake is reading mx.google.com as the signer. It is the host that wrote the result after checking the message. The signing domain and selector are inside each DKIM signature. The related body hash verification explanation covers how canonicalization and content changes affect the hash.
- Evaluator: Treat mx.google.com as the receiver that recorded the result.
- Signer: Use d= to identify the domain that created that signature.
- Selector: Use s= to retrieve the public key for that signature.
- Result matching: Match header.s and the header.b prefix to the corresponding s= and b= values. A bh= value alone cannot identify the signer.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Why SPF and DMARC pass anyway
A mixed result is normal. SPF checks whether the connecting IP is authorized for the Return-Path domain. DMARC then checks whether a passing SPF or DKIM domain matches the visible From domain. If SPF passes and its domain matches, DMARC can pass even when one DKIM signature is neutral. A second DKIM signature can also supply the required domain match.
|
|
|
|---|---|---|
SPF pass | IP authorized for Return-Path | Check domain match |
DKIM neutral with body hash error | Calculated body hash differs from bh= | Identify its signer |
DMARC pass | At least one matching path passed | Find which path |
Policy none | No quarantine or reject request | Stage enforcement |
Compact reading of a mixed authentication result.
A DMARC pass does not repair the failed DKIM signature. SPF often breaks during forwarding, and a route is easier to operate when its intended DKIM signature passes. Suped's DMARC monitoring groups aggregate results by source so a persistent Salesforce or Google Workspace failure can be separated from a single header test.
Do not chase SPF first
If SPF and DMARC already pass, changing SPF will not fix body hash did not verify. Focus on the failing signature, the message source, and the hops after that signature was added.
Isolate the failing Salesforce or Gmail route
Before changing DNS, confirm the basic records with Suped's domain health checker. Then test each sending path with the same recipient and content. For Send through Gmail, use Google Workspace Email Log Search; these messages are not recorded in Salesforce email logs. For Salesforce direct and Email Relay, use Salesforce email logs as well as the receiving headers.
Salesforce Setup with DKIM Keys and Google Workspace email relay settings.
- Plain body: Use only hello world with no thread, signature, template, tab, or footer.
- Gmail baseline: Send the same short message directly from Gmail as the same user.
- Send through Gmail: Send that message from Salesforce's email composer using the connected Gmail account.
- Salesforce direct: Use a controlled Salesforce-direct test without changing the production default.
- Relay path: Send the same body through the configured Google Workspace SMTP relay.
- Compare: Save the externally received source and compare the Received chain, every d=, s=, and DKIM result.
Plain ASCII test messagetext
Subject: DKIM test hello world
If plain text passes
The route preserves a simple body. Add template elements back individually to find which content triggers rewriting after signing.
- Template: Remove rich text blocks one at a time.
- Encoding: Compare Content-Transfer-Encoding and MIME boundaries in raw copies before and after the suspected hop.
- Threading: Test a new message without quoted replies.
If plain text fails
Check for body changes after signing and signing or verification errors. Use the headers and logs to locate the first different raw copy.
- Route: Compare Salesforce direct with the Google Workspace relay path.
- Support: Send the responsible provider the raw source, route logs, and test matrix.
- Signing: Have the final body-changing system add a domain-matching DKIM signature.
Fix DKIM for the confirmed sending path
The fix depends on which signature failed. For Send through Gmail, verify that Google Workspace adds a passing signature for the visible From domain. Salesforce custom DKIM does not control that connected-account route. For Email Relay, preserve the Salesforce-signed body or add a domain-matching signature after the last modification. Also compare the Salesforce authentication guidance with the exact org, sending domain, and message path.
In Google Admin, open Apps > Google Workspace > Gmail > Authenticate email, select the sending domain, generate a key if needed, and publish its TXT record. After the record resolves, click Start authentication and verify a fresh external message. Follow Google's DKIM setup instructions. A Salesforce DKIM CNAME and Google's DKIM TXT record use separate selectors; keep both when both sending paths are in use.
|
|
|
|---|---|---|
Enable Google DKIM | Send through Gmail lacks a passing domain signature | Check an external recipient copy |
Preserve relay body | Salesforce signature fails after relay | Remove footer and MIME rewrites |
Sign after modification | Relay must change the body | Confirm final signature passes |
Clean the template | Plain ASCII passes | Add content back one change at a time |
Fix options for Salesforce and Google Workspace DKIM failures.
Do not assume DNS is wrong
A successful selector lookup proves that a public key record exists. A body hash failure points first to the signed body or canonicalization, while a missing key or incorrect selector produces a different error. Replace or republish a DKIM key only when the result identifies a key lookup or signature-key problem.
- Send through Gmail: Confirm Google Workspace signs the externally delivered message.
- Email Relay: Disable body modifications or sign again after them.
- Evidence: Attach raw sources, signer domains, selectors, route settings, and timestamps.
- Retest: Change one variable and compare the same authentication fields again.
Check Salesforce DKIM keys if the signature is missing
For Salesforce direct or Email Relay mail with no expected signature or a key lookup error, check Setup > DKIM Keys before troubleshooting body changes.
- Confirm the key is active. For a new key, choose 2048-bit RSA and distinct primary and alternate selectors.
- Publish both CNAME records exactly as Salesforce provides them. Check whether your DNS host appends the domain automatically, so the record name is not duplicated.
- Set Domain and Domain Match Pattern for the exact sending domain. Create a separate key for each subdomain you own; Salesforce no longer recommends wildcard patterns for those domains.
- Wait for the CNAME records to resolve, click Activate, then send a fresh test to an external recipient. Keep the alternate CNAME in place for automatic key rotation.
Salesforce's key setup instructions describe these steps. They address missing signatures and key lookup errors, not a mismatch in an existing signature's body hash.
Monitor Salesforce and Gmail authentication in Suped
Suped's product groups DMARC aggregate reports by sending source and shows the SPF and DKIM results reported for each source. For this Salesforce and Gmail problem, compare the reported sources, check selectors where receivers include them, and watch whether failures stop after a route change. For relayed mail, the source IP can be Google's even when Salesforce created the message; use raw headers and route logs to confirm the originating system.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
DMARC aggregate reports show pass or fail by source, but they do not contain the exact body mutation or the full body hash did not verify diagnostic. Keep the raw message beside the Suped source view. Suped's alerts can flag a new failure pattern, and hosted DMARC can support controlled policy changes after every legitimate route passes.
Post-change DKIM checks
Review reported failures alongside controlled tests for the confirmed Salesforce and Google Workspace path.
Clear
0%
No reported failures from the confirmed path in the reviewed reporting periods.
Investigate
>0%
Any repeat failure from the same production path needs a raw-header check.
Escalate
Persistent
The controlled retest still fails after one route variable changes.
- Source grouping: Compare source IPs and use route logs to distinguish Salesforce direct mail from Google-relayed mail.
- Selector tracking: Use selectors reported by receivers, plus raw headers, to identify the failing signature.
- Policy staging: Move beyond p=none only after every legitimate route has a matching pass.
Views from the trenches
Best practices
Compare Salesforce direct, Gmail relay, and basic Gmail headers before changing DNS.
Test a plain ASCII message first, then add template elements until DKIM fails again.
Track the signing domain and selector so support receives the exact failing path.
Common pitfalls
Treating mx.google.com as the signer confuses result stamping with DKIM signing.
Assuming a valid DNS key proves the message body survived every hop without changes.
Changing SPF when DMARC already passes wastes time on the wrong authentication result.
Expert tips
Confirm the sending mode before deciding whether Salesforce or Google should sign.
Disable one sending path at a time so each test isolates the failing route cleanly.
Keep one untouched raw message file so support can inspect canonicalized body data.
Expert view
An Email Geeks discussion says the first question is which system created the DKIM signature, since mx.google.com only recorded the authentication result.
2023-08-04 - Email Geeks
Expert view
An Email Geeks discussion says body hash errors point to a difference between the signed body and the received body, so SPF changes do not address the error.
2023-08-04 - Email Geeks
Frequently asked questions
A body hash failure means the receiver's calculated body hash differs from the value in that signature; it does not identify the responsible system. Use d= and s= to identify that signer, then use Received headers and route logs to identify the later hops.
That host wrote the Authentication-Results header after checking the message. It is not necessarily the signer. Each signer is identified by d= and s= in its DKIM-Signature.
DMARC passes when a passing SPF or DKIM result uses a domain that matches the visible From domain. SPF can supply that match in this case, or a second DKIM signature can pass even while the Salesforce signature fails.
Usually not. A body hash mismatch points to the body or canonicalization. Replace or republish the key only when the result reports a missing selector, unavailable key, or signature-key verification problem.
Send the raw externally received source for each control path, the sending mode, DKIM domains and selectors, message identifier, exact timestamp, and route-specific email logs. Use Google logs for Send through Gmail and include Salesforce logs for Salesforce direct or Email Relay.
