Salesforce SPF and DKIM setup

First: which Salesforce are you sending from?

This is the whole game with Salesforce. There are three different products that send email, in three different consoles, with three different DNS recipes. Sending the wrong records to the wrong product is the number-one Salesforce mistake. Match yours:

• Sales Cloud or Service Cloud (your core CRM org sending email): DKIM Keys in Setup. Section below.
• Marketing Cloud Account Engagement (formerly Pardot): Domain Management. Section below.
• Marketing Cloud Engagement (formerly ExactTarget): the Sender Authentication Package, mostly set up by Salesforce. Section below.

One thing that applies across all of them: DKIM is the leg that carries DMARC.Salesforce's SPF passes on a bounce or relay domain that does not align with your from address, so getting DKIM right is what makes DMARC pass.

New and important:as of the Spring ’26 release (rolling out through March 2026), Salesforce blocks outbound mail from any email domain you have not verified, by either an active DKIM key or an entry in the Authorized Email Domains list. Salesforce recommends the DKIM-key path, so setting up DKIM below is no longer optional for core org email.

Sales Cloud and Service Cloud (DKIM Keys)

In Setup, search DKIM Keys and click Create New Key. You enter a selector and an alternate selector (any names, e.g. sf-a and sf-b) and pick a key size (2048-bit recommended). Salesforce generates the key and gives you two CNAME records, a primary and an alternate (the alternate is there so Salesforce can rotate keys without breaking you):

Type:  CNAME
Host:  (the CNAME Record host Salesforce shows)
Value: (the target Salesforce shows)

Type:  CNAME
Host:  (the Alternate CNAME Record host Salesforce shows)
Value: (the target Salesforce shows)

Copy both records exactly from the DKIM Keys page; the hosts and targets are specific to your org. Publish them, wait for DNS to propagate (up to 72 hours), then return and activatethe key. The activate button stays disabled until Salesforce can see the CNAMEs, so if it is greyed out, the records have not propagated yet (and watch for a proxying DNS host, like Cloudflare's orange cloud, hiding them).

On SPF: Salesforce's include is include:_spf.salesforce.com (a full record looks like v=spf1 mx include:_spf.salesforce.com ~all). It is fine to add, but with Bounce Management on, the envelope sender becomes a Salesforce bounce address, so SPF does not align. DKIM is what aligns, and DMARC needs only one aligned leg.

Marketing Cloud Account Engagement (Pardot)

Account Engagement setup lives in Settings > Domain Management, and it is two separate pieces:

• Verify the sending domain with a TXTrecord (a validation key from the “Expected DNS Entries” action), then click Check DNS Entries.
• Set up DKIM, which uses the same selector-and-alternate CNAME flow as the core DKIM Keys feature above. Note Account Engagement DKIM defaults to a 1024-bit key; 2048-bit requires a dedicated sending IP and a support case.

Do not confuse the DKIM CNAMEs with the tracker domain CNAME (something like go.yourdomain.com pointing at a Pardot host). The tracker domain is for link tracking, not authentication, it is a separate record and does nothing for DMARC.

Marketing Cloud Engagement (Sender Authentication Package)

Marketing Cloud Engagement uses the Sender Authentication Package (SAP), a paid add-on that sets up a dedicated authenticated sending subdomain with SPF, DKIM, and branded link wrapping. Unlike the other two, you mostly do not hand-author these records.Salesforce provisions them, either by you delegating the subdomain to Salesforce's nameservers, or by downloading a zone file from the sending domain and applying it at your DNS host. If you are on Marketing Cloud Engagement, work the SAP setup with Salesforce rather than trying to publish individual DKIM records yourself.

Add DMARC

Whichever product you use, DMARC is a standard _dmarc TXT record at your domain, nothing Salesforce-specific. Start in monitor-only mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean.

The Salesforce gotcha

Beyond picking the wrong product, the recurring trap is expecting SPF to carry DMARC. Across all three products, Salesforce sends with a bounce or relay envelope that is not your domain, so SPF authenticates but does not align. Teams add include:_spf.salesforce.com, see SPF pass, and are baffled when DMARC still fails. The answer is always DKIM: get the signing domain to be yours, and DMARC passes on the DKIM leg.

Confirm it worked

• Send a test and read the headers. Send from the Salesforce product in question, open the original, and confirm the DKIM signature shows d=yourdomain.com and dmarc=pass. Our header analyzer reads it back in plain English.
• Re-check the records. A free DMARC audit confirms the DKIM CNAMEs resolve and your DMARC record parses.
• Watch the reports. Salesforce should appear as an aligned, passing source in your DMARC aggregate reports. trustyourinbox labels it as a known sender so a misconfigured product is easy to spot among everything sending as you.