Email authentication for Salesforce: SPF, DKIM and DMARC

27 April 2026 · 11 min read

Salesforce is not one mail sender. It is a family of them, and that is the single fact that trips up most domains trying to reach DMARC enforcement. Sales Cloud and Service Cloud send case notifications and workflow emails one way. Marketing Cloud Engagement (the platform formerly called ExactTarget) sends through an entirely separate sending infrastructure. Marketing Cloud Account Engagement (Pardot) is different again. Each one has its own SPF include, its own DKIM mechanism, and its own rules about which envelope domain it stamps on the message. If you set up authentication for one and assume the others are covered, you will publish p=reject and start losing legitimate mail from the parts of Salesforce you forgot.

This guide is specific to Salesforce. It gives you the exact includes and selectors, explains how alignment actually works for each cloud, and walks the path from p=none to p=reject without an outage. It is not a generic DMARC explainer; if you want the fundamentals first, read how to reach p=reject without breaking email and come back.

Which Salesforce product is actually sending your mail?

Before you touch DNS, work out which sending paths your From: domain uses. Run a few weeks at p=none and read the aggregate reports, because the reports will tell you the truth about your senders rather than what you assume. The common Salesforce paths are:

• Core (Sales Cloud / Service Cloud) sending from Salesforce servers. Workflow emails, case responses, list emails and alerts sent directly by the platform.
• Core with Email Relay. The same core clouds, but configured to route outbound mail through your own corporate mail server (Microsoft 365, Google Workspace, a gateway). In this mode the relay host is the sender, not Salesforce, so its authentication applies instead.
• Marketing Cloud Engagement (ExactTarget). Bulk and journey email from a separate infrastructure, authenticated with a Sender Authentication Package (SAP).
• Marketing Cloud Account Engagement (Pardot). B2B marketing automation with its own DKIM and a separate verified domain model.

These do not share an SPF include or a DKIM setup. Treat them as four separate integrations that happen to live under one brand. Check what your domain currently publishes with the SPF checker and the DMARC checker before you change anything.

SPF for Salesforce core (Sales and Service Cloud)

When Salesforce core sends mail directly, the envelope sender (the MAIL FROM, also called the Return-Path) is what SPF checks. Salesforce publishes a maintained include for its sending ranges:

include:_spf.salesforce.com

Add it to your existing SPF record. You publish exactly one SPF record per domain, so you merge the include into the record you already have rather than creating a second one. A domain that sends from Salesforce core, Microsoft 365 and a transactional provider might look like this:

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

Two things to watch here.

The 10-lookup limit. SPF allows at most ten DNS lookups when a receiver evaluates your record, and include:_spf.salesforce.com is itself a nested include that expands to several more lookups. Salesforce, Microsoft and a marketing platform together routinely push a record past ten, at which point SPF returns PermError and stops authenticating for everyone, not just the newest sender. The failure is silent. We cover the mechanics in why your SPF hits the 10-lookup limit and in the 10-lookup limit glossary entry. If you are close to the ceiling, flattening is the fix, and our hosted SPF keeps a flattened record current as Salesforce rotates IPs.

Email Relay changes everything. If you have switched on Email Relay so core mail leaves through your own Microsoft 365 or Google Workspace tenant, then _spf.salesforce.com is irrelevant for that traffic. The relay host is the sender, so the relay host's SPF include (spf.protection.outlook.com, _spf.google.com) is what must be present and must pass. Do not add the Salesforce include for relayed mail; add it only for mail that genuinely leaves Salesforce servers.

DKIM for Salesforce core: generate the key, publish the CNAMEs

DKIM is where Salesforce core differs most from a typical provider, and it is the mechanism you should rely on for alignment. You generate the key inside Salesforce, not at your DNS host.

1. In Salesforce, go to Setup, then Email, then DKIM Keys.
2. Click Create New Key. Choose the key size (2048-bit is the sensible default), set the Selector to a short label you choose, and set the Domain to the exact sending domain, for example mail.example.com or example.com.
3. Decide the domain match. Domain Match of Exact match for the specified domain means the key applies only to that domain; the subdomain options let one key cover a domain and its subdomains.
4. Save. Salesforce generates the key pair and shows you two CNAME records to publish. It does not give you a single TXT record. Instead it publishes the public key on Salesforce's side and asks you to point two selector hostnames at it.

The two CNAME records take this shape, with the selector you chose and a Salesforce-generated token:

