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, with TXT records. 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: with the Spring ’26 release (enforcement began in March 2026), Salesforce no longer sends outbound mail from an 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. A key for yourdomain.com does not cover mail.yourdomain.com; each sending subdomain needs its own.

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 Key Details page; the hosts and targets are specific to your org. Publish them, wait for DNS to propagate (allow up to 72 hours), then return and activate the key. The activate button stays disabled until Salesforce can see the CNAMEs, so if it is grayed out, the records have not propagated yet (and watch for a proxying DNS host, like Cloudflare's orange cloud, hiding them). Once active, Salesforce rotates the key on its own schedule and prepares the next one under the alternate selector.

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 Account Engagement Settings > Domain Management, and it is two separate pieces, both TXT records listed under the domain's Expected DNS Entries action:

• Verify the sending domain with the validation key TXT record, then click Check DNS Entries.
• Set up DKIM by publishing the DomainKey TXT record at the selector host Pardot shows you. Our Pardot guide walks through it.

Do not confuse the DomainKey record 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 getting a zone file for the sending domain and applying it at your DNS host. If you are on Marketing Cloud Engagement, follow our Marketing Cloud guide and work the SAP setup with Salesforce rather than publishing 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 records 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.