Setting SPF and DKIM in Salesforce
Keep your email working.
By Jonathan Davis — Managing Partner, Solution Architect
Salesforce Email Authentication Guide
DKIM & SPF Setup — Step by Step
Why Email Authentication Matters
When Salesforce sends an email on your behalf — a workflow alert, a notification, an automated message — the receiving mail server asks two questions:
- Is this server allowed to send email for this domain? (That's SPF.)
- Was this email tampered with in transit? (That's DKIM.)
Without these records, your emails are more likely to land in spam folders, get flagged as suspicious, or be rejected entirely. Email authentication proves to the world that your Salesforce emails are legitimate.
⚠ Salesforce requires email domain verification for all orgs. If your sending domains aren't verified, Salesforce will block outbound emails from those domains — including workflow alerts, notifications, and any emails sent through Salesforce.
SPF vs DKIM at a Glance
- What it does: Declares which servers can send for your domain
- Record type: TXT record on your domain root
- How it works: Receiving server checks if sender is on approved list
- Without it: Emails flagged or rejected as unauthorized
- What it does: Digitally signs each email to prove authenticity
- Record type: Two CNAME records on your domain
- How it works: Receiving server verifies signature against public key
- Without it: Emails flagged as potentially tampered
Part 1: Creating DKIM Keys in Salesforce
This section walks through creating the DKIM keys inside Salesforce. If someone has already done this for you, skip to Part 2.
Step 2: Create a New Key
Click Create New Key and fill in the following fields:
- Key Size — Leave this set to 2048-bit (the default). Always use 2048 — 1024-bit is considered weak.
- Selector — A short, unique name like sf1 or salesforce. This becomes part of the DNS record name. No spaces or special characters.
- Alternate Selector — A second name like sf2. Salesforce uses two selectors to rotate keys automatically every 30 days.
- Domain — Your email-sending domain, e.g., yourcompany.com. This must match the domain in your Organization-Wide Email Addresses.
- Domain Match Pattern — This controls which sending addresses Salesforce will sign with this DKIM key.
- yourcompany.com — Signs emails where the sending domain matches exactly (most common).
- *.yourcompany.com — Signs only subdomain emails but not the root domain.
- yourcompany.com,*.yourcompany.com — Signs both the root domain and all subdomains.
Click Save. Salesforce will take a few minutes to generate the key pair.
Step 3: Copy the CNAME Records
After the key is generated, the DKIM Key Details page will show two CNAME records. These are what you (or your IT team) will add to your DNS. They look like this:
- Primary: sf1._domainkey.yourcompany.com → sf1.a1b2c3.custdkim.salesforce.com
- Alternate: sf2._domainkey.yourcompany.com → sf2.d4e5f6.custdkim.salesforce.com
The alphanumeric segment (like a1b2c3) is unique to your org. Copy these values exactly — don't guess or modify them.
You can't click Activate yet. You need to add the DNS records to your domain first and wait for them to propagate.
Part 2: DNS Records to Add
You need to add three DNS records total: two CNAME records (for DKIM) and one TXT record (for SPF).
DKIM — Two CNAME Records
Add both CNAME records from Part 1, Step 3. Both are required — Salesforce uses the alternate for automatic key rotation.
⚠ Some DNS providers automatically append your domain to the host field. If yours does, only enter the prefix (sf1._domainkey) — not the full sf1._domainkey.yourcompany.com. Entering the full name when the provider auto-appends will result in sf1._domainkey.yourcompany.com.yourcompany.com, which won't work. This is the single most common mistake.
SPF — One TXT Record
If you don't have an existing SPF record, add this TXT record to your domain root (@):
v=spf1 include:_spf.salesforce.com ~all
If you already have an SPF record (most companies do), you need to merge the Salesforce include into it. Do NOT create a second SPF record — having two SPF records on the same domain causes both to fail, breaking email authentication for your entire domain.
- Change: v=spf1 include:_spf.google.com ~all
- To: v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all
- Change: v=spf1 include:spf.protection.outlook.com -all
- To: v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com ~all
⚠ SPF Lookup Limit: SPF has a hard limit of 10 DNS lookups. Each include: directive counts toward this. If your record already has 7+ includes, adding Salesforce may push you over the limit. Exceeding 10 lookups causes email authentication to fail for ALL senders, not just Salesforce.
Part 3: Add DNS Records — Google Workspace
Follow these steps if your domain's DNS is managed through Google Admin Console or your domain registrar.
- Sign in to Google Admin Console — Go to admin.google.com with your admin account.
- Navigate to DNS settings — Account → Domains → Manage domains → Click your domain → Manage DNS.
- Add the first CNAME record — Type: CNAME. Host: sf1._domainkey (Google appends domain automatically). Data: paste value from Salesforce. TTL: 3600.
- Add the second CNAME record — Repeat for the alternate selector.
- Update your SPF record — Find existing v=spf1 TXT record → Edit → Add include:_spf.salesforce.com before ~all → Save.
- Wait for DNS propagation — Google DNS changes typically take 1–24 hours. Most are live within a few hours.
Note: If your domain was originally on Google Domains, it was migrated to Squarespace in 2024. You may need to manage DNS at domains.squarespace.com instead.
Part 4: Add DNS Records — Microsoft 365 / Outlook
Follow these steps if your email is on Microsoft 365. Microsoft 365 may manage your DNS directly, or it may tell you to add records at your domain registrar.
- Sign in to Microsoft 365 Admin Center — Go to admin.microsoft.com with your admin account.
- Navigate to your domain's DNS — Show all → Settings → Domains → Click your domain → DNS records tab.
- Add the first CNAME record — Type: CNAME. Name: sf1._domainkey. Value: paste from Salesforce. TTL: 3600.
- Add the second CNAME record — Repeat for the alternate selector.
- Update your SPF record — Find existing v=spf1 TXT record → Edit → Add include:_spf.salesforce.com before -all or ~all → Save.
- Wait for DNS propagation — Microsoft DNS changes typically take 1–4 hours.
Note: If Microsoft says DNS is managed externally, log into your domain registrar directly and add the records there.
Part 5: Activate DKIM in Salesforce
After your DNS records have propagated (wait at least 1 hour):
- Return to Salesforce Setup → DKIM Keys
- Click the DKIM key you created
- Click Activate
Salesforce will verify that both CNAME records resolve correctly before activating. If activation fails, wait a few more hours and try again — or use the verification steps below to check your DNS records.
If you wait 24 hours and the activation button is still not available, refer to This Article for additional troubleshooting.
Part 6: Verify Everything Is Working
- Mac (Terminal): dig CNAME sf1._domainkey.yourdomain.com
- Windows (Command Prompt): nslookup -type=CNAME sf1._domainkey.yourdomain.com
You should see it resolve to the Salesforce custdkim.salesforce.com address.
- Mac: dig TXT yourdomain.com
- Windows: nslookup -type=TXT yourdomain.com
Look for a single TXT record starting with v=spf1 that includes _spf.salesforce.com.
- MXToolbox — Check DKIM, SPF, and MX records all at once.
- Mail Tester — Send a test email and get an authentication score.
- WhatsMyDNS — Check DNS propagation across the globe.
Part 7: Common Mistakes
Symptom: Record resolves to sf1._domainkey.acme.com.acme.com
Fix: Only enter the prefix (sf1._domainkey) if your DNS provider auto-appends the domain.
Symptom: ALL email fails SPF — not just Salesforce.
Fix: You can only have one SPF TXT record per domain. Merge includes into one record.
Symptom: Activation fails in Salesforce.
Fix: Wait at least 1 hour. Verify with dig or nslookup before trying to activate.
Symptom: DKIM works initially but key rotation fails after 30 days.
Fix: Both the primary and alternate CNAME are required.
Symptom: DKIM lookup fails.
Fix: Set the CNAME to DNS-only (grey cloud icon). Do not proxy DKIM records through Cloudflare.
Symptom: SPF returns PermError — email auth fails for all senders.
Fix: Audit your includes. Remove unused senders or use an SPF flattening tool.
Need Help? If you run into any issues or aren't sure about any of these steps, just let us know. We're happy to walk through it with you or do a screen share to get it done together.
Email Me: