Salesforce SPF: include:_spf.salesforce.com, and why DMARC still needs DKIM

When a client's sales team sends email from Salesforce, the request that reaches the MSP is usually "add Salesforce to SPF." Salesforce does document an SPF entry, and you should use exactly that one. Its own help articles also explain why, with default settings, SPF won't get Salesforce mail through DMARC. This guide covers both, for mail sent from the core Salesforce application. Pardot (Account Engagement) and Marketing Cloud have separate instructions.

The entry Salesforce documents

Salesforce's help article on SPF says:

> The appropriate entry to include in your SPF record when sending mail from the Salesforce application is _spf.salesforce.com.

It adds a warning: use only _spf.salesforce.com, because the salesforce.com domain has "a variety of SPF records... for other uses" that aren't relevant to mail sent from the application. Don't use include:salesforce.com.

Salesforce's sample record is:

```

v=spf1 mx include:_spf.salesforce.com ~all

```

That's just an example. Your client's real record should keep its existing senders and ending. Salesforce explains that _spf.salesforce.com uses an exists:%{i} macro that authorizes all of its MTA IPs dynamically, so you don't list Salesforce IPs yourself. It also says that if the domain uses other authorized mail servers, such as Google Workspace or Microsoft 365, you add their includes before the Salesforce entry.

A merged record for a Microsoft 365 client would look like this:

```

v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all

```

Keep one SPF record per domain. A second v=spf1 record gives a permerror under RFC 7208 §4.5.

Lookup cost

On Oct 13, 2026, a live DNS check showed that _spf.salesforce.com publishes v=spf1 exists:%{i}._spf.mta.salesforce.com -all. The include itself costs one lookup and the exists costs another, so Salesforce uses two of the ten lookups RFC 7208 §4.6.4 allows. Salesforce documents the macro but not the count, so this is an observation, not a guarantee.

Testing the record the way Salesforce suggests

Salesforce's SPF article suggests validating the record with the SPF Query Tool on Kitterman.com. Open its "Test SPF Record" section, enter the client's real SPF record (not Salesforce's example), use an address on the client's domain, and pick a Salesforce sending IP. Salesforce's example uses 13.108.238.141. The result should be a pass. Keep in mind this only proves the record authorizes Salesforce's IPs. It doesn't prove DMARC alignment, because with bounce management on, real Salesforce mail is checked against a bnc.salesforce.com envelope, not the client's domain. The DKIM test send below is the check that matters for DMARC.

Why SPF alone won't pass DMARC for Salesforce mail

Salesforce's article on alignment failures explains the catch. If Bounce Management or Email Security Compliance is turned on in the org, Salesforce changes the envelope sender to a Variable Envelope Return Path (VERP) address. Its example is sampleemail=salesforce.com__abc123@abc123.bnc.salesforce.com.

SPF is evaluated against that envelope sender, a bnc.salesforce.com address, not the client's domain. Under DMARC (RFC 9989), an SPF pass only counts when the SPF-authenticated domain aligns with the From: domain. A salesforce.com envelope never aligns with client.com. Salesforce puts it plainly: "This does not meet the DMARC alignment requirement."

So with those settings on, include:_spf.salesforce.com in the client's record doesn't make Salesforce mail pass DMARC. Salesforce notes that the mismatch can get mail rejected or sent to spam, depending on the receiver's policy.

Salesforce's preferred fix: a DKIM key

Salesforce's resolution is to set up a DKIM key, and says customers who want to keep bounce processing should use DKIM. As the article says, "As long as DKIM signing passes in alignment, DMARC does not require SPF to also be aligned."

For DKIM to align, the key's Domain field has to match the domain in the From: header, and Salesforce says the Domain field must match the Domain Match Pattern field. If the key is for client.com but users send as client.co.uk, DKIM won't align for those messages.

The alternate fix, if a DKIM key isn't possible, is to set up SPF and turn off both Bounce Management and Email Security Compliance. In Lightning: Setup → Deliverability, then clear Activate bounce management and Enable compliance with standard email security mechanisms. That puts the client's domain in the envelope sender so SPF can align, but the org loses bounce handling. RFC 9989 also says domains publishing p=reject must not rely solely on SPF, because forwarding breaks SPF. DKIM is the durable answer.

A client checklist

• Confirm which Salesforce product sends: the core application, Pardot or Marketing Cloud. This page only covers the core application.
• Add include:_spf.salesforce.com to the one existing SPF record, after the other senders. Then recount the lookups.
• Create and activate a DKIM key in Salesforce for each From: domain users send from, and publish the DNS records Salesforce generates.
• Check that the key's Domain field matches the Domain Match Pattern.
• Send a test message to a mailbox you control, and confirm dkim=pass for the client's domain and dmarc=pass in the Authentication-Results header. Salesforce suggests a header analyzer, such as Microsoft's Message Header Analyzer.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10, names common senders such as Salesforce, and flags duplicate records and +all or ?all endings.

Founding Partner: $1,999, one time. Show every client which of their SaaS senders actually pass DMARC, on reports carrying your logo. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →