Salesforce SPF record setup, step by step

Salesforce sends transactional and marketing email on behalf of your organisation from its own sending infrastructure. For SPF to pass, your domain's SPF record needs to authorise Salesforce's sending domains.

The include mechanism

Add Salesforce's include to your domain's single SPF TXT record:

yourdomain.com.    TXT    "v=spf1 include:_spf.salesforce.com ~all"

If you already send from other services, merge the includes into one record rather than publishing a second SPF TXT record - a domain can only have one:

yourdomain.com.    TXT    "v=spf1 include:_spf.salesforce.com include:_spf.google.com ~all"

For Salesforce Marketing Cloud or Pardot sending on dedicated or shared IPs, check the exact include hostname shown in your Salesforce email setup - some products use a different subdomain than the core _spf.salesforce.com. Copy it directly from that screen rather than guessing, since it is account- and product-specific.

Verify it resolves

$ dig yourdomain.com TXT +short
"v=spf1 include:_spf.salesforce.com ~all"

Then confirm the include itself resolves to IPs, not an error:

$ dig _spf.salesforce.com TXT +short

Watch the 10-lookup limit

Every include: mechanism costs at least one DNS lookup when a receiving server evaluates your SPF record, and nested includes inside that chain count too. SPF evaluation is capped at 10 lookups total; exceeding it returns a permerror, which most receivers treat as an outright SPF failure regardless of whether your actual sending IPs would have passed.

Salesforce's own include chain uses up some of that budget on its own. If you are also including several other ESPs, a CRM, and a helpdesk tool, you can hit the ceiling without realising it. Count lookups with a manual walk of each include:, a, mx, ptr, and exists mechanism in your merged record, or use any SPF lookup counter and verify its count by hand - do not trust a single tool blindly since some miscount nested includes.

There is also a 2-void-lookup limit (DNS lookups that return no answer or an error) - stale includes pointing at decommissioned services burn through this quickly and are worth auditing out periodically.

DKIM and DMARC alongside SPF

SPF alone is not sufficient. Enable DKIM signing in Salesforce's email domain settings (under Email Administration), which gives you a CNAME to publish - again, account-specific, copy it from that screen. Then publish DMARC:

_dmarc.yourdomain.com.    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

DMARC passes if *either* SPF or DKIM aligns with the domain in the visible From: header (header.from) - not the envelope sender. That's why getting DKIM signed with your own domain matters even if SPF already passes: it's a second independent path to alignment, and the one that survives forwarding, since SPF breaks on forwarded mail while DKIM signatures usually don't.

What not to do

• Don't add Salesforce's include and leave an old, unrelated SPF record from a previous provider in place - merge into one record, never two.
• Don't assume SPF passing means DMARC passes. Check that the SPF-authenticated domain matches your visible From: domain (header.from), not just that SPF returned a pass.
• Don't leave DMARC at p=none indefinitely once reports confirm your Salesforce traffic aligns cleanly - that stage is for visibility, not a permanent setting.

Salesforce authentication quick reference

FAQ

Does this apply to Salesforce Marketing Cloud and Pardot the same way? The general pattern - SPF include, DKIM CNAME, your own DMARC record - holds across Salesforce's email-sending products, but the exact include hostnames and DKIM setup screens differ by product. Check the specific product's email domain settings rather than assuming one include covers all of them.

What if Salesforce is only one of several systems sending as my domain? List every sending system (Salesforce, your ESP, your helpdesk, any transactional API) and make sure each has either an SPF include or an IP range in your single merged SPF record, and ideally its own DKIM selector so you can tell their signed mail apart in logs.

Will DMARC break my existing Salesforce automations if I set p=reject too early? Yes, if any automation sends with a sender address that isn't properly aligned - this is exactly why reading aggregate reports at p=none first matters before enforcing anything.

MailPilot doesn't connect to Salesforce directly, but it does check SPF, DKIM, and DMARC alignment for the mailboxes you warm, and tracks reputation daily, so a lookup-limit or alignment problem surfaces as a measurable drop rather than a guess.