How to Set Up Email Deliverability in Salesforce

Part 1 focused on Salesforce itself. Part 2 focuses on the systems receiving your emails.

Modern email providers such as Microsoft 365 and Gmail use authentication standards to determine whether a message is legitimate. Without proper authentication, even a correctly configured Salesforce email may still be flagged as spam.

The two most important standards are SPF and DKIM.

SPF: Authorizing Salesforce to Send Email

Once Salesforce is permitted to send email, the next step is ensuring recipient mail servers trust those messages. This is where SPF comes in.

SPF (Sender Policy Framework) is a DNS-based email authentication standard that tells receiving mail servers which systems are authorized to send email using your domain. Without it, recipient servers have no reliable way to verify that Salesforce is an approved sender—so emails are more likely to be flagged as spam, quarantined, or rejected entirely.

How SPF Works

When an email arrives at a recipient's mail server, the server checks the sender's domain and looks up its SPF record in DNS. That record contains a list of systems authorized to send email on behalf of the domain.  If Salesforce is included in that list, the email passes SPF validation.  If Salesforce is not included, the receiving server may treat the message as suspicious.

Think of SPF as a guest list for your domain. You're telling other mail servers: These are the systems allowed to send email claiming to be from us.

Adding Salesforce to Your SPF Record

SPF records live in your organization’s DNS, typically managed by IT, a network team, or a domain administrator. 
To authorize Salesforce, add the following include statement to your existing SPF record:

include:_spf.salesforce.com

Example:

Before (if using Microsoft 365): v=spf1 include:spf.protection.outlook.com -all

After: v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all

⚠️ Never create a second SPF record. A domain should only have one SPF TXT record—having two will cause SPF to fail.

Working with Your IT Team

In most organizations, Salesforce admins don’t have direct access to DNS settings. 

A typical process looks like this:

1. Identify the domain Salesforce will send from
2. Provide the Salesforce SPF include value to IT
3. Ask IT to update the existing SPF TXT record
4. Wait for DNS propagation
5. Verify the updated record

Verifying SPF

After your IT team updates the DNS record, allow up to 48 hours for propagation. You can verify the change using a free online SPF checker by entering your domain. A correct result will show:

• Your original email provider’s include (e.g., Microsoft 365)
• include:_spf.salesforce.com
• A single TXT record for the domain

Why SPF Matters

SPF alone won't guarantee inbox placement, but it provides an important layer of trust. Proper SPF configuration helps:

• Improve email deliverability
• Reduce spam filtering
• Prevent email spoofing
• Increase trust with recipient mail servers

SPF, however, is only half of the authentication story. While SPF verifies who is allowed to send the email, it doesn't verify that the email content remained unchanged after it was sent. That's where DKIM comes in.

DKIM: Digital Signing of Salesforce Emails

Where SPF verifies that Salesforce is authorized to send on your domain’s behalf, DKIM (DomainKeys Identified Mail) adds another layer of trust by digitally signing every message Salesforce sends.

SPF proves who sent the email. 

DKIM proves the email hasn’t been modified after it was sent. 

Together, they form the foundation of modern email authentication and meaningfully improve deliverability.

How DKIM Works

Salesforce holds a private key and uses it to sign each outgoing email. The corresponding public key is published in your DNS. When a recipient’s mail server receives the email, it retrieves that public key and uses it to verify the signature. If the signature checks out, the email is authenticated.

Think of it as a tamper-evident seal: if anything changes after Salesforce sends the email, the seal breaks and the receiving server knows the message was altered.

Setting Up DKIM in Salesforce

DKIM setup is a three-phase process coordinated between Salesforce and your IT/DNS team.

Phase 1: Generate DKIM Keys 
Navigate to: Setup → Email → DKIM Keys, then click New.

