SPF, DKIM & DMARC for Salesforce.
Salesforce (Sales, Service, and Platform Cloud) authenticates your domain in three moving parts, and as of Spring '26 it refuses to send mail from a domain you haven't verified. SPF is a genuine shared include (include:_spf.salesforce.com) you merge into your one root SPF record. DKIM is a pair of CNAME "selector" records you generate under Setup - DKIM Keys and then Activate - and creating an active DKIM key is also the recommended way to satisfy Salesforce's new email-sending domain verification. DMARC is a fourth, separate record Salesforce never creates for you. The catch that trips almost everyone up: Salesforce sends bounces from its own return-path domain, so SPF does not align to your From address - DKIM is the mechanism that actually carries DMARC.
Why authenticate Salesforce?
Authenticating Salesforce mail is no longer optional housekeeping - since Spring '26 (enforcement began March 9, 2026 and rolled out through late April 2026) Salesforce blocks any user-authored or automated email sent from an unverified domain. Manual sends fail in the Email Composer with "Not allowed to send from an unauthorized domain," and automated flows fail silently, showing "550 5.7.1 Delivery not authorized, message discarded" only in your Email Logs. On top of that, since February 2024 Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume mail to Outlook.com in 2025. Salesforce's default behavior quietly breaks DMARC: it stamps a return-path on its own bounce domain, so SPF authenticates but does not align to your From address, and out of the box there is no DKIM signature on your domain at all - meaning a Salesforce email that looks fine can still fail DMARC everywhere. Setting up a DKIM key fixes both problems at once: it satisfies the domain-verification requirement and gives you an aligned signature that makes DMARC pass, so the reputation you build accrues to your own domain instead of bouncing off Salesforce's shared infrastructure.
The SPF reality for Salesforce
Salesforce core is a true "include" provider: there is one real shared mechanism, include:_spf.salesforce.com, that you add to the single SPF TXT record on your root domain, e.g. v=spf1 include:_spf.salesforce.com ~all. But be clear about what it does. The include resolves to v=spf1 exists:%{i}._spf.mta.salesforce.com -all - an exists-macro record that authorizes Salesforce's current sending IPs - and it costs TWO of your 10 SPF DNS lookups (one for the include itself, one for the nested exists mechanism). The important nuance: adding this include authorizes Salesforce for SPF but does NOT make SPF align. By default Salesforce uses its own domain as the envelope-from / Return-Path (its bounce-handling domain), so the SPF check runs against Salesforce's domain, not yours - which means SPF passes but does not align to your visible From address, and DMARC gets nothing from it. That is why DKIM is not optional here: DMARC needs at least one aligned mechanism, and on Salesforce that mechanism is DKIM. Publish the include anyway (it's Salesforce's documented recommendation and it authorizes the sending IPs cleanly), but treat DKIM - not SPF - as the thing that carries your DMARC pass.
Two ways to set it up
DKIM key (recommended)
- CNAME-delegated to custdkim.salesforce.com so Salesforce holds and rotates the private keys
- Gives you an aligned DKIM signature - the mechanism that actually makes DMARC pass
- An active DKIM key also satisfies the Spring '26 email-sending domain verification requirement
- One key can cover multiple From-address domains via its Domain Match Pattern
Authorized Email Domains - TXT (verification only)
- A single TXT record at _sfdv.yourdomain.com (or the apex) proves you own the domain
- Satisfies the Spring '26 verification requirement so sends aren't blocked
- Does NOT sign your mail - no DKIM signature, no DMARC alignment from it
- Use it only as a stopgap; you still need a DKIM key for deliverability
Step by step
- 1
Set your Deliverability access level
From Setup, use Quick Find to open Email - Deliverability. Set "Access to Send Email" (Access level) to "All email" so Salesforce actually sends outbound mail - sandboxes and some orgs default to "System email only" or "No access," which silently drops your test messages before authentication even matters.
- 2
Create a DKIM key
From Setup, search Quick Find for "DKIM Keys" and click Create New Key. Choose 2048-bit for the RSA key size. Enter a unique Selector (e.g. example-sf-a) and a unique Alternate Selector (e.g. example-sf-b). Enter the Domain you send from and a Domain Match Pattern (e.g. example.com to cover that domain, or a broader pattern for subdomains), then Save. Note: the Domain field is permanent once saved.
- 3
Publish the two DKIM CNAME records
Open the DKIM Key Details page - Salesforce shows a CNAME and an Alternate CNAME. At your DNS host, create both as CNAME records: host example-sf-a._domainkey.yourdomain.com pointing to the target Salesforce shows, like example-sf-a.k4tyd2.custdkim.salesforce.com (and the -b selector to its own custdkim.salesforce.com target). Copy the exact targets - a single wrong character breaks signing. If your DNS is behind Cloudflare, set them to DNS-only (grey cloud).
- 4
Activate the DKIM key
After the CNAMEs propagate (minutes, up to 48-72 hours), return to Setup - DKIM Keys, open the key, and click Activate. Salesforce won't let you activate until both CNAMEs resolve in public DNS. Once active, Salesforce signs outbound mail with d=yourdomain.com and your domain counts as verified for the Spring '26 requirement.
- 5
Add or merge the SPF include
At your DNS host, publish ONE SPF TXT record on the root (host @): v=spf1 include:_spf.salesforce.com ~all. If you already send via Google Workspace, Microsoft 365, a marketing tool, etc., merge include:_spf.salesforce.com into that single existing v=spf1 line - never create a second SPF record. This authorizes Salesforce's IPs (it costs 2 lookups) but remember it won't align on its own.
- 6
Verify the domain if you're not using DKIM yet
If you need to unblock sending before DKIM is live, use the TXT alternative: Setup - Quick Find "Authorized Email Domains" - Add, enter your domain, and Salesforce generates a verification key. Publish it as a TXT record (host _sfdv.yourdomain.com or the apex), wait for propagation, then Edit the domain and turn on "Verify domain ownership." This proves ownership but does not sign mail - a DKIM key is still the goal.
- 7
Point your Org-Wide Address at the verified domain
Every From address must be on a verified domain. From Setup, open Quick Find - "Organization-Wide Addresses," and make sure the addresses your users, flows, and email alerts send from (e.g. no-reply@yourdomain.com) are on the domain you just authenticated. Unverified Org-Wide Addresses are the most common cause of blocked automated sends.
- 8
Publish your DMARC record
Salesforce never creates DMARC. Add a TXT record at _dmarc.yourdomain.com: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only - it changes nothing about delivery while you confirm Salesforce mail passes DKIM aligned to your domain. Keep exactly one _dmarc record for the whole domain.
- 9
Send a test and read the headers
Send a real message from a Salesforce Org-Wide Address to a Gmail mailbox, open it, and choose the three-dot menu - Show original. You want DKIM: PASS with signed-by / d=yourdomain.com (not salesforce.com) and DMARC: PASS. SPF will typically show Salesforce's return-path domain - that's expected; DKIM is what should be carrying the DMARC pass.
Records to add
Salesforce generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.salesforce.com ~allRoot SPF - keep exactly ONE SPF record; merge this include into your existing v=spf1 line if you have one. Costs ~2 DNS lookups (include + nested exists). Authorizes Salesforce but does not align. |
| CNAME | example-sf-a._domainkey | example-sf-a.k4tyd2.custdkim.salesforce.comDKIM selector 1 - illustrative. Copy the exact target from your DKIM Key Details page; the k4tyd2 partition string is unique to your key. |
| CNAME | example-sf-b._domainkey | example-sf-b.e6mxu6.custdkim.salesforce.comDKIM alternate selector - illustrative. The second selector lets Salesforce rotate keys without you touching DNS again. Use the exact value Salesforce shows. |
| TXT | _sfdv | 00D000000000P18=1AB00000000000BAuthorized Email Domains verification key - illustrative and per-org. Only needed if you use the TXT ownership method instead of (or before) an active DKIM key; the apex also works as the host. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself - Salesforce never creates it. One per domain; start at p=none and tighten later. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Salesforce's setup costs against that budget.
Salesforce adds 2 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM is the centerpiece of Salesforce authentication, because it's the only mechanism that aligns to your domain - and, since Spring '26, an active DKIM key is Salesforce's recommended way to verify domain ownership so your sends aren't blocked. Create it under Setup - Quick Find - "DKIM Keys" - Create New Key: choose 2048-bit, enter a unique Selector and a unique Alternate Selector (Salesforce uses two selectors so it can rotate keys), specify the Domain, and set a Domain Match Pattern that controls which From-address domains this key signs. After you Save, the DKIM Key Details page shows a CNAME and an Alternate CNAME - for example example-sf-a._domainkey.yourdomain.com to example-sf-a.k4tyd2.custdkim.salesforce.com and example-sf-b._domainkey.yourdomain.com to example-sf-b.e6mxu6.custdkim.salesforce.com. Because these are CNAMEs delegated into custdkim.salesforce.com (not TXT records you paste), Salesforce holds the private keys and rotates the published keys behind the two selectors without you ever re-editing DNS. Two things people miss: the Domain field is permanent once saved (you'd have to create a new key to change it), and you cannot click Activate until both CNAMEs actually resolve in public DNS. Publish both records, wait for propagation, then return to DKIM Keys and click Activate - only then does Salesforce start signing outbound mail with d=yourdomain.com. Older Salesforce DKIM keys were self-managed TXT keys you generated and pasted; the modern "secure" DKIM key is the CNAME-delegated version described here and is what you should use.
DMARC
DMARC is a separate policy TXT record on your domain that Salesforce does not create - you publish it yourself at _dmarc.yourdomain.com, starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm Salesforce mail is passing DKIM aligned to your domain. This is the step where Salesforce's alignment quirk matters most: because Salesforce sends bounces from its own return-path domain, SPF authenticates but does not align, so on Salesforce mail DMARC passes on DKIM alignment alone. That's fine - DMARC only requires one aligned mechanism - but it means your DKIM key must be active and signing before you tighten policy, or legitimate Salesforce mail will fail. Watch the reports for a week or two, make sure Salesforce (and every other sender - Google Workspace, Microsoft 365, marketing tools) shows an aligned pass, then ramp to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole organizational domain; never add a second one just for Salesforce.
Check it actually worked
Don't trust the Salesforce DKIM Keys page status alone - confirm on a real message. Send from one of your Org-Wide Addresses to a Gmail mailbox, open the message, and choose the three-dot menu - Show original. You want DKIM: PASS with signed-by / d=yourdomain.com (if it shows salesforce.com, your key isn't active or your Org-Wide Address is on the wrong domain) and DMARC: PASS. SPF will usually list a Salesforce return-path domain rather than yours - that's expected, because DKIM, not SPF, is doing the aligning. In Salesforce, the DKIM Key Details page should read Active. Then run your domain through Qualisend's domain health check to confirm the SPF record, both DKIM selector CNAMEs, and the DMARC record all resolve cleanly and the SPF stays under the 10-lookup limit; once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer to confirm Salesforce appears as an aligned, passing source.
Common gotchas
- Coverage
Spring '26 enforcement: Salesforce now blocks mail from unverified domains - manual sends fail with "Not allowed to send from an unauthorized domain" and automated flows fail silently, logging "550 5.7.1 Delivery not authorized, message discarded" in Email Logs. Activate a DKIM key (or verify via Authorized Email Domains) for every domain your Org-Wide Addresses use.
- Coverage
SPF does not align on Salesforce. It sends bounces from its own return-path domain, so the SPF include authorizes but never aligns to your From address - DMARC leans entirely on DKIM. Adding the include without an active DKIM key will NOT get you a DMARC pass.
- Coverage
The DKIM key's Domain field is permanent. Once you Save, you can't edit the domain (or the selectors) - you'd have to create a new key. Get it right, and use the Domain Match Pattern to cover the domains you actually send from.
- DNS setup
You can't Activate DKIM until both CNAMEs resolve. The Activate button won't work while DNS is still propagating; wait (up to 48-72 hours) and re-check with a DNS lookup before trying again.
- Coverage
Deliverability access level silently blocks sends. If "Access to Send Email" is set to "System email only" or "No access" (common in sandboxes), Salesforce drops your outbound mail regardless of DNS - set it to "All email" under Setup - Deliverability.
- Coverage
Email Relay bypasses Salesforce's DKIM signing. If you route outbound through your own SMTP server via Setup - Email Relay, Salesforce doesn't sign the mail - your relay is responsible for SPF and DKIM, and these Salesforce records won't apply to that path.
- DNS setup
This covers Salesforce core (Sales/Service/Platform), not Marketing Cloud or Pardot. Marketing Cloud Engagement uses its own Sender Authentication Package (SAP) with different CNAMEs, and Account Engagement (Pardot) has its own setup - each product family authenticates separately.
- Breaks auth
Keep one SPF record. Merge include:_spf.salesforce.com into your single v=spf1 line - two SPF TXT records on the same domain is a PermError that breaks SPF for every sender.
Build your SPF record
Salesforce is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSalesforce SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.