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

Salesforce Marketing Cloud Account Engagement (formerly Pardot) is a B2B marketing automation platform that sends email on behalf of your domain. Without proper SPF, DKIM, and DMARC configuration, those messages are vulnerable to spoofing and increasingly likely to land in spam folders. By the end of this guide you will have all three records published and verified.

Reviewer note (remove before publishing): Vendor-specific values in this guide (SPF includes, DKIM selector names, admin-console paths) were drafted from general knowledge and must be verified against the platform's current documentation before publishing.

Before you begin

• DNS write access to every domain you intend to send from via Pardot (typically through your registrar or DNS host: Cloudflare, Route 53, GoDaddy, etc.).
• Salesforce administrator access with permissions to manage Marketing Cloud Account Engagement settings.
• A verified sending domain already added to your Pardot account — Pardot will not generate DKIM keys for a domain that has not been added first.
• Access to a Gmail or Yahoo mailbox for test message header inspection.
• An understanding of your current SPF record (run dig TXT your-domain.com or use an online SPF lookup tool before starting).

Step 1: Identify what's sending from Pardot

Pardot can send from multiple infrastructure paths depending on your account configuration: the shared Pardot sending pool, a Salesforce-managed dedicated IP, or Salesforce's transactional email infrastructure if you have Sales Cloud integration enabled. Each path may require a different SPF include or may share a single include. Before editing your DNS, log in to your Pardot admin and check Admin → Account Settings → Domain Management (path may vary by org) to confirm which sending domain and IP configuration your account is using. If you have a dedicated IP assigned, you may need to add an ip4: mechanism in addition to an include: — your account team or Salesforce support can confirm the exact IP ranges.

Step 2: Add the SPF include

Pardot's documented SPF include mechanism is include:_spf.google.com if your Pardot instance routes through Google infrastructure, but many Pardot accounts use Salesforce's own sending infrastructure. Salesforce has historically published SPF includes under their own domain. Check the Salesforce Help article on Pardot email authentication for the current authoritative include string before publishing.

The general form of an SPF record that includes Pardot alongside a common mail provider (such as Google Workspace) looks like this:

Before (example — your existing record):

your-domain.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

