How to Set Up SPF, DKIM and DMARC for Salesforce (2026)

Salesforce sends transactional, marketing, and CRM-triggered email on behalf of your domain across several products — including Sales Cloud, Marketing Cloud, and Salesforce Pardot — each of which may require its own authentication configuration. Without properly published SPF, DKIM, and DMARC records, mail from these products is vulnerable to spoofing and increasingly likely to land in spam under 2024–2026 inbox provider requirements. Follow the steps below and you will have all three authentication layers in place and verifiably passing.

Before you begin

• Write access to the DNS zone for the domain you send from (at your registrar or DNS host — Cloudflare, Route 53, GoDaddy, etc.).
• Admin-level access to the Salesforce org or Marketing Cloud account you are authenticating.
• Knowledge of which Salesforce products are sending mail from your domain (Sales Cloud, Marketing Cloud, Pardot/Marketing Cloud Account Engagement, or a combination).
• A mailbox at Gmail or Yahoo that you can use to receive test messages and inspect raw headers.
• Any existing SPF record for your domain — you will need to edit it, not create a second one.

Step 1: Identify what's sending from Salesforce

Salesforce is not a single sending service. Depending on which products your org uses, mail from your domain may originate from Sales Cloud's built-in email relay, Marketing Cloud's shared or dedicated sending infrastructure, or Pardot (now marketed as Marketing Cloud Account Engagement). Each product family maintains separate IP ranges and, in many cases, requires a separate SPF include and its own DKIM key pair. Before touching DNS, log into each Salesforce product you use and confirm whether it is configured to send as your domain. If you have a dedicated IP assignment in Marketing Cloud, Salesforce Support or your account documentation will provide the exact IP or include string — use that instead of a shared include where available.

Step 2: Add the SPF include

Salesforce's exact SPF include strings vary by product and, in some cases, by region or account type. The values below reflect the most commonly documented includes as of early 2026; verify them against Salesforce's current Help documentation or your account's DNS setup guide before publishing.

For Sales Cloud email relay and general Salesforce platform mail, the include is typically:

include:_spf.salesforce.com

For Marketing Cloud (ExactTarget infrastructure), consult your Marketing Cloud Setup documentation — the include string may reference a subdomain specific to your account's sending region (e.g. include:<marketing-cloud-spf-include>). If you have a dedicated IP, Salesforce may instruct you to authorize it directly with an ip4: mechanism instead.

For Pardot / Marketing Cloud Account Engagement, check the Pardot Email Authentication setup page in your account for the current include string.

Edit your existing SPF record — do not create a second TXT record at the root. A typical before-and-after looks like this:

# BEFORE — existing SPF record
v=spf1 include:_spf.google.com ~all

# AFTER — Salesforce Sales Cloud added
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

If you use Marketing Cloud, add its include in the same record:

v=spf1 include:_spf.google.com include:_spf.salesforce.com include:<marketing-cloud-spf-include> ~all

SPF 10-lookup limit warning. The SPF specification allows a maximum of 10 DNS lookups during evaluation. Each include: mechanism counts as at least one lookup, and includes that chain to further includes compound this quickly. Salesforce, Google Workspace, Microsoft 365, and a CRM tool together can easily exceed the limit, causing SPF permerror and authentication failures. If you are already close to the limit, see the DMARC Busta section at the end of this guide — SPF Auto-Repair is designed specifically to resolve this without manual IP enumeration.

Step 3: Enable DKIM in Salesforce

DKIM setup in Salesforce differs by product. Follow the path for the product you are authenticating.

Sales Cloud (Salesforce Platform)

1. In Salesforce Setup, use the Quick Find box to search for DKIM Keys.
2. Click Create New Key. Salesforce will generate a key pair and present you with the selector name and public key value.
3. Note the selector name shown in the UI — it is typically a string like s1 or a Salesforce-assigned value; do not assume it is a fixed string.
4. Salesforce requires you to publish a TXT record in DNS before it will activate the key. The record to create is:

# DNS record name
<selector>._domainkey.your-domain.com

# DNS record type
TXT

# DNS record value (paste the exact public key string from Salesforce Setup)
v=DKIM1; k=rsa; p=<your-public-key>

5. After publishing the TXT record, return to DKIM Keys in Salesforce Setup and click Activate. Salesforce will validate that the DNS record resolves correctly before activation succeeds.

Marketing Cloud

1. In Marketing Cloud, navigate to Email Studio → Admin → Sender Authentication Package (SAP) or the Private Domain setup area. The exact path depends on whether your account uses a Sender Authentication Package or a custom From address configuration — consult Marketing Cloud's Email Authentication documentation for your account tier.
2. Marketing Cloud can manage DKIM signing on your behalf if a SAP is provisioned. In this case, Salesforce's deliverability team will provide you with the CNAME or TXT records to publish rather than a raw key. Follow the record values they supply exactly.
3. If you are using a custom domain without a full SAP, the process mirrors the Sales Cloud flow: retrieve the selector and public key from the admin interface, publish the TXT record, and confirm activation.

Pardot / Marketing Cloud Account Engagement

1. In Pardot, go to Admin → Domain Management (or the equivalent in the Lightning-integrated experience under Marketing Setup).
2. Add your sending domain if it is not already listed. Pardot will generate a DKIM key and display the TXT record values you must publish.
3. Publish the TXT record in DNS using the selector and public key shown in the Pardot interface, then return and verify the domain within Pardot.

In all cases, the published DNS record follows this form:

Name:   <selector-from-salesforce>._domainkey.your-domain.com
Type:   TXT
Value:  v=DKIM1; k=rsa; p=<public-key-string>

If Salesforce provides CNAME records rather than TXT records (common in Marketing Cloud SAP setups), publish CNAMEs as instructed — do not convert them to TXT entries.

Step 4: Publish your DMARC record

Start at p=none. This policy instructs receiving mail servers to take no action on unauthenticated mail while still generating reports — giving you visibility into all sources sending as your domain before you risk blocking legitimate email. Stay at p=none for a minimum of 14 days, or until your DMARC reports show Salesforce authenticating cleanly alongside all other senders.

Name:   _dmarc.your-domain.com
Type:   TXT
Value:  v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; ri=86400

Field reference:

Tag	Value used	What it does
v	DMARC1	Identifies the record as DMARC.
p	none	Monitor only — no mail is rejected or quarantined yet.
rua	mailto:dmarc-rua@dmarcbusta.pro	Aggregate report destination; replace with your own reporting inbox if not using DMARC Busta.
ri	86400	Report interval in seconds (once per day); many receivers send daily regardless.

Once aggregate reports confirm that Salesforce and all other sending services are authenticating, progress your policy:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-rua@dmarcbusta.pro; ri=86400

Increase pct gradually before moving to p=reject. Do not jump directly from p=none to p=reject at 100%.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

After publishing all three records, allow 15–30 minutes for DNS propagation, then send a test message from your Salesforce instance to a Gmail or Yahoo mailbox you control.

1. Open the received message in Gmail and click the three-dot menu → Show original. In Yahoo Mail, use More → View Raw Message.
2. At the top of the raw headers, locate the Authentication-Results header. You are looking for:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of sender@your-domain.com designates x.x.x.x as permitted sender)
  dkim=pass header.i=@your-domain.com header.s=<selector>
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

• spf=pass — the sending IP was found in your SPF record.
• dkim=pass — the DKIM signature in the message header was verified against the public key in DNS.
• dmarc=pass — at least one of SPF or DKIM passes and the authenticated domain aligns with the From: header domain.

If any result shows fail, permerror, or temperror, refer to the common errors section below before escalating to Salesforce Support.

Common errors with Salesforce

• DKIM key not activated in Salesforce. Publishing the DNS record alone does not enable DKIM signing. You must return to the Salesforce Setup screen and explicitly activate the key after DNS propagation. Mail signed before activation will fail DKIM.
• Wrong product's include used. Adding include:_spf.salesforce.com does not cover Marketing Cloud sending IPs. If you use multiple Salesforce products, each may require its own include or IP authorization. SPF failures from Marketing Cloud while Sales Cloud passes is a common symptom of this mismatch.
• SPF lookup limit exceeded. Organizations using Salesforce alongside Google Workspace, Microsoft 365, Zendesk, or other SaaS senders frequently hit the 10-lookup ceiling. The resulting SPF permerror causes DMARC to fail even when the include is correct. Audit your total lookup count with an SPF checker tool before and after adding Salesforce.
• DKIM public key split incorrectly across TXT strings. Some DNS providers wrap long TXT values in multiple quoted strings. The DKIM public key must be presented as a single concatenated value. If your DNS provider splits the key, verify that it reassembles correctly — a truncated or split key will produce dkim=fail consistently.
• From domain misalignment with Marketing Cloud. If Marketing Cloud is configured to send from a subdomain (e.g. em.your-domain.com) but your DMARC record is published at your-domain.com with no subdomain policy, alignment may fail depending on your DMARC aspf and adkim settings. Confirm that the authenticated domain in DKIM or SPF aligns — either exactly or as an organizational domain match — with the From: header.

How DMARC Busta helps

The steps above involve at least three DNS edits, Salesforce admin actions across potentially multiple products, and an ongoing process of reading aggregate reports and tightening your DMARC policy over weeks. For organizations running Salesforce alongside several other sending platforms, the SPF lookup count and policy progression become active maintenance tasks rather than one-time setup.

DMARC Busta's SPF Auto-Repair is designed to keep your SPF record within the 10-lookup limit automatically as sending sources change — without requiring manual IP enumeration or record edits each time a vendor updates their infrastructure. Autopilot mode handles DMARC policy progression from p=none through to p=reject based on aggregate report data, progressing only when authentication signals indicate it is safe to do so. Managed DMARC reporting normalizes and surfaces aggregate report data across all your domains — a capability designed to support MSPs and enterprises managing 10,000+ domains from a single interface. If you are setting up Salesforce authentication across multiple client domains, DMARC Busta's multi-domain management is built for that workflow.

Start your free trial and put your email authentication on autopilot.