<selector>._domainkey.example.com.   CNAME   <selector>.<token>.dkim.<region>.salesforce.com.
<selector>2._domainkey.example.com.  CNAME   <selector>2.<token>.dkim.<region>.salesforce.com.

Salesforce uses two selectors so it can rotate keys without an outage: it can move signing from one to the other while both resolve. Publish both CNAMEs exactly as shown, including the trailing dots if your DNS editor expects fully qualified names. The reason it is a CNAME rather than a TXT is that Salesforce holds the private key and the published public key on its own DNS, then rotates it for you; your CNAME just delegates the lookup. Once the CNAMEs resolve, return to the DKIM Keys page and toggle the key to Active. Salesforce will not sign with a key you have not activated, so it is easy to publish the DNS, forget the toggle, and wonder why DKIM still fails.

Verify the published selector with the DKIM checker, querying <selector>._domainkey.example.com. If the CNAME resolves and the target returns a valid v=DKIM1 key, you are signing.

Alignment: the part that decides whether DMARC passes

DMARC does not care that SPF or DKIM merely passed. It cares about alignment: the domain that authenticated must match the domain in the visible From: header. This is where Salesforce setups quietly fail at enforcement even though the green ticks look fine in a header dump.

DKIM alignment is the reliable lever for Salesforce core. When you generate a DKIM key for example.com (or a subdomain you also use in the From:) and activate it, the d= value Salesforce signs with is your domain. That aligns with a From: of you@example.com, and DMARC passes on DKIM. This is why DKIM, not SPF, should carry your Salesforce alignment: it survives forwarding and it does not depend on the envelope sender.

SPF alignment is harder to get with Salesforce core because the Return-Path is set by Salesforce, often to a bounces address on a Salesforce-controlled domain, which does not align with your From:. If your Return-Path is bounce@something.salesforce.com while your From: is you@example.com, SPF may pass for the Salesforce domain but it does not align with yours, so it contributes nothing to DMARC. Do not count on SPF alignment from core; get DKIM right instead.

Bounce management matters here. In Setup > Email > Deliverability, Activate bounce management governs how Salesforce handles the Return-Path. With it active, Salesforce manages bounces on its own envelope domain, which is fine for deliverability but is exactly why SPF will not align. As long as your DKIM key is active and signs with your domain, DMARC still passes on the DKIM side, so this is the supported configuration: lean on DKIM alignment and let Salesforce own the bounce path.

You can confirm alignment without guesswork by reading the aggregate reports, where each source row shows whether SPF and DKIM passed and whether each aligned. Our DMARC report analyzer breaks this out per sender so you can see Salesforce specifically.

Marketing Cloud Engagement (ExactTarget): the Sender Authentication Package

Marketing Cloud Engagement does not use the core DKIM Keys screen or _spf.salesforce.com. It authenticates through a Sender Authentication Package (SAP), a paid add-on that gives you a private domain and dedicated IP, with its own SPF, DKIM and a custom Reply/Return path.

With an SAP and a private sending domain, you typically delegate a subdomain to Marketing Cloud, for example mktg.example.com, and publish the records Salesforce provides for that subdomain:

• An SPF entry for the dedicated sending infrastructure, given to you during SAP provisioning. Do not assume it is _spf.salesforce.com; Marketing Cloud Engagement uses different ranges, and the exact include or ip4 set comes from your SAP configuration.
• A DKIM record for the Marketing Cloud selector on that subdomain.
• A custom Return-Path / bounce domain so the envelope sender aligns with your private domain.

For DMARC, the key is that the From: address you send from in Marketing Cloud should sit on the authenticated private domain (news@mktg.example.com), so that the DKIM d= and ideally the Return-Path both align with the visible From:. If you send Marketing Cloud Engagement mail from a From: on your root example.com while the SAP authenticates mktg.example.com, you reintroduce an alignment gap. Keep the From: domain and the authenticated domain the same.

Because Marketing Cloud Engagement is a separate organisation, validate it separately: send a campaign to a seed address and inspect the headers, or watch the mktg.example.com source rows in your aggregate reports.

Marketing Cloud Account Engagement (Pardot)

Account Engagement (Pardot) has its own model again. You verify your email sending domain inside Account Engagement, and it provides DKIM records (commonly two selectors, in the same rotate-friendly spirit as core) plus guidance on SPF and a dedicated tracking and email domain.