After (with Pardot's include added):

your-domain.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:<pardot-spf-include> ~all"

Replace <pardot-spf-include> with the exact string from Salesforce's current documentation. Do not guess this value — publishing an incorrect include silently fails rather than throwing an error.

SPF 10-lookup limit warning: SPF allows a maximum of 10 DNS lookups per evaluation. Pardot, especially in orgs that also use Salesforce Sales Cloud, Outreach, or other sales tools, can push you over this limit quickly. Each include: typically chains additional lookups inside it. If you are already close to the limit, use a tool such as MXToolbox SPF Checker to count your current lookups before adding another include. Exceeding 10 lookups causes an SPF permerror, which can result in DMARC failure even when all records appear correct.

Step 3: Enable DKIM in Pardot

Pardot supports custom DKIM signing so that outbound messages are signed with your domain rather than Salesforce's. The general workflow is as follows:

1. Log in to Salesforce and navigate to the Marketing Cloud Account Engagement (Pardot) admin area.
2. Locate the domain management or email authentication section. In recent Pardot UI versions this is found under Account Engagement Settings → Domain Management → Sending Domains, but Salesforce reorganizes navigation periodically — consult the current Salesforce Help documentation if the path has changed.
3. Select your verified sending domain and look for an option to enable or configure DKIM. Pardot will generate a public/private key pair and display the public key value you need to publish in DNS.
4. Copy the selector name and the public key value exactly as displayed. Pardot has historically used selectors in the format pm._domainkey, but this may differ by account or provisioning date — use the selector name shown in your own admin console rather than assuming a value.
5. Publish a TXT record in your DNS with the following structure:

DNS record name:

<your-selector>._domainkey.your-domain.com

DNS record value:

v=DKIM1; k=rsa; p=<your-public-key-from-pardot-admin>

If the public key string is longer than 255 characters, some DNS providers require it to be split into multiple quoted strings within a single TXT record. The correct format when splitting is:

"v=DKIM1; k=rsa; p=<first-part-of-key>" "<second-part-of-key>"

After publishing, return to the Pardot domain management screen and use the built-in verification button (if available) to confirm Pardot can resolve the key. Allow up to 48 hours for DNS propagation before troubleshooting a failed verification.

Step 4: Publish your DMARC record

DMARC ties SPF and DKIM together by telling receiving mail servers what to do when authentication fails. Start with a monitoring-only policy (p=none) for a minimum of 14 days before moving to p=quarantine or p=reject. This gives you time to identify all sending sources and fix any alignment issues without risking legitimate mail.

Publish the following TXT record at the exact name _dmarc.your-domain.com:

_dmarc.your-domain.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; ruf=mailto:dmarc-rua@dmarcbusta.pro; fo=1; adkim=r; aspf=r"

Parameter notes:

• p=none — monitoring only, no action taken on failing mail. Change to quarantine then reject once you have clean aggregate report data.
• rua=mailto:dmarc-rua@dmarcbusta.pro — aggregate reports are sent here for processing and display in the DMARC Busta dashboard.
• fo=1 — request forensic reports on any authentication failure (not just both SPF and DKIM failing).
• adkim=r and aspf=r — relaxed alignment. For Pardot specifically, relaxed alignment is important because Pardot may sign messages from a subdomain (send.your-domain.com) while the From header shows your-domain.com; relaxed DKIM alignment allows the organizational domain to match rather than requiring an exact match.

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.

Send a test email from a Pardot campaign or test send to a Gmail or Yahoo address you control. In Gmail, open the message, click the three-dot menu in the top-right corner of the message, and select Show original. In Yahoo Mail, open the message and select View Raw Message. Look for the Authentication-Results header near the top of the raw source.

A fully passing result looks like this:

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

What each result confirms:

• spf=pass — the sending IP is listed in your SPF record. If you see spf=fail or spf=softfail, the Pardot sending IP is not covered by your current SPF record.
• dkim=pass — the message was signed by a key that matches the public key in your DNS. If you see dkim=fail, the key is either not yet propagated, split incorrectly in DNS, or the selector name does not match what Pardot is using to sign.
• dmarc=pass — at least one of SPF or DKIM passed and the relevant identifier is aligned with the From header domain. DMARC can pass even if one of the two fails, as long as the other passes with alignment.

Common errors with Pardot

• DKIM selector mismatch. The selector Pardot uses to sign outbound messages must exactly match the label you published in DNS. If Pardot rotates or reassigns a selector (this can happen after certain account changes or Salesforce org migrations), the old DNS record will no longer match and DKIM will fail silently until you republish the new key.
• SPF softfail on dedicated IPs. If your Pardot account was upgraded to a dedicated IP after your SPF record was originally configured, the new IP may not be covered by the existing include. A ~all softfail will not cause immediate delivery problems but will prevent DMARC from passing on the SPF path. Verify your IP coverage using a live SPF record checker.
• DKIM public key split incorrectly. RSA-2048 public keys exceed 255 characters and must be split into multiple quoted strings in a TXT record. If your DNS provider concatenates or truncates them incorrectly, the key will fail to validate. Always verify the published record with dig TXT <selector>._domainkey.your-domain.com and compare the output to what Pardot shows in the admin console.
• DMARC alignment failure on subdomain sends. Pardot often sends from a tracking or sending subdomain (e.g., go.your-domain.com or send.your-domain.com). If the DKIM signature covers that subdomain but your From address is @your-domain.com, strict DKIM alignment (adkim=s) will fail. Use relaxed alignment (adkim=r) unless you have a specific reason for strict.
• SPF lookup overflow from Sales Cloud plus Pardot. Organizations using both Salesforce Sales Cloud and Pardot for email often accumulate includes from Salesforce email relay, Pardot, and third-party tools. The combined lookup count can exceed 10, producing a permerror that causes DMARC failure across all SPF-dependent sending. Audit your full SPF record with a lookup-counting tool before and after adding the Pardot include.

How DMARC Busta helps

The steps above give you a working baseline, but email authentication is not a one-time task. Pardot configurations change, sending IPs rotate, and new marketing tools get added to your stack — each change can silently break authentication that was passing the week before. DMARC Busta is designed to manage this continuously across 10,000+ domains.

Autopilot mode monitors your aggregate DMARC report data and guides policy progression from p=none to p=reject at a pace that reflects your actual sending posture — not a generic timer. SPF Auto-Repair is designed to detect lookup overflows and unauthorized sending sources, then delegate SPF management so your record stays within limits as your toolstack grows. Managed DMARC reporting normalizes and surfaces the data from receiving mail servers — including Pardot-specific sending paths — so you can act on failures rather than parse raw XML aggregate reports manually.

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