SPF and DKIM by provider

SPF record for Salesforce

Last updated 2026-08-26

Salesforce sends workflow, case and list email from Sales Cloud and Service Cloud. Here is what to publish so it can do that as your domain, and what has to line up before DMARC will pass.

The SPF record

Add one mechanism to the SPF record on your sending domain:

In a complete record, alongside Google Workspace, that looks like:

This is the include for mail sent directly by Salesforce. If you route Salesforce email through your own mail server with an email relay instead, take it out: the connecting IP is then yours, and Salesforce's addresses are irrelevant to the check.

Then count your lookups. SPF allows ten DNS-querying mechanisms across the entire nested chain, and the eleventh turns the record into a permerror that authorises nothing. The record still reads correctly to a human while every check fails. Run the domain through the SPF checker after every change, because the number moves when your providers change their own records, not just when you change yours.

DKIM

Create the key in Setup, under Email, DKIM Keys. Salesforce asks for a selector name and the domain to match, then generates a pair of CNAME records for you to publish. Once they resolve, come back and activate the key. Signing does not start until you do.

The selector names are yours to choose, which is unusual and means there is no standard value to look up. Pick something you will recognise in a header in two years.

DMARC alignment with Salesforce

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the domain in your visible From address. A provider can pass both checks for its own domain and leave you failing. These are the Salesforce specifics:

• Marketing Cloud is a different product with a different setup. Its Sender Authentication Package publishes records on a dedicated sending domain, and reusing the Sales Cloud include for it authorises the wrong infrastructure.
• Salesforce sends "on behalf of" your address unless the org is configured otherwise, and the resulting Sender header confuses people who are reading bounces.
• Bounce management rewrites the envelope sender to a Salesforce address, so SPF passes for Salesforce and does not align with your From domain. DKIM is doing the work.

The general case is covered in alignment, explained, and the header you read to prove it is on the dmarc=fail page.

Verify it

Substitute your domain, and run these after the TTL on anything you replaced has expired:

Then send one message through Salesforce to a Gmail address you control, open Show original, and look for dkim=pass with your domain in header.i. That single check is worth more than any number of DNS lookups, because it tests the thing receivers actually do.

Our SPF checker gives you the lookup count, the DKIM checker confirms a selector resolves and the key is long enough, and the DMARC checker reads your policy back to you. All three are free and none of them ask for an account.

Values here were checked against Salesforce's own documentation, at Salesforce help. Providers change DNS requirements without much announcement, so if their screen disagrees with this page, believe their screen and tell us.

A record can read correctly and still fail alignment once real mail moves through it. Receivers write that verdict into the reports they send. We read them for you, and paid plans email you the same day one names a new sender that failed, instead of holding it for Monday. See whether this sender passes. Your first domain is free.