The practical rules are the same as everywhere else in Salesforce:

• Publish the DKIM selectors Account Engagement gives you, on the domain you send from.
• Make sure the From: domain on your Account Engagement emails matches the domain those DKIM keys authenticate, so DKIM aligns.
• Treat its SPF/Return-Path separately from core; do not assume one include covers both.

If you send from a subdomain such as go.example.com for Account Engagement, your organisation-wide DMARC policy still applies to it via the subdomain policy unless you publish a specific record. We explain that inheritance in do I need a separate DMARC record for a subdomain and in the subdomain policy glossary entry.

Putting it together: the staged path to p=reject

You now have potentially four sending paths to authenticate. Here is the order that gets you to enforcement without breaking anything.

1. Publish a monitoring DMARC record

Start at observation, not enforcement. Publish:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

p=none enforces nothing; it only asks receivers to send you aggregate reports so you can see every source, including each Salesforce cloud. Generate a correct record with the DMARC generator and point rua at an inbox you actually read, or at our monitoring so the reports are parsed for you.

2. Identify every Salesforce source in the reports

Run p=none for two to four weeks. In the aggregate data you should be able to see core Salesforce, Marketing Cloud Engagement and Account Engagement as distinct sources, each with its own pass/fail and alignment status. This is the step people skip, and it is the one that prevents the outage. Use the report analyzer to read them quickly.

3. Fix alignment for each cloud

For every Salesforce source that shows DMARC failing:

• Core: create and activate a DKIM key on your sending domain so DKIM aligns. Accept that SPF will not align while bounce management owns the Return-Path; that is fine.
• Email Relay: make sure your relay host (Microsoft 365, Google Workspace) is DKIM-signing and SPF-passing for your domain, because that host is the real sender.
• Marketing Cloud Engagement: confirm the SAP domain, DKIM and Return-Path, and send the From: from that authenticated domain.
• Account Engagement: publish its DKIM selectors and match the From: domain to them.

Do not advance until every legitimate Salesforce source shows DMARC pass with at least one mechanism aligned.

4. Move to quarantine, in steps

Tighten gradually so any missed source surfaces as quarantined rather than lost:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; fo=1

Raise pct from 25 to 50 to 100 over a week or two, watching the reports between each step. If a Salesforce source you forgot starts failing, you will see it in the data while only a fraction of mail is affected.

5. Reach reject

Once every Salesforce path passes aligned at pct=100 quarantine with no surprises, publish:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; fo=1

At p=reject, anything that fails DMARC for your domain is refused outright, which is what actually stops spoofing. Because you proved each Salesforce cloud aligns first, your real mail keeps flowing. The full rationale for staging is in why p=none is a false sense of security.

Common Salesforce-specific mistakes

• Forgetting to activate the DKIM key. The CNAMEs resolve, but the key is left inactive in Setup, so Salesforce never signs. Toggle it to Active.
• Expecting SPF to align on core. Bounce management sets a Salesforce Return-Path, so SPF aligns to a Salesforce domain, not yours. Use DKIM alignment instead.
• Assuming one setup covers all clouds. Core, Marketing Cloud Engagement and Account Engagement each need their own DKIM and their own SPF/Return-Path. One green tick is not four.
• Blowing the 10-lookup limit. _spf.salesforce.com plus your other includes can push SPF past ten lookups into PermError. Check with the SPF checker and flatten if needed.
• Mismatched From: domain in Marketing Cloud. Sending from the root domain while the SAP authenticates a subdomain breaks alignment. Keep them the same.
• Going straight to reject. Publishing p=reject before reading reports is how Salesforce notifications and campaigns vanish overnight.

The practical takeaway

Salesforce authentication is not hard, but it is plural. The winning move is to treat each cloud as its own sender, lean on DKIM alignment rather than SPF (because bounce management owns the Return-Path on core), and never enforce before the aggregate reports show every Salesforce path passing aligned. Generate your record with the DMARC generator, watch the sources with the report analyzer, and keep your SPF under the 10-lookup ceiling.

If you would rather not babysit four Salesforce integrations, two DKIM selectors per cloud and a flattening budget by hand, DMARC Engine does the staged move to p=reject for you, keeps a flattened hosted SPF current as Salesforce rotates ranges, and emails you the moment any source, Salesforce or otherwise, starts failing. Either way, the order is the same: observe, align every cloud, then enforce.