SPF record for Salesforce Marketing Cloud Account Engagement (Pardot)

The exact SPF record

Copy the example that matches your setup. Each one is a single TXT record; the host is shown as your DNS provider usually expects it (@ means the domain itself).

Your main domain on Microsoft 365 stays as it is

Type: TXT · Host: @ · 1 of 10 DNS lookups Copy

v=spf1 include:spf.protection.outlook.com -all

Your main domain on Google Workspace stays as it is

Type: TXT · Host: @ · 1 of 10 DNS lookups Copy

v=spf1 include:_spf.google.com ~all

How SPF applies to Account Engagement (Pardot) mail

Account Engagement (Pardot) sends with a bounce (MAIL FROM) address on a domain it manages, so receivers check SPF there, not on your domain. You don't add anything to your SPF record for it; your domain is authenticated with DKIM instead.

• Salesforce still calls an SPF record for your domain a best practice. That is your normal record for your mailbox provider and other senders; its Account Engagement guides don't name an include for it.
• If everything is verified, each column on the Domain Management page shows a green checkmark. Salesforce notes that a TXT entry added in the last 24 hours may not show one yet.

How to add it

1. Open Domain Management: in standalone Account Engagement, Admin > Domain Management; in the Lightning app, Account Engagement Settings > Domain Management.
2. Click Add New Domain, enter the domain you send from and click Create domain.
3. In the Actions column, click Expected DNS Entries and copy the validation key. Publish it as a TXT record on that domain or subdomain.
4. Return to Domain Management and click Check DNS Entries. Repeat for every sending domain.

DKIM and DMARC alignment

Salesforce recommends DKIM for Account Engagement: copy the DomainKey value from Expected DNS Entries and publish it as a TXT record (see our Account Engagement DKIM page). DMARC is something you set up with your IT team, and an aligned DKIM signature is what lets it pass for your From domain.

DMARC passes when SPF or DKIM passes and the domain it checked matches your From domain. Our guide to SPF, DKIM and DMARC explains how the three fit together.

Common mistakes

• Two SPF records. A domain may publish only one record that starts with v=spf1. With two, receivers return a permanent error and SPF fails for all your mail (RFC 7208 section 3.2). Merge every sender into one record.
• More than 10 DNS lookups. Each include, a, mx, exists and redirect costs a lookup, nested ones included; over 10 is a PermError (section 4.6.4). Account Engagement (Pardot) adds nothing to your count, which is one more reason not to add an include for it. See how to fix too many SPF lookups.
• Choosing ~all or -all without a plan. -all asks receivers to reject unlisted servers; ~all asks them to accept but mark the mail. Once DMARC is enforced, receivers act on DMARC instead. Read SPF soft fail vs hard fail before you choose.
• Adding an include copied from an old blog post. Salesforce's current guides say SPF passes automatically, and every unneeded include costs DNS lookups.
• Confusing the validation key with the DomainKey. The validation key proves you own the domain; the DomainKey is the DKIM public key. Both are TXT records.
• Sending from a domain that doesn't match the one on the Domain Management page. Salesforce lists this as a reason SPF or DKIM doesn't pass in a test.