DMARC & SPF with Marketing Cloud Account Engagement for Email Deliverability

by brandonin Advanced, Education, Pardoton Posted on

Why SPF and DMARC Are Essential for Email Deliverability in Salesforce Marketing Cloud

Email remains one of the most powerful digital marketing channels—but only if your messages actually reach the inbox. For organizations using enterprise platforms like Salesforce Marketing Cloud (SFMC), strong deliverability is not accidental. It is built on trust, authentication, and alignment with modern mailbox provider requirements.

Two of the most critical components of this foundation are SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting, and Conformance). Together, they protect your brand, improve inbox placement, and ensure your email program scales safely and reliably.

The Deliverability Challenge in Today’s Email Ecosystem

Mailbox providers such as Gmail, Microsoft, and Yahoo are increasingly strict about who is allowed to send email and how that email is authenticated. Spam filtering is no longer based solely on content—it heavily depends on domain reputation and authentication signals.

For high-volume senders using platforms like Salesforce Marketing Cloud, this means:

  • Your sending domain must prove it is legitimate
  • Your emails must be protected against spoofing and impersonation
  • Your brand reputation must be consistent across all campaigns

Without proper authentication, even well-designed, compliant emails can be blocked, filtered to spam, or rejected outright.

SPF: Authorizing Salesforce Marketing Cloud to Send on Your Behalf

SPF is a DNS-based protocol that tells mailbox providers which servers are allowed to send email for your domain.

When SPF is configured correctly for Salesforce Marketing Cloud:

  • Receiving servers can verify that SFMC is an approved sender
  • Spoofed or unauthorized messages are more easily rejected
  • Your domain’s sending reputation remains protected

Without SPF, mailbox providers may see your email as suspicious—even if it originates from SFMC—leading to degraded deliverability and trust issues.

DMARC: Enforcing Trust and Protecting Your Brand

DMARC builds on SPF (and DKIM) to define how mailbox providers should handle unauthenticated or suspicious messages.

With DMARC in place, you gain:

  • Protection against phishing and domain spoofing
  • Clear policies for how failed messages are treated
  • Visibility into who is sending email using your domain

For Salesforce Marketing Cloud customers, DMARC ensures that all marketing emails align with your domain’s authentication strategy and that unauthorized senders cannot exploit your brand identity.

Why SPF and DMARC Matter Specifically in Salesforce Marketing Cloud

Salesforce Marketing Cloud is a powerful, shared sending environment designed for scale. Because of this:

  • Authentication must be explicitly aligned with your sending domains
  • Inbox providers expect enterprise-grade standards
  • Missing or misconfigured authentication directly impacts inbox placement

Proper SPF and DMARC configuration is not just a technical checkbox—it is a core requirement for sustainable deliverability within SFMC.

A Foundation for Inbox Success

Including SPF and DMARC from the start allows your email program to:

  • Build and maintain sender reputation
  • Meet evolving mailbox provider requirements
  • Protect your brand from abuse
  • Maximize inbox placement and engagement

In short, SPF and DMARC are not optional—they are fundamental. For any organization sending email through Salesforce Marketing Cloud, these protocols form the backbone of a secure, trusted, and high-performing email strategy.

Setting up SPF Records for MCAE (Marketing Cloud Account Engagement)

For MCAE (Marketing Cloud Account Engagement, formerly Pardot), you use the specific Salesforce include mechanism, include:_spf.salesforce.com, in your domain’s DNS TXT record, combined with v=spf1 and a final qualifier like ~all or -all, to authorize Salesforce to send emails on your behalf, protecting your domain from spoofing. 

Here’s a breakdown of what to use:

  1. v=spf1: This is always the start of your SPF record, indicating the version.
  2. include:_spf.salesforce.com: This is the crucial part for MCAE/Pardot, telling receiving servers that Salesforce is an authorized sender.
  3. ~all or -all: This defines how to handle unauthorized senders. ~all (soft fail) marks them as suspicious, while -all (hard fail) rejects them.
  4. Your Existing Senders: You must also include other services (like Google Workspace, Microsoft 365) that send mail for your domain using their own include: mechanisms or IP addresses. 

