Salesforce is one of the most widely deployed email-sending platforms in the world. It is not just a CRM. It is the engine behind millions of transactional notifications, marketing campaigns, automated workflows, and customer service replies every single day. When that email volume is tied to your domain and those messages arrive without proper authentication, the consequences go well beyond the spam folder. You are exposing your domain to spoofing, phishing attacks, and the kind of sender reputation damage that takes months to recover from.
The challenge with Salesforce email authentication is not that it is technically difficult. The challenge is that Salesforce’s default configuration is specifically designed to break SPF alignment, and most documentation stops at telling you to add an SPF record without explaining why that alone is insufficient to pass DMARC. Understanding the mechanics behind why Salesforce behaves this way, and what you need to do about it, is the difference between having authentication records that look correct and having authentication that actually works.
This guide covers the complete setup: SPF, DKIM, and DMARC across Salesforce Sales Cloud, Marketing Cloud, and Pardot (now Marketing Cloud Account Engagement). It explains how each protocol works in the context of Salesforce specifically, walks through step-by-step configuration, and covers the troubleshooting scenarios that trip up even experienced administrators.
What You’ll Need Before Starting
- System Administrator access in your Salesforce org
- DNS access for your sending domain (Cloudflare, Route 53, GoDaddy, etc.)
- Your sending domain confirmed – this is the domain in your Salesforce From: address
The Critical Thing Most Guides Miss: Salesforce’s SPF Alignment Problem
Before touching any DNS records, understand this:
By default, Salesforce routes bounces through its own infrastructure by setting the email’s Return-Path to a Salesforce-controlled address – something like sampleemail=salesforce.com__abc123@abc123.bnc.salesforce.com. This is intentional, for bounce management.
The problem: DMARC checks SPF alignment against the Return-Path domain, not the From address. Since that Return-Path belongs to Salesforce – not your domain – SPF will never be DMARC-aligned, even after you add include:_spf.salesforce.com to your record.
Adding Salesforce to your SPF record does not fix this.
The solution: DKIM is your primary DMARC alignment mechanism for Salesforce. DMARC only requires one of SPF or DKIM to align, so properly configured DKIM is all you need for compliance. You should still add Salesforce to your SPF record as a baseline, but DKIM does the heavy lifting.
Step 1: Set Up SPF for Salesforce
Even though SPF alignment won’t pass with default Salesforce settings, include it in your record for baseline authentication.
Check your existing SPF record first. Your domain can only have one SPF TXT record – a second record causes an immediate PermError. Look up your domain’s TXT records and find any record starting with v=spf1.
If one exists, add the Salesforce mechanism to it. If none exists, create a new TXT record on your root domain.
Salesforce SPF include:
include:_spf.salesforce.com
Example – Salesforce only:
v=spf1 include:_spf.salesforce.com ~all
Example – Salesforce + Google Workspace:
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all
Key rules:
- One SPF record per domain – merge all senders into a single record
- Keep total DNS lookups under 10 (each include: counts as one)
- Use ~all (softfail) during setup; move to -all (hardfail) once verified
Want SPF alignment too? You can disable Bounce Management in Salesforce (Setup → Email Administration → Deliverability → uncheck “Activate Bounce Management”). This forces Salesforce to use your domain in the Return-Path, enabling SPF alignment. Trade-off: Salesforce stops auto-processing bounce notifications. Most organizations skip this and rely on DKIM alone, which is fully sufficient.
Step 2: Set Up DKIM for Salesforce Sales Cloud
DKIM is the protocol that actually gets you DMARC-compliant. Configure this before publishing your DMARC record.
Generate the DKIM Key
- In Salesforce Setup, search DKIM Keys in the Quick Find box
- Click Create New Key
- Fill in the form:
- RSA Key Size: Select 2048-bit (required by most inbox providers as of 2024)
- Selector: Enter a unique name like sf-2025 – this becomes part of your DNS record name
- Domain: Enter the domain in your Salesforce From address (e.g., yourcompany.com)
- Domain Match Pattern: Enter your domain again
- Click Save
Publish the DNS Records
Salesforce will generate two CNAME records. Copy them exactly – one character error breaks verification.
In your DNS provider, create two new records:
| Field | Value |
| Type | CNAME |
| Name | [selector]._domainkey.yourdomain.com |
| Value | The long CNAME target Salesforce provides |
Repeat for the second CNAME record.
Cloudflare users: Set both records to DNS Only (grey cloud). Proxied CNAME records will break DKIM lookups.
Wait for DNS propagation – typically 15 minutes to a few hours, up to 48 hours.
Activate the Key
Return to Setup → DKIM Keys, open your key, and click Activate. If it fails, DNS hasn’t propagated yet – wait and retry.
Verify It’s Working
Send a test email to Gmail, open the original headers, and look for:
DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.com; s=sf-2025; …
The d= should be your domain. If it is, DKIM is active and aligned.
Step 3: Set Up DKIM for Salesforce Marketing Cloud
Marketing Cloud handles DKIM differently depending on whether you have the Sender Authentication Package (SAP).
Without SAP: Marketing Cloud uses Salesforce’s shared infrastructure. You cannot configure domain-level DKIM for your custom domain in this state. Emails sent via Marketing Cloud without SAP cannot be DMARC-aligned on your From domain.
With SAP: SAP provisions a custom subdomain (e.g., em.yourcompany.com) and handles DKIM signing under that subdomain automatically. DNS changes are made during SAP onboarding in coordination with Salesforce’s deliverability team. Since em.yourcompany.com shares the same organizational domain as yourcompany.com, DMARC relaxed alignment passes.
SAP is available for organizations sending 250,000+ emails/month. Contact your Salesforce account team to initiate onboarding.
Marketing Cloud DMARC alignment note: DMARC’s default relaxed alignment accepts subdomain matches – so DKIM signing for em.yourcompany.com aligns with a DMARC policy on yourcompany.com. No separate DMARC record needed for the subdomain.
Step 4: Set Up DKIM for Pardot (Marketing Cloud Account Engagement)
- In Salesforce, navigate to Marketing Cloud Account Engagement → Settings → Domain Management
- Click Add Domain and enter your sending domain
- Pardot generates CNAME records – publish these in your DNS exactly as provided
- Return to Domain Management and click Verify
Once verified, Pardot signs outgoing messages with DKIM automatically.
Step 5: Publish Your DMARC Record
With DKIM active, you’re ready for DMARC. Start with monitoring (p=none) before enforcing any policy.
Publish a TXT record at _dmarc.yourdomain.com (note the underscore – it’s a subdomain, not the root):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;
Core DMARC tags:
| Tag | What it does |
| p=none | Monitor only – no messages are blocked or filtered |
| p=quarantine | Failed messages go to spam |
| p=reject | Failed messages are rejected outright |
| rua= | Where to send aggregate reports (daily XML summaries) |
| ruf= | Where to send forensic reports (per-failure notifications) |
| pct= | Percentage of messages the policy applies to (default: 100) |
Only one DMARC record per domain is allowed.
Moving to Enforcement
Don’t rush this. The phased approach prevents blocking legitimate email from sources you forgot to authenticate.
Phase 1 – p=none (2–4 weeks minimum)
Monitor your DMARC reports. Confirm all Salesforce traffic shows dkim=pass. Identify any other sending sources that are failing.
Phase 2 – p=quarantine at 25%
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com;
Increase pct to 50, then 100 over the following weeks as you confirm no false positives.
Phase 3 – p=reject
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1;
Full protection. Unauthenticated emails claiming to be from your domain are rejected.
Reading Your DMARC Reports: What to Look For
DMARC aggregate reports arrive daily from each major mail provider (Gmail, Yahoo, Microsoft). For each sending source, you’ll see whether SPF and DKIM passed, and whether they aligned with your From domain.
For Salesforce traffic with Bounce Management enabled, this is the expected result – and it is compliant:
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
spf=fail is expected – Salesforce’s Return-Path doesn’t align. dkim=pass is what carries DMARC compliance. If you see dkim=fail for Salesforce traffic, DKIM is not properly configured or hasn’t been activated. Do not move to enforcement until Salesforce shows consistent dkim=pass.
A DMARC reporting tool – dmarcian, Valimail, or the reporting tools at dmarcs.com – is strongly recommended over reading raw XML directly. These tools surface new unauthorized senders immediately, which is the real security value of DMARC.
Common Errors and Fixes
DMARC fails even though SPF passes for Salesforce
Expected behavior with Bounce Management enabled. SPF passes at the mechanism level but doesn’t align with your From domain. Configure DKIM – that’s the fix.
DKIM key stuck in “Pending” in Salesforce
DNS hasn’t propagated yet, or Cloudflare proxy is enabled on the CNAME records. Disable the proxy, wait, and retry activation.
SPF PermError – too many DNS lookups
You’ve exceeded the 10-lookup limit. Audit your SPF record, remove unused include: entries, or replace nested includes with direct IP addresses using ip4:.
Multiple SPF records on the domain
Delete all but one and merge all include: entries into a single record.
DMARC record not found
Published at the wrong location. The record must be at _dmarc.yourdomain.com – missing the underscore (dmarc.yourdomain.com) or publishing on the root domain both cause lookup failures.
Quick Verification Checklist
SPF
- One TXT record on the root domain, starting with v=spf1
- include:_spf.salesforce.com is present
- Total DNS lookups ≤ 10
DKIM
- DKIM key created in Salesforce with 2048-bit key size
- Both CNAME records published in DNS
- Key shows Active in Salesforce (not Pending)
- Test email headers show dkim=pass with d=yourdomain.com
- DMARC reports confirm Salesforce traffic as dkim=pass
DMARC
- TXT record at _dmarc.yourdomain.com
- rua= points to a monitored inbox or reporting service
- Reports being reviewed; all Salesforce sources show as compliant
- Policy progression scheduled: none → quarantine → reject
Ongoing Maintenance
Rotate DKIM keys annually. Salesforce supports multiple active keys simultaneously, so rotation has zero downtime: create the new key, publish its DNS records, activate it, confirm it’s signing, then deactivate and remove the old key.
Audit SPF when adding new tools. Any new service that sends email from your domain – a support desk, a billing tool, a new marketing platform – needs to be added to SPF and have DKIM configured before it goes live.
Keep DMARC reports monitored. New unauthorized senders appear in reports the day they start. Catching spoofing campaigns early requires monitoring, not monthly check-ins.
Ready to get started? Use our DMARC record generator, SPF checker, and report analyzer to set up, validate, and monitor your Salesforce authentication.
