Why is DKIM failing when sending from Salesforce via Gmail?
Matthew Whittaker
Co-founder & CTO, Suped
Published 21 Jul 2025
Updated 17 Aug 2025
7 min read
It can be incredibly frustrating to see your emails bounce or land in spam, especially when you're confident your authentication records are in order. A common scenario I've encountered is when Salesforce is configured to send emails via Gmail (Google Workspace), and while SPF and DMARC pass, DKIM authentication fails with a 'neutral' result, specifically due to a 'body hash did not verify' error.
This specific error often points away from a DNS misconfiguration and towards something more subtle: the email's content being altered in transit. This happens between the moment Salesforce signs the email and when Gmail's outbound servers handle it. Let's delve into why this occurs and what steps you can take to resolve it.
DKIM, or DomainKeys Identified Mail, serves as a digital signature for your emails. Its primary role is to verify the integrity of the message and confirm that it hasn't been tampered with since it left the sender's mail server. It works by attaching a cryptographic signature to the email's headers, which is then verified by the recipient's mail server using a public key published in your domain's DNS records. Alongside SPF and DMARC, DKIM forms a critical part of modern email authentication standards, increasingly vital for deliverability, especially with new sender requirements from Google and Yahoo.
When you encounter a 'dkim=neutral (body hash did not verify)' error, it means the recipient's mail server, in this case Gmail, was able to find your DKIM public key but found that the cryptographic hash of the email's body did not match the hash in the DKIM signature. This almost always indicates that the email body was somehow modified after it was signed by the sending system but before it was verified by the receiving system.
A 'body hash did not verify' error points to content modification, not necessarily a DNS issue. This differentiates it from situations where Gmail might misreport DKIM or if there's no key for the signature at all.
How Salesforce and Gmail interact during email sending
When you configure Salesforce to send emails through Google's SMTP relay, Salesforce is typically responsible for signing the email with its own DKIM key before it ever leaves its platform. This is a common setup to ensure proper authentication for emails originating from your domain but sent via a third-party service.
The email then travels from Salesforce's infrastructure to Google's outbound mail servers. At this point, Google acts as a relay, forwarding the already-signed message to the final recipient. The critical point is that Google's servers should ideally pass the email through without any modifications that would invalidate the existing DKIM signature.
Example of a failing DKIM authentication result
Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@yourdomain.com header.s=sf1; spf=pass (google.com: domain of sender@yourdomain.com designates 209.85.220.97 as permitted sender) smtp.mailfrom=sender@yourdomain.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com
The snippet above illustrates what a typical header might look like when the body hash doesn't verify. Notice that the SPF passes, and DMARC also passes (likely because the policy is at p=NONE), but DKIM is marked as 'neutral' specifically due to the body hash issue. This confirms the problem isn't with your DNS records for DKIM, but rather how the message itself is handled during the relay.
Common causes of DKIM body hash mismatches
The primary suspect in a 'body hash did not verify' scenario is usually subtle content modification. This can happen if Salesforce sends the email content in a way that Google's SMTP relay service feels the need to normalize or re-encode it. This might include: non-standard character sets, excessive white space, or complex HTML structures that are interpreted differently. Even minor alterations like converting tabs to spaces, or handling specific Unicode characters, can cause the hash to mismatch.
Email templates used within Salesforce can also play a role. If your templates contain dynamic fields, merge tags, or intricate styling, the final rendered email body might undergo changes when processed by Google's outbound system, causing the post-relay body to differ from the pre-signed version. This is particularly relevant if Salesforce performs the DKIM signing before the final rendering or before passing it to Google.
Original message integrity
Signed Content: Salesforce applies the DKIM signature to the email's body and relevant headers.
Expected Hash: A specific hash value is generated based on the exact email content at the time of signing.
Potential content modifications
Character Conversion: Non-standard characters or encoding irregularities might be normalized by Google.
Formatting Changes: Subtle adjustments to white space, line breaks, or HTML structure can occur.
New Hash: The altered body generates a different hash value, leading to the DKIM failure.
While recipient-side spam filters (like Proofpoint, if an organization uses one) can also modify emails and break DKIM, the dkim=neutral (body hash did not verify) error specifically when relaying through Gmail usually points to an issue during the handoff process from Salesforce to Google's outbound mailers, or how Google itself handles content normalization for messages it's relaying.
Troubleshooting and solutions
The first step in diagnosing this issue is to simplify your email content. Send a very basic 'hello world' email, containing only plain ASCII text, from Salesforce via Gmail to a Gmail address. If this plain email passes DKIM, then you've confirmed the issue is indeed related to the specific content or encoding of your more complex emails. If it still fails, it suggests a deeper problem with how Salesforce is signing emails being relayed through Google.
Always examine the full email headers (in Gmail, click 'Show original' from the three-dot menu next to the reply button). Look for the Authentication-Results header and the DKIM-Signature header. Specifically, check the d= (domain) and s= (selector) tags in the DKIM-Signature header to confirm that Salesforce is indeed the one signing your emails. This will help you to verify your DKIM setup is generally correct.
Symptom
Likely Cause
Action
DKIM=neutral (body hash did not verify)
Email content altered in transit by Google's outbound relay.
Missing or incorrect CNAME records in DNS for Salesforce's DKIM keys.
Verify CNAME records in your DNS and Salesforce setup are active.
DKIM fails inconsistently
Intermittent content modifications or external filtering (less common for outbound relay).
Check for complex templating and any other intermediate email security gateways.
If a very plain email still results in a DKIM body hash mismatch, the problem likely lies deeper within how Salesforce prepares messages for relay or how Google processes them on the outbound side. In such cases, contacting Salesforce support is essential. They can investigate the specific encoding or handling of your emails during the relay process to address DKIM body hash mismatch failures. It's also worth checking your DMARC reports for further insights.
Views from the trenches
Best practices
Always test email authentication with a simple 'hello world' message first.
Regularly review your DMARC aggregate reports to detect authentication failures.
Ensure your email templates adhere to standard HTML and character encoding practices.
Confirm that Salesforce DKIM keys are correctly published and active in DNS.
Common pitfalls
Assuming a DKIM 'neutral' or 'fail' means a DNS record issue, when content modification is the culprit.
Overlooking subtle changes to email body (whitespace, character encoding) during relay.
Not thoroughly testing email deliverability from sandbox environments to external recipients.
Failing to engage platform support (Salesforce, Google) when self-troubleshooting hits a wall.
Expert tips
Use email header analysis tools to dissect the 'Authentication-Results' header for precise diagnostic information.
Consider temporary disabling of Salesforce's DKIM signing to see if Google Workspace can sign instead, if applicable.
Examine if any corporate spam filters or gateways are modifying email content on receipt.
Trace the exact path of the email, from generation to final delivery, noting any potential modification points.
Expert view
Expert from Email Geeks says that speculation on DKIM issues is difficult without access to detailed data like the specific domain and full email headers.
2023-08-04 - Email Geeks
Expert view
Expert from Email Geeks states that corporate email filters or security solutions that modify email headers or body can cause DKIM failures when messages are routed through them.
2023-08-04 - Email Geeks
Maintaining email deliverability for Salesforce and Gmail
Dealing with DKIM failures when sending from Salesforce via Gmail can feel like an email deliverability puzzle. However, by understanding the mechanics of how these platforms interact and diligently troubleshooting content-related issues, you can often identify and resolve the root cause of the 'body hash did not verify' error. Remember, the goal is to ensure the email's integrity remains intact from the moment it's signed until it reaches the recipient's inbox.
Maintaining strong email authentication is more critical than ever, given the evolving requirements from major mailbox providers. Regular monitoring of your email deliverability and authentication results will help you proactively address issues and ensure your messages consistently reach their intended audience, avoiding the spam folder or outright rejection.
Gmail's outbound servers handle it. Let's delve into why this occurs and what steps you can take to resolve it.
Salesforce to send emails through Google's SMTP relay, Salesforce is typically responsible for signing the email with its own DKIM key before it ever leaves its platform. This is a common setup to ensure proper authentication for emails originating from your domain but sent via a third-party service.
