How to set up DMARC/DKIM/SPF for Salesforce Marketing Cloud
Salesforce Marketing Cloud needs SPF, DKIM, and DMARC on the domain that appears in the visible From address. I start by choosing the exact sending domain, usually a dedicated subdomain such as marketing.example.com, then I publish the Salesforce-provided DNS records and test a real campaign send.
The Salesforce private domain FAQ is the reference I use when deciding whether the account has delegated DNS, self-hosted DNS, Private Domain, or Sender Authentication Package. Those choices decide where SPF and DKIM records are published.
Add your domain
In Salesforce Marketing Cloud, I treat the authenticated sending domain as the product setup unit. If the account has Sender Authentication Package or Private Domain, Salesforce gives a domain plan that covers the sending domain, bounce handling, reply handling, click tracking, image hosting, and DKIM.
Salesforce Marketing Cloud authenticated domain setup screen.
- Access: Open Salesforce Marketing Cloud with an admin user and select the business unit that sends the campaigns.
- Domain: Choose the exact From domain, for example marketing.example.com. I prefer a dedicated subdomain for Salesforce Marketing Cloud.
- Package: Confirm Sender Authentication Package or Private Domain is enabled. If it is missing, request it through your Salesforce account or support path.
- Records: Get the Salesforce DNS zone file, delegated DNS instructions, or domain verification values. Do not invent SPF or DKIM values.
- Verify: After DNS is published, return to Salesforce Marketing Cloud and confirm the domain status shows verified, active, or ready.
Typical Salesforce Marketing Cloud DNS patterndns
bounce MX bounce.s50.exacttarget.com. reply MX reply.s50.exacttarget.com. click CNAME click.virt.s50.exacttarget.com. view CNAME view.virt.s50.exacttarget.com. 50dkim1._domainkey TXT "v=DKIM1; k=rsa; p=..." @ TXT "v=spf1 include:cust-spf.exacttarget.com -all"
Use Salesforce values
Salesforce Marketing Cloud stacks vary. A zone file can include stack-specific hosts, selectors, and IPs. I copy the exact values Salesforce provides for the tenant and domain, then I check DNS resolution before touching the DMARC policy.
|
|
|
|---|---|---|
Root | Brand mail | More shared DNS risk |
Subdomain | Campaigns | Cleaner isolation |
Private | SAP | Needs Salesforce setup |
Delegated | Managed DNS | Less direct control |
Choose the Salesforce Marketing Cloud sending domain before adding DNS.
Set up SPF
SPF for Salesforce Marketing Cloud matters when the return path uses your Salesforce-authenticated domain. Salesforce Marketing Cloud supports return path matching through Private Domain, so I publish the Salesforce SPF value on the return-path host Salesforce gives, then I test the actual envelope sender.
Salesforce Marketing Cloud SPF DNS record screen.
- Existing: Keep one SPF TXT record per DNS host. Merge Salesforce into the current record instead of publishing a second SPF record.
- Include: Use the value Salesforce gives for your stack. Common SFMC zone files use include:cust-spf.exacttarget.com, but the Salesforce zone file wins.
- Return-path: Publish SPF on the bounce or custom Mail From host Salesforce gives so SPF can pass on the envelope sender.
- Root: Do not add Salesforce to the root SPF record unless that host is the Mail From domain or Salesforce explicitly instructs it.
- Limit: Keep SPF under the 10 DNS lookup limit after every include, redirect, mx, a, and exists mechanism is counted.
SPF examplesdns
Host: bounce.marketing.example.com TXT: v=spf1 include:cust-spf.exacttarget.com -all Host: marketing.example.com TXT: v=spf1 include:cust-spf.exacttarget.com -all
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After the DNS TTL has passed, I run the SPF check against the exact host Salesforce uses for bounces or Mail From. A pass on the wrong host does not prove the Salesforce Marketing Cloud send is ready.
SPF checks I care about
- Pass: SPF returns pass for the Salesforce envelope domain used by the actual campaign.
- Domain: The envelope domain is in the same organizational domain family as the visible From address when SPF is meant to satisfy DMARC.
- Errors: SPF temperror, permerror, and too many lookups need DNS cleanup before policy enforcement.
- Scope: The Salesforce include belongs only on hosts Salesforce uses, not every domain in the company.
Set up DKIM
DKIM is the control I rely on most for Salesforce Marketing Cloud because DMARC passes when a valid DKIM signature uses the same organizational domain family as the visible From address. For SFMC, the selector and key normally come from Salesforce, not from a local key generator.
Salesforce Marketing Cloud DKIM selector and key screen.
- Selector: Copy the selector Salesforce gives, such as a stack-specific selector under _domainkey.
- Type: Publish the DKIM public key exactly as TXT or CNAME, depending on the Salesforce instruction for your account.
- Host: Use the full host Salesforce gives. Shorten it only when your DNS provider automatically appends the zone.
- Activate: Wait for DNS to resolve, then activate or verify DKIM inside Salesforce Marketing Cloud.
- Units: Check every business unit that sends as the domain. Multi-business-unit setups often have separate send profiles.
Delegated DNS
Salesforce manages the hosted zone after delegation. I still verify the live DKIM selector because the visible Salesforce status can lag DNS.
- Control: Salesforce publishes the required DKIM values.
- Risk: DNS troubleshooting depends on Salesforce visibility.
- Check: Query the selector after Salesforce marks the domain active.
- Fit: Good when the whole SFMC subdomain is dedicated.
Self-hosted DNS
Your DNS team publishes every Salesforce value. I compare the zone file with public DNS because copy mistakes are common.
- Control: Your team owns every TXT, CNAME, MX, and A record.
- Risk: Hostname suffix mistakes can publish DKIM under the wrong name.
- Check: Query the exact selector host shown by Salesforce.
- Fit: Good when central DNS controls every domain change.
DKIM host patterndns
Host: selector1._domainkey.marketing.example.com Type: TXT Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_SALESFORCE
Common DKIM failure
If Salesforce signs with an exacttarget.com or stack domain instead of your sending domain, DMARC can fail even when DKIM says pass. I handle that as a DKIM domain matching issue, not as a generic DNS issue. The SFMC DKIM failures page covers that symptom.
Set up DMARC
DMARC belongs on the domain in the visible From address. For a first Salesforce Marketing Cloud rollout, I start at p=none so I can collect aggregate reports without blocking legitimate campaigns. If the domain already uses quarantine or reject, I leave that policy in place and fix Salesforce until it passes.
- Host: Create TXT at _dmarc.marketing.example.com for a subdomain, or _dmarc.example.com for the root domain.
- Policy: Use p=none while testing new Salesforce Marketing Cloud authentication.
- Reports: Send rua reports to a mailbox or reporting address that can process XML.
- Subdomains: Set sp only when you need a different rule for child domains.
- Generator: Use the DMARC record generator to build the final record without hand-typing optional tags.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Run the DMARC check against the same domain that appears after the @ in your Salesforce Marketing Cloud From address. Checking the parent domain can miss a subdomain DMARC record that changes the result.
Passing condition
A Salesforce Marketing Cloud message passes DMARC when DKIM passes with your From domain family or SPF passes with the Salesforce return-path domain in the same domain family. DKIM is usually the more stable path because forwarded mail can break SPF.
Verify and troubleshoot
I never judge the setup only by DNS lookups. I send a real message from Salesforce Marketing Cloud because headers prove which domain signed DKIM and which return path SPF used.
- Send: Send from the real sender profile, not a plain test route if campaigns use another profile.
- Headers: Check Authentication-Results for spf=pass, dkim=pass, and dmarc=pass.
- DKIM: Confirm the DKIM d= domain is in the same organizational domain family as the visible From address.
- SPF: Confirm the Return-Path domain belongs to the Salesforce-authenticated domain when SPF is expected to help DMARC.
- Retest: Wait for TTL and test again before changing DMARC policy.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The quickest validation is a test email sent from the same Salesforce Marketing Cloud sender profile used in production. A real message exposes the DKIM selector, SPF envelope domain, rDNS, and DMARC result in one place.
|
|
|
|---|---|---|
DKIM fail | Bad key | Republish selector |
DKIM mismatch | Wrong d= | Fix SFMC domain |
SPF fail | Missing include | Update SPF |
DMARC fail | No domain match | Fix DKIM or SPF |
Permerror | SPF syntax | Repair record |
Use message headers to map each failure to the right fix.
Do not test the wrong path
A Salesforce system notification, a CRM email, and a Marketing Cloud campaign can use different mail paths. I only accept a pass result when the message came from the same SFMC business unit, sender profile, and domain used for production sends.
Get alerted when it breaks
Salesforce Marketing Cloud authentication can break after a business unit change, sender profile change, DNS cleanup, or Private Domain migration. Suped's product is strongest here because raw DMARC XML arrives after the damage has started, while alerts point to the exact source and failure.
- Sources: Suped groups Salesforce Marketing Cloud separately from other senders so I can see whether the issue is isolated.
- Alerts: Suped notifies when Salesforce volume starts failing SPF, DKIM, or DMARC above the threshold.
- Fixes: Suped shows the failing domain, the authentication result, and the DNS action to take.
- SPF: Hosted SPF and SPF flattening help keep Salesforce and other senders under lookup limits.
- Reputation: Blocklist monitoring (blacklist monitoring) helps catch domain or IP reputation issues in the same workflow.
Where Suped fits
For ongoing operations, Suped's DMARC monitoring connects aggregate reports, SPF, DKIM, blocklist checks, blacklist visibility, and deliverability signals in one workflow. That makes it the best overall fit for most teams managing Salesforce Marketing Cloud next to other senders.
Manual review
- Delay: Someone has to open XML reports after failures appear.
- Noise: Salesforce traffic is mixed with every other sender.
- Ownership: DNS, marketing, and security teams need manual handoff.
- Policy: Reject changes are harder to stage with confidence.
Suped workflow
- Detection: Source-level changes are surfaced without reading raw XML.
- Context: Salesforce results sit next to SPF, DKIM, and policy status.
- Action: Issues include tailored steps to fix the failing record.
- Scale: MSP and multi-tenant dashboards keep client domains separate.
Secure your domain with p=reject
I move Salesforce Marketing Cloud domains to p=reject only after real campaign traffic shows consistent DMARC pass results. The goal is to reject unauthenticated use of the domain without blocking valid journeys, automations, newsletters, and promotional sends.
- Baseline: Run p=none long enough to capture normal campaigns, journeys, automations, regional sends, and seasonal sends.
- Fix: Resolve every unknown Salesforce Marketing Cloud source before enforcing the domain.
- Stage: Move to quarantine first when production traffic still has unresolved owners.
- Percent: Use pct during staged enforcement when volume is high and domain ownership is split across teams.
- Reject: Set p=reject only when Salesforce DKIM passes consistently and every other sender is accounted for.
Policy readiness
Use real DMARC pass rates before enforcing Salesforce Marketing Cloud domains.
Monitor
Below 95%
Use this while DNS is new or sender ownership is incomplete.
Repair
95% to 98%
Fix DKIM, SPF, and unknown sources before moving policy.
Stage
98% to 99%
Use quarantine or pct when only edge cases remain.
Reject
99%+
Enforce only after the Salesforce source is stable.
Reject policy exampledns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Where Suped helps
Suped's hosted DMARC lets teams stage policy changes without repeated DNS edits. Combined with hosted SPF, SPF flattening, real-time alerts, and issue steps, it is the practical way to take a Salesforce Marketing Cloud domain to reject without guessing.
