SPF, DKIM & DMARC for Salesforce Marketing Cloud.
Salesforce Marketing Cloud Engagement (formerly ExactTarget) doesn't authenticate email the way a self-serve ESP does. You can't paste a record and click "verify" — instead you buy a Sender Authentication Package (SAP) or the lighter Private Domain add-on, Salesforce provisions a dedicated sending subdomain (and usually a dedicated IP) for your account, and you either delegate that subdomain to Salesforce's nameservers or publish the exact SPF, DKIM, and MX records their deliverability team hands you. This guide covers the real SAP workflow: the include:cust-spf.exacttarget.com SPF mechanism, the shared 200608 DKIM key versus the dedicated CNAME-delegated key that actually aligns to your domain, subdomain delegation vs. self-hosting, Reply Mail Management, and the DMARC record you have to add yourself.
Why authenticate Salesforce Marketing Cloud?
Since February 2024, Gmail and Yahoo require every bulk sender to pass SPF, DKIM, and a DMARC policy — miss them and Marketing Cloud sends get throttled or spam-foldered at exactly the mailbox providers where your audience lives. Proper SAP authentication also removes the shared-domain / "via" indicator, puts your own brand on click-tracking, image, View-as-webpage, and CloudPages links, and lets SFMC send from a dedicated IP you can build a clean reputation on. Because SAP sends from a subdomain of your own domain, both SPF (envelope/return-path on your subdomain) and DKIM (a dedicated key on your subdomain) can align to your organizational domain for DMARC — a stronger position than most ESPs, but only if you sign with the dedicated DKIM key rather than the shared 200608 default and publish everything correctly.
The SPF reality for Salesforce Marketing Cloud
SFMC's SPF authorization is a genuine, live include: include:cust-spf.exacttarget.com. Resolve it today and you get a single flat record of roughly 50 ip4 ranges ending in ~all — no nested includes — so it costs exactly one of SPF's ten DNS lookups. Two things make SFMC different from a normal "add this include to your SPF" provider. First, the include belongs on the dedicated SAP sending subdomain (e.g. cloud.yourdomain.com), not on your root/apex domain — SFMC almost never sends as your bare domain, so putting it on the root usually adds a lookup that does nothing. Second, in Salesforce's recommended setup you delegate that whole subdomain to Salesforce via NS records and Salesforce hosts the SPF record for you, so you may never touch the SPF string directly. Only if you self-host DNS do you publish v=spf1 include:cust-spf.exacttarget.com ~all on the subdomain yourself. Either way it lives on the subdomain's own SPF record, so it never eats into your root domain's lookup budget — which is why this include should not be bolted onto your root-domain SPF by default.
Two ways to set it up
Delegate the sending subdomain to Salesforce (recommended)
- Add NS records pointing the SAP subdomain (e.g. cloud.yourdomain.com) to Salesforce's nameservers
- Salesforce hosts SPF (cust-spf.exacttarget.com), the dedicated DKIM key, the reply MX, and tracking records for you
- Salesforce can rotate the dedicated DKIM key automatically — no manual key coordination
- Lowest maintenance; fewer chances to fat-finger a record
- Do NOT also publish SPF/DKIM for that subdomain at your parent zone
Self-host the SAP records at your own DNS
- Keep DNS in-house and publish exactly the records Salesforce's deliverability team provides
- SPF: add v=spf1 include:cust-spf.exacttarget.com ~all on the sending subdomain
- DKIM: publish the account-specific CNAME (or TXT) Salesforce supplies — don't convert a CNAME to a TXT
- MX: add the Reply Mail Management record on your reply subdomain
- You own DKIM key-rotation coordination — more control, more upkeep
Step by step
- 1
Confirm you have SAP or a Private Domain
SFMC authentication is not self-serve. To authenticate on your own domain you need the paid Sender Authentication Package (or the lighter Private Domain add-on); Salesforce positions it for senders above ~250,000 emails/month. Without it you send from a shared exacttarget.com domain you cannot publish records for. Provisioning runs through your account team — the DNS/config portion is often around five business days once your request form is submitted, though contracting and IP allocation add lead time, so start here.
- 2
Decide your dedicated sending subdomain
SAP provisions a private domain that is a subdomain of your brand — typically cloud.yourdomain.com, email.yourdomain.com, or mkt.yourdomain.com. Every From address, link/image tracking URL, View-as-webpage link, and CloudPage in the account will use it, so pick a subdomain you're happy to see in inboxes and browsers long-term.
- 3
Choose delegation vs. self-hosting DNS
Preferred: delegate the sending subdomain to Salesforce's nameservers via NS records so Salesforce hosts SPF, DKIM, tracking, and reply records from a zone file it manages, and can rotate DKIM keys for you. Alternative: keep DNS in-house and publish the exact records Salesforce provides. Delegation is lower-maintenance; self-hosting keeps control but means you own key-rotation coordination.
- 4
Delegation path — add NS records for the subdomain
Create NS records for the sending subdomain pointing to the Salesforce/ExactTarget nameservers your team provides (e.g. cloud.yourdomain.com NS -> the hosts in Salesforce's zone file). Do not also publish SPF or DKIM for that subdomain at your parent zone — the delegated child zone becomes authoritative and parent records are ignored.
- 5
Self-host path — publish the SPF record on the subdomain
If you are not delegating, add a TXT record on the sending subdomain: v=spf1 include:cust-spf.exacttarget.com ~all. This is Salesforce's documented value; tighten ~all to -all only after you've confirmed nothing else sends as that subdomain. Keep it a single SPF TXT record — never two.
- 6
Publish the DKIM key
SAP provisions a dedicated DKIM key that Salesforce typically delegates as a CNAME on your sending subdomain — an account/stack-specific selector such as [stack]dkim1._domainkey.cloud.yourdomain.com pointing at [stack]dkim1._domainkey.sNN.exacttarget.com — so Salesforce holds and rotates the private key and the signature aligns to your domain. Older setups hand you a raw TXT public key to publish instead. The shared 200608 selector is the legacy key on exacttarget.com and does NOT align to your domain. Publish exactly what Salesforce supplies — you never generate the key yourself (unlike core Salesforce's Setup > DKIM Keys).
- 7
Set up Reply Mail Management
Configure the authenticated reply domain so subscriber replies, out-of-office bounces, and manual unsubscribe requests route back through SFMC. This publishes an MX record on a reply subdomain (and a parallel bounce subdomain) pointing at Salesforce's inbound infrastructure. Skip it and replies to your campaigns go nowhere useful.
- 8
Add DMARC, then verify and activate
SAP does not create DMARC — add _dmarc.yourdomain.com TXT yourself, starting at v=DMARC1; p=none with an rua mailbox. Confirm the private domain shows Active/authenticated in SFMC Setup, send a seed email, and check headers show spf=pass and dkim=pass with the d= and envelope domains aligned to your subdomain (not exacttarget.com). Once aggregate reports look clean, move the policy to quarantine, then reject.
Records to add
Salesforce Marketing Cloud 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 | cloud.yourdomain.com | v=spf1 include:cust-spf.exacttarget.com ~allSPF on the SAP sending subdomain (self-host method). In the recommended delegation model Salesforce hosts this for you; shown here for accounts keeping DNS in-house. The sending subdomain name is provisioned per account — illustrative. Lives on the subdomain's own SPF, so it never touches your root domain's 10-lookup budget. |
| CNAME | s10dkim1._domainkey.cloud.yourdomain.com | s10dkim1._domainkey.s10.exacttarget.comDedicated SAP DKIM key, CNAME-delegated so Salesforce can rotate it — this is the key that aligns to your domain for DMARC. The selector (e.g. [stack]dkim1) and stack number (sNN) are account-specific; publish exactly as Salesforce supplies. Do not convert a CNAME to a TXT or shorten the hostname. |
| TXT | <selector>._domainkey.cloud.yourdomain.com | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...Alternative DKIM shape — some SAP setups hand you a raw TXT public key instead of a CNAME. Selector is account-specific and supplied by Salesforce (the shared, non-aligning default is 200608 on exacttarget.com, not your domain). Illustrative key — do not copy verbatim. |
| MX | reply.yourdomain.com | reply.s10.exacttarget.comReply Mail Management MX so subscriber replies, OOO, and unsubscribe requests route through SFMC. A parallel bounce subdomain MX (bounce.sNN.exacttarget.com) is also provisioned. Reply subdomain, stack (sNN), and MX host are per-account — illustrative. |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add DMARC yourself — SAP never creates it. Start at p=none, then tighten to quarantine/reject once reports are clean. |
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 Marketing Cloud's setup costs against that budget.
Salesforce Marketing Cloud adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
Two different DKIM stories run through Salesforce Marketing Cloud. The legacy default is a single shared key with selector 200608 — created back in 2006 and used by every non-private-domain SFMC account. It's published on exacttarget.com, signs as d=exacttarget.com, and therefore does NOT align to your From domain for DMARC; being a fixed TXT selector, it's also awkward to rotate. When you provision SAP / a private domain, Salesforce instead issues a dedicated DKIM key and typically delegates it via a CNAME on your sending subdomain — an account/stack-specific selector such as s10dkim1._domainkey.cloud.yourdomain.com pointing at s10dkim1._domainkey.s10.exacttarget.com — so Salesforce holds and rotates the private key while the signature aligns to your organizational domain. Some setups still hand you a raw TXT public key to publish instead. Either way Salesforce always provides the exact record; you never generate the key yourself, unlike core Salesforce Sales/Service Cloud where you create it under Setup > DKIM Keys. Since a dedicated SAP key signs with a subdomain of your own domain, it's the most reliable path to a DMARC pass — confirm your package includes a dedicated, domain-aligned key rather than leaning on the shared 200608 default.
DMARC
SAP does not create or manage DMARC — you publish it. Add a TXT record at _dmarc.yourdomain.com: start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to collect aggregate reports without affecting delivery. Because SAP sends from a subdomain of your domain, SPF can align via the envelope/return-path on that subdomain and DKIM can align via the dedicated SAP key — so DMARC can pass on either, with DKIM the sturdier aligner. The shared 200608 key alone won't align (it signs as exacttarget.com), so make sure your account is signing with the dedicated key before you enforce. Watch the subdomain policy: if you set p=reject, add sp= deliberately and confirm the SAP sending subdomain is fully authenticated first. Move p=none -> quarantine -> reject only after reports confirm all of your legitimate SFMC (and other) mail is passing aligned.
Check it actually worked
Query the sending subdomain's SPF (dig +short TXT cloud.yourdomain.com) and confirm it resolves to include:cust-spf.exacttarget.com, then check the DKIM selector Salesforce gave you (e.g. dig +short CNAME s10dkim1._domainkey.cloud.yourdomain.com, or a TXT lookup if you were handed a raw key — not the shared 200608 selector). Send a seed/test campaign to a mailbox you control and inspect the headers: Authentication-Results should show spf=pass and dkim=pass, and the DKIM d= domain and SPF envelope domain should both be your own subdomain (aligned), not exacttarget.com. In Marketing Cloud Setup, confirm the private domain / SAP shows Active and authenticated (not Pending). Then run the sending subdomain and your _dmarc record through Qualisend's SPF, DKIM & DMARC checker and domain health check to catch typos, proxied records, or a missing DMARC policy before you scale up volume.
Common gotchas
- DNS setup
It's not self-serve. You can't just publish records and start sending — SAP / Private Domain is a paid add-on that Salesforce's team provisions (roughly five business days for DNS once your form is in, plus contracting lead time) and is positioned for senders above ~250,000 emails/month. No SAP means you send from a shared exacttarget.com domain you can't authenticate.
- DNS setup
Right product, right records. include:cust-spf.exacttarget.com and selector 200608 are Marketing Cloud Engagement (ExactTarget) ONLY. Core Salesforce Sales/Service Cloud uses include:_spf.salesforce.com with keys you generate under Setup > DKIM Keys, and Account Engagement (Pardot) uses its own tracker CNAMEs — never merge them into one SPF record.
- Breaks auth
Subdomain, not root. SAP sends from a dedicated subdomain (e.g. cloud.yourdomain.com), and the include/DKIM/MX live there. Don't bolt cust-spf.exacttarget.com onto your root/apex SPF unless your SFMC From address is genuinely on the root domain — for most accounts that just adds a lookup that does nothing.
- DNS setup
200608 is the shared key — and it doesn't align. Selector 200608 is Marketing Cloud's single shared DKIM key (from 2006), published on exacttarget.com; it signs as exacttarget.com, so it gives you no domain-aligned DKIM for DMARC, and as a fixed TXT selector it's hard to rotate. Domain alignment comes from the dedicated SAP key Salesforce delegates via CNAME — confirm your package includes one.
- DNS setup
Delegation and manual records conflict. If you delegate the subdomain via NS to Salesforce, do NOT also publish SPF/DKIM for that subdomain at your parent zone — the delegated child zone is authoritative and your parent records are silently ignored.
- DNS setup
Publish records exactly. Don't convert a Salesforce CNAME into a TXT, don't shorten hostnames, and don't proxy the records (no Cloudflare orange cloud) — any of these breaks DKIM, reply routing, or return-path resolution.
- DNS setup
SPF budget and qualifier. cust-spf.exacttarget.com is one flat ip4-only record = a single lookup (no nesting), but it's large. Salesforce's documented value ends in ~all; tighten to -all only once you're sure nothing else sends as that subdomain.
- DNS setup
DMARC is on you. SAP won't create _dmarc — without a published DMARC policy, Gmail and Yahoo bulk-sender enforcement will throttle or junk your Marketing Cloud sends.
Build your SPF record
Salesforce Marketing Cloud doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
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).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- 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 Marketing Cloud 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.