Salesforce Marketing Cloud SPF and DKIM setup

What you are setting up

This page is about Marketing Cloud Engagement, the platform that used to be ExactTarget. If you send from Sales Cloud, Service Cloud, or Account Engagement (Pardot), those products use a selector-and-CNAME DKIM flow in Setup, and our Salesforce guide covers them. Marketing Cloud Engagement works differently. It authenticates a sending domain only through one of two paid products: the Sender Authentication Package (SAP), which bundles an authenticated private domain with branded link, image, and view-as-a-webpage hosts, a dedicated IP address, and Reply Mail Management; or a Private Domain, which is the authentication piece on its own (SPF, DKIM, and DMARC on the sending domain, no branding, no change to your IP assignment). Adding a From address under From Address Management is only an address; the domain itself authenticates only when it is configured as an SAP or Private Domain.

Salesforce recommends a subdomain of a domain your subscribers already know, such as email.yourdomain.com, and warns against using an existing domain that hosts your website, because the records Marketing Cloud needs would collide with the ones already there. The subdomain appears in your From address and in every tracked link, so pick one that reads as your brand.

Publish SPF and DKIM

In Marketing Cloud Engagement Setup, type ssl in the Quick Find box and open Domain SSL Certificates. Click New Domain (the button is disabled until your account holds an SAP or Private Domain license), enter the subdomain and a notification address, then choose Email authentication + URL branding for an SAP or Email authentication only for a Private Domain. You pick an IP arrangement (a Salesforce shared IP, a new dedicated IP, or a dedicated IP you already own), optionally turn on Reply Mail Management, and then make the decision that shapes the rest of this page: who hosts the DNS.

Path 1: delegate the subdomain to Salesforce. You publish NS records for the subdomain at your DNS host, and Marketing Cloud runs every record beneath it:

Type:  NS
Host:  email
Value: ns1.exacttarget.com

Type:  NS
Host:  email
Value: ns2.exacttarget.com

Type:  NS
Host:  email
Value: ns3.exacttarget.com

Type:  NS
Host:  email
Value: ns4.exacttarget.com

Some accounts are given a different set of name servers; the New Domain flow tells you which set applies, so copy the four it shows. With delegation, SPF and DKIM are already in place the moment the zone is live, because Salesforce authors the records itself, rotates keys when it needs to, and updates them when it adds a name server or changes sending IPs. Salesforce notes that not every registrar or DNS host supports delegating a subdomain, so check yours before you start, and that the subdomain must be used for Marketing Cloud and nothing else.

Path 2: self-host. Choose self-hosted DNS and get the zone file of every record the domain needs from Salesforce, then publish everything in it at your DNS host. Salesforce does not publish the values on a public page, because they are generated per account, so do not copy an SPF include or a DKIM key from a forum post. The zone file's shape is:

Type:  TXT     (SPF, on the sending subdomain)
Host:  email
Value: v=spf1 ... (exactly as the zone file gives it)

Type:  TXT     (SPF, on the bounce and reply hosts)
Host:  bounce.email and reply.email
Value: v=spf1 ... (exactly as the zone file gives it)

Type:  TXT     (DKIM)
Host:  <selector>._domainkey.email
Value: v=DKIM1; k=rsa; p=... (exactly as the zone file gives it)

Type:  MX      email, bounce.email, reply.email, leave.email
Type:  CNAME   click.email, image.email, view.email, pages.email, cloud.email
Type:  A       mta.email  (your dedicated IP)
Type:  TXT     _dmarc.email

The MX records route bounces, replies, and unsubscribes back to Marketing Cloud; the CNAMEs carry click tracking, images, view-as-a-webpage, and landing pages; the A record is the dedicated IP. Publish all of them, not just the SPF and DKIM lines. Self-hosting comes with two conditions Salesforce states plainly: it cannot support DNS configurations outside its own system, and Marketing Cloud sometimes adds a name server or changes sending IPs, which means a change to your records that nobody will make for you. Either way, the domain shows Active only once Salesforce finishes provisioning it, which takes business days rather than minutes.

Add DMARC

Your organizational domain still needs its own _dmarc TXT record. Start in monitor-only mode and ramp up:

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 Marketing Cloud twist is on the subdomain. On a delegated SAP or Private Domain, Salesforce publishes the DMARC record at _dmarc.email.yourdomain.com itself, and a record with a policy but no rua tag sends reports nowhere. Look the record up with our DMARC checker; if it carries no reporting address, open a support case and ask for yours to be added, because on a delegated zone only Salesforce can change it. On a self-hosted domain the _dmarc.email record is in your zone file and in your hands, so add rua=mailto:dmarc@yourdomain.com yourself.

The Salesforce Marketing Cloud gotcha

The subdomain's DMARC record hides your reports. DMARC looks for a policy at the exact From domain first and only falls back to the organizational domain when there is none. Marketing Cloud publishes one at _dmarc.email.yourdomain.com, so receivers use that record and never read the rua you carefully put on _dmarc.yourdomain.com. The result is a campaign platform that sends millions of messages and is invisible in your DMARC data until the subdomain record carries a reporting address of its own. This is the single most common reason a Marketing Cloud customer's aggregate reports look suspiciously quiet.

A second brand does not align by itself. If your SAP domain is e.firstbrand.com and you send a campaign from an address at secondbrand.com, SPF will not align, because the bounce domain stays on the first brand, and DKIM aligns only if Salesforce signs with the second brand's domain. Give each brand its own Private Domain rather than borrowing one brand's authentication for another.

Confirm it worked

• Check Domain SSL Certificates. The domain should read Active. If it is still pending after a few days on a delegated domain, confirm the four NS records resolve from outside your network; on a self-hosted domain, diff your zone against the file Salesforce gave you line by line.
• Send a test and read the headers. Send yourself a campaign, open it at the other end, and confirm the DKIM signature shows d=email.yourdomain.com, the Return-Path is on a bounce host under that same subdomain, and the result is dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports for the subdomain, not just the apex. Once the subdomain's DMARC record carries your rua, Marketing Cloud should appear as an aligned, passing source on both SPF and DKIM under email.yourdomain.com. trustyourinbox tracks each sending subdomain separately, so a silent subdomain stands out.