Example Record (for a domain using Google Workspace & Pardot):

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

How to Implement:

  1. Access DNS: Log in to your domain host (GoDaddy, Cloudflare, etc.).
  2. Create/Edit TXT Record: Add or modify a TXT record with the host @ (or blank).
  3. Paste Value: Enter the SPF string above (adjusting for your other services) into the value field.
  4. Save & Wait: Save changes and allow up to 72 hours for propagation. 

Setting up DMARC for MCAE (Marketing Cloud Account Engagement)

To implement DMARC for Pardot, you first need to set up SPF and DKIM for your sending domain within Pardot (Domain Management), then generate a DMARC TXT record, and finally publish this record in your DNS provider, ensuring the policy (p=) aligns with your domain’s authentication status for emails sent via Pardot. It’s crucial to get reports (rua/ruf) to monitor authentication and gradually move to quarantine/reject policies, working with your IT team for DNS updates. 

Step 1: Set Up SPF & DKIM in Pardot

  1. Navigate to Domain Management: In Pardot, go to Admin > Domain Management.
  2. Add Your Domain: Add your sending domain and tracking domain, then click “Expected DNS Entries”.
  3. Get DNS Values: Copy the provided SPF, DKIM (DomainKey/DomainKey_Policy), and CNAME values (for tracking).
  4. Update DNS: Give these values to your IT team to add as TXT and CNAME records with your DNS host (e.g., GoDaddy, Cloudflare).
    • SPF Example: v=spf1 include:_spf.salesforce.com ~all (add to existing SPF record if present).
    • DKIM Examples: Add the provided _domainkey TXT records (like t=y; o=~; and the key itself).
  5. Validate: Check the DNS entries in Pardot to ensure they’re green. 

Step 2: Generate & Publish Your DMARC Record

  1. Use a Generator: Use an online tool (we like DMARCian inspector tool) to validate your DMARC record.
  2. Set Initial Policy: Start with p=none for monitoring, add your reporting email (rua=mailto:your@email.com), and generate the record.
  3. Create TXT Record: Go back to your DNS provider and create a new TXT record for _dmarc (or _dmarc.yourdomain.com).
  4. Enter Value: Paste the generated DMARC record string (e.g., v=DMARC1; p=none; rua=mailto:reports@yourdomain.com) into the TXT record value field.
  5. Save & Verify: Save the record and use a DMARC checker tool to confirm it’s published correctly. 

Important notes about SPF and Marketing Cloud Account Engagement (MCEA, Formerly known as Pardot)

Even though the Domain Management page in MCAE says SPF and DKIM are no longer required. We strongly recommend setting up these resources correctly to assure the best deliverability possible.

emails sent through Salesforce Account Engagement (formerly Pardot) no longer rely on your domain’s SPF record for authentication. 

Key Differences in SPF Usage

  • include:aspmx.pardot.com (Outdated): This entry was previously required in your domain’s SPF record for emails sent via Salesforce Account Engagement (Pardot).
  • include:_spf.salesforce.com (For core Salesforce platform emails): This is the correct identifier to include in your SPF record when sending mail from the core Salesforce application (e.g., standard sales emails, service emails), not from Account Engagement/Pardot. 

Current Best Practice for Salesforce Account Engagement (Pardot)

Emails sent through Salesforce Account Engagement now use a Salesforce-managed domain in the Return-Path header. This means: 

  • Your domain’s SPF record is no longer used for these emails. Salesforce maintains the necessary SPF records on their own sending domain.
  • If your domain’s SPF record still includes include:aspmx.pardot.com, you can safely remove it. 

For emails sent from the main Salesforce platform, you should still use include:_spf.salesforce.com in your DNS TXT record, alongside any other authorized senders. 

You can use tools like the MxToolbox SPF Query Tool to validate your current SPF records. It is highly recommended to use both SPF and DKIM for better email deliverability and security.