Field	Recommended Value	Notes
Key Size	2048-bit	Preferred for modern security standards
Selector	sf1	Avoid spaces or special characters
Alternate Selector	sf2	Used as a backup selector
Domain	yourdomain.com	Domain Salesforce sends from
Domain Match	Exact Domain	Most common configuration

 

After clicking Save, Salesforce generates two CNAME records. 

Don’t activate the keys yet—Salesforce is waiting for the DNS records to be published first.

Phase 2: Publish the CNAME Records to Your DNS
Provide the two CNAME values to your IT team. Each record has:

• Record Name: the selector prefix (the part before your domain name)
• Target/Value: the long Salesforce string shown after “CNAME”

Your DNS administrator must create both records exactly as provided.

💡 The trailing dot at the end of the Salesforce CNAME target (e.g., “salesforce.com.”) may be required by some DNS providers. Check your existing records to see if other entries include a trailing dot.

DNS propagation can take up to 48 hours. This is a hard wait—don’t attempt to activate DKIM before it completes.

Phase 3: Activate DKIM

After DNS propagation is complete:

1. Navigate back to Setup → Email → DKIM Keys
2. Open the first selector
3. Click Activate
4. Repeat for the second selector

Once activated, Salesforce begins signing outbound email using the configured keys.

⚠️ If the Activate button isn’t visible after 48 hours, the DNS records haven’t propagated correctly. Review the CNAME entries with your IT team. If the issue persists after 72 hours, open a Salesforce Support case.

Coordinating SPF and DKIM with IT: The Relay Race

Unlike many Salesforce configurations, SPF and DKIM require a coordinated effort between Salesforce admins and IT Teams. The easiest way to manage it is to treat the process as a simple handoff workflow.

Step	Who Acts	Action
1	IT Team	Update SPF record to include _spf.salesforce.com
2	Salesforce Admin	Verify SPF configuration, then generate DKIM keys in Salesforce
3	Salesforce Admin	Share the two CNAME values with IT
4	IT Team	Add both CNAME records to DNS; confirm when done
5	Salesforce Admin	Wait 48 hours, then activate DKIM in Salesforce
6	Salesforce Admin	Run Test Deliverability to confirm full authentication

 

Multiple Production Orgs Using the Same Domain

Organizations occasionally maintain multiple Salesforce Production orgs that send email using the same corporate domain.This is fully supported—the key requirement is that each org uses unique DKIM selectors.

For example:

Org	Selector 1	Selector 2
Production Org A	sf1prod1	sf2prod1
Production Org B	sf1prod2	sf2prod2

 

Because the selectors are unique, both orgs can publish DKIM records for the same domain without creating DNS conflicts.

💡 Use a selector naming convention that clearly identifies the org responsible for the key. This makes future troubleshooting significantly easier.

 

Sample Coordination Email to IT

Subject: Salesforce Email Authentication Setup – Action Required

Hi Team,

I'm enabling email deliverability in Salesforce and need your help with two DNS updates. This ensures Salesforce-generated emails are properly authenticated and don't get marked as spam.

Step 1 (IT Team): Update SPF Record

Please add include:_spf.salesforce.com to the existing SPF TXT record for our domain. Please do not create a new SPF record.

Step 2 (Salesforce Admin)

Once SPF is updated, I'll generate DKIM keys in Salesforce and send over two CNAME values.

Step 3 (IT Team)

Please add the two DKIM CNAME records to DNS. After propagation, I'll activate DKIM in Salesforce.

Please let me know once Step 1 is complete so we can proceed.

Thank you.

 

Quick Reference: Deliverability & Authentication

Topic	Key Navigation Path	Critical Notes
Email Deliverability	Setup → Email → Deliverability	Sandbox defaults to “System Email Only”
Test Deliverability	Setup → Email → Test Deliverability	Test after each configuration change
SPF Record	DNS (via IT)	Add to existing record — never create a second
DKIM Keys	Setup → Email → DKIM Keys	Wait 48 hrs after DNS changes before activating

 

 

Final Thoughts