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). Salesforce is explicit that the Add Email Address and Register Domain options in From Address Management do not authenticate anything; only a domain configured as an SAP or Private Domain does.

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 (Salesforce shared IP for under 100,000 emails a month, a new dedicated IP for over 250,000, 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

Accounts on Hyperforce point at ns01.ums-dns-salesforce.com through ns04.ums-dns-salesforce.com instead; the New Domain flow tells you which set applies. 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. Not every DNS host supports delegating a subdomain, so check yours before you start.

Path 2: self-host. Choose self-hosted DNS, then pick Download Zone File from the domain's action menu and 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: its support team will not troubleshoot DNS for a self-hosted domain, 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 sits at Pending DNS validation, then In progress, and Salesforce says to allow up to five business days before it shows Active.

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 applies a basic DMARC record automatically during setup, and the record it suggests is v=DMARC1; p=reject; adkim=r; aspf=r; pct=100;. Notice what is missing: no rua. Salesforce's own KB says that without a mailto parameter no reports go anywhere, and any change to a delegated domain's DMARC record has to go through a support case. Ask for your reporting address to be added. 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 stop there 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, Salesforce documents that SPF will not align, because the bounce domain stays on the first brand, unless its multi-bounce domain feature is enabled for the account, which is another support case. 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 sits at Pending DNS validation past 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 downloaded file 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. Salesforce itself points customers at third-party inbox testers for the same check.
• 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.