How to set up DMARC/DKIM/SPF for Salesforce
Published 6 Jul 2026
Updated 6 Jul 2026
10 min read
Summarize with
Salesforce email authentication is three separate jobs: SPF at your root domain, DKIM CNAME records from Salesforce, and a DMARC TXT record at _dmarc. I start with DKIM because it gives DMARC the most reliable pass, then I use SPF and DMARC reporting to catch DNS drift, sender changes, and copied org setups.
Salesforce's Salesforce SPF FAQ matches the same pattern: create DKIM keys, publish CNAMEs, and use the Salesforce SPF include when Salesforce sends for your domain.
- Use Salesforce records: Create DKIM keys in Salesforce Setup, then publish the exact CNAME targets Salesforce gives you.
- Use one SPF record: Add include:_spf.salesforce.com to your existing SPF TXT record, not a second TXT record.
- Use DMARC reports: A monitor policy tells you whether Salesforce, users, automations, and relays pass before you enforce.
Add your domain
Salesforce does not have one universal domain-authentication wizard for core CRM email. Add the sending domain when you create DKIM keys, then verify any org-wide From addresses that users or automation use.
Salesforce DKIM Keys setup screen with selector, alternate selector, domain, and domain match fields.
- Choose the From domain: Use the domain in the visible From address, such as example.com or a dedicated subdomain like mail.example.com.
- Open setup: In Salesforce, go to Setup, search for DKIM Keys, then open Email DKIM Keys.
- Create the domain key: Click Create New Key and enter the sending domain, not the Salesforce org domain.
- Match the pattern: Use an exact domain match for ordinary user@domain.com mail; use a subdomain pattern only when the From domain is a subdomain.
- Verify org-wide senders: If users send from shared addresses, open Organization-Wide Addresses and complete the email verification for each address.
- Document ownership: Record who controls DNS, Salesforce Setup access, and release windows before you edit records.
Domain mapping checklist
Before DNS changes, map each Salesforce sender to one domain. This prevents a clean DKIM setup on example.com while automations send from alerts.mail.example.com.
- Header From: The mailbox domain users see must match the domain you authenticate.
- Bounce domain: The Return-Path domain should use the same organizational domain when SPF is expected to count.
- DKIM domain: The DKIM d= value should be your domain after activation, not a Salesforce-owned domain.
|
|
|
|---|---|---|
Sending domain | From address | example.com |
SPF | DNS root | One TXT |
DKIM | DKIM Keys | Two CNAMEs |
DMARC | _dmarc | One TXT |
Salesforce authentication records to prepare.
Set up SPF
Publish or edit one SPF TXT record at the DNS root for the Salesforce From domain. Salesforce has no button for this step; DNS authorizes Salesforce by including include:_spf.salesforce.com. Salesforce supports Return-Path domain matching for this sending source, so SPF is worth setting up alongside DKIM.
- Find the SPF TXT: In DNS, look for a TXT record that starts with v=spf1 at the root host.
- Add Salesforce: Insert include:_spf.salesforce.com before the final all mechanism.
- Keep one SPF record: Multiple v=spf1 TXT records make SPF fail, even when each record looks valid.
- Check DNS lookups: Salesforce's include consumes DNS lookups, so keep the full SPF chain under ten lookups.
- Confirm Return-Path: SPF only helps DMARC when the Return-Path domain uses your domain or a matching organizational domain.
SPF record for SalesforceDNS
v=spf1 include:_spf.salesforce.com ~all
Merged SPF exampleDNS
v=spf1 include:spf.mailhost.example include:_spf.salesforce.com ~all
After saving DNS, run the SPF checker against the exact domain in the From address. Do this before sending test mail so you catch duplicate records and lookup limits early.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If the checker fails, fix SPF before moving on. DKIM can still carry DMARC, but a broken SPF record hurts other systems that rely on SPF and makes troubleshooting harder.
SPF failure patterns
- Duplicate SPF: Delete or merge extra v=spf1 TXT records at the same host.
- Wrong host: Add the record at example.com unless the Salesforce From domain is a subdomain.
- Lookup limit: Remove unused includes when SPF exceeds ten DNS lookups.
- Return-Path mismatch: If the Return-Path is Salesforce-owned, DMARC still needs DKIM to pass with your domain.
Set up DKIM
DKIM is the main Salesforce pass condition I care about. In Salesforce, generate a 2048-bit DKIM key, publish the two CNAMEs, then activate the key once Salesforce can see those records.
Salesforce DKIM key detail page showing two CNAME records and an Activate button.
- Open DKIM Keys: Go to Setup, Email, DKIM Keys.
- Create a key: Click Create New Key and choose 2048-bit unless your DNS host cannot store the generated record.
- Set selectors: Use simple selector names such as sf1 and sf2 so rotation stays clean.
- Enter the domain: Use the visible From domain or subdomain Salesforce sends from.
- Publish CNAMEs: Copy both Salesforce-generated host and target values into DNS exactly.
- Activate the key: Return to Salesforce after DNS propagation and click Activate.
Salesforce DKIM CNAME shapeDNS
Host: sf1._domainkey.example.com Type: CNAME Value: copy the first Salesforce target Host: sf2._domainkey.example.com Type: CNAME Value: copy the second Salesforce target
DKIM pass target
A real Salesforce message should show DKIM pass with d=example.com or the subdomain you authenticated. If it shows d=salesforce.com, DMARC does not treat that as your domain.
- Selector check: The selector in the header should match sf1 or sf2.
- Domain check: The DKIM d= domain should match the visible From domain's organizational domain.
- Activation check: A saved key is not enough; the Salesforce key must be activated.
Set up DMARC
DMARC is the domain policy receivers check after SPF and DKIM. Publish it on _dmarc.example.com for the domain in the visible From address. Start at p=none while Salesforce is being verified, unless the domain is already at p=quarantine or p=reject. In that case, keep the stronger policy and fix Salesforce until it passes.
- Check first: Search DNS for an existing _dmarc TXT record before adding anything.
- Use one record: A domain must have one DMARC TXT record at _dmarc.
- Set reporting: Replace dmarc@example.com with the mailbox or parser that receives aggregate reports.
- Keep enforcement: Do not reduce p=quarantine or p=reject just to make Salesforce easier.
- Generate safely: Use the DMARC record generator if you need a clean starting value.
Starter DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
After publishing, check the record at the public DNS layer. The Salesforce UI does not validate DMARC for the whole domain; DMARC covers every sender using that domain.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A passing DMARC result needs SPF or DKIM to pass with the same organizational domain as the visible From domain. For Salesforce, I expect DKIM to be the most stable pass.
Do not relax a live policy
If your domain already uses p=quarantine or p=reject, keep it. Fix Salesforce DKIM and SPF until Salesforce passes under the current policy.
- Existing enforcement: Treat failed Salesforce mail as a configuration problem, not a reason to weaken policy.
- New domains: Start at p=none, collect reports, then move up after legitimate senders are known.
- Subdomains: Publish a separate DMARC record when Salesforce sends from a dedicated subdomain.
Verify and troubleshoot
After DNS propagation, verify at three layers: DNS, Salesforce activation, and a real message header. I send a Salesforce notification to an external inbox because Salesforce UI success does not prove receiving systems see the same path.
The fastest real test is a message, not DNS alone. Send a Salesforce email generated by the same feature your users rely on, such as Flow, Case notifications, email alerts, or list email.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Use the test result to inspect SPF, DKIM, DMARC, Return-Path, DKIM selector, and the visible From domain. Then compare that one message against DMARC aggregate reports over the next day.
- Send real mail: Trigger the exact Salesforce feature that sends production mail.
- Inspect results: Read Authentication-Results for SPF, DKIM, and DMARC.
- Check DKIM domain: Confirm the d= value uses your domain or sending subdomain.
- Check SPF domain: Confirm the Return-Path domain is the domain you expected.
- Compare reports: DMARC aggregate reports should show Salesforce traffic passing after DNS has propagated.
|
|
|
|---|---|---|
DKIM fail | CNAME wrong | Copy again |
DKIM none | Key inactive | Activate |
SPF fail | Missing include | Merge SPF |
DMARC fail | Domain mismatch | Fix DKIM |
Common Salesforce authentication failures.
Salesforce checks
- Key status: DKIM key shows active, not saved or pending.
- Sender path: The same feature that failed is used for the retest.
- From address: The visible sender uses the authenticated domain.
DNS and header checks
- SPF result: SPF passes and the domain is expected.
- DKIM result: DKIM passes with your domain in d=.
- DMARC result: DMARC passes with disposition none, quarantine, or reject.
Get alerted when it breaks
Salesforce email authentication breaks in quiet ways: a new sandbox, a new org-wide address, a changed DNS provider, an email relay change, or an automation that uses a different From domain. Manual checks catch setup errors once. Monitoring catches regressions.
- Watch source IPs: A new Salesforce source can appear when routing or org configuration changes.
- Watch DKIM: A deleted CNAME or inactive key turns valid Salesforce mail into DMARC failures.
- Watch SPF: SPF lookup changes outside Salesforce can break the whole domain.
- Watch volume: Unexpected Salesforce volume usually means a new automation or sender path needs review.
- Watch reputation: Blocklist (blacklist) signals help explain delivery drops after authentication is fixed.
Suped's DMARC monitoring fits this stage: it turns aggregate reports into source-level Salesforce activity, flags failing DKIM or SPF, sends real-time alerts, and keeps DMARC, SPF, DKIM, blocklist (blacklist), and deliverability checks in one place.
Why Suped fits Salesforce
For most teams, Suped is the best overall DMARC platform because it turns Salesforce authentication results into concrete fixes rather than raw XML. Suped's product also covers SPF, DKIM, blocklist monitoring, hosted SPF, hosted DMARC, and MSP multi-tenancy.
- Issue detection: Suped identifies broken DKIM, SPF lookup limits, and unverified Salesforce sources.
- Alerts: Suped sends real-time alerts when failures cross thresholds.
- Hosted SPF: Suped can host and flatten SPF so Salesforce changes do not require repeated DNS edits.
- MSP scale: Suped's multi-tenant dashboard tracks Salesforce across many client domains.
Secure your domain with p=reject
Move to p=reject after Salesforce has passed for normal traffic and every other legitimate sender is accounted for. The goal is simple: mail that uses your domain either authenticates correctly or gets rejected.
Policy rollout thresholds
Use these checks before changing the DMARC policy on a Salesforce sending domain.
Monitor
p=none
Use while Salesforce DKIM and SPF are being validated.
Contain
p=quarantine
Use after Salesforce and other known senders pass consistently.
Block
p=reject
Use when remaining failures are unauthorized or retired senders.
- Prove Salesforce: Salesforce DKIM passes for real production messages across normal traffic.
- Review all sources: DMARC reports show every legitimate platform using the domain.
- Quarantine first: Use p=quarantine before p=reject when the domain has broad business use.
- Move to reject: Switch to p=reject when failures are unauthorized, abandoned, or test-only.
- Keep alerts on: A reject policy needs alerting so a future Salesforce change does not become a delivery incident.
Suped's Hosted DMARC helps with this rollout when DNS access is slow or split across teams: publish the hosted record once, then stage policy changes without opening a DNS ticket for every step.
Ready for reject
- Salesforce passes: DKIM passes with your domain for normal mail.
- Unknowns are gone: Reports no longer show legitimate sources failing.
- Owners exist: Each sending source has an owner and a rollback path.
Not ready
- DKIM is inconsistent: Some Salesforce mail still shows d=salesforce.com or no DKIM pass.
- Sources are unknown: Reports show IPs or sending domains no one owns.
- No alerts exist: A future Salesforce or DNS change would fail silently.
Reject policy rule
Do not set p=reject because Salesforce alone looks correct. Set p=reject when Salesforce and every other legitimate sender for the domain has a clean DMARC result.
