- Salesforce sends email through three distinct products: core Salesforce (Sales/Service Cloud), Marketing Cloud Account Engagement (formerly Pardot), and Marketing Cloud Engagement. Each has separate authentication setup that must be configured independently.
- Account Engagement requires verifying domain ownership and configuring DKIM through Domain Management; SPF is provided by default but should be customized for production sending.
- Marketing Cloud only requires custom DNS configuration if you purchase the Sender Authentication Package (SAP), available to organizations sending over 250,000 messages per month.
- Core Salesforce email needs SPF includes for the Salesforce relay servers and DKIM keys generated within Setup. Without these, mail sent from Salesforce will appear unauthenticated.
- DMARC works across all three Salesforce products but only if alignment is correctly configured at the individual product level first. A single misconfigured product can cause DMARC failures that affect every Salesforce-sent message from your domain.
Salesforce is the largest enterprise CRM platform in the world, and its email-sending products handle billions of messages per month across customer service notifications, marketing campaigns, transactional alerts, and sales outreach. The platform also has one of the most fragmented email infrastructure stories of any major SaaS vendor: three distinct products, three different authentication setups, and a steady stream of feature evolution as Salesforce rebranded Pardot to Account Engagement and continued expanding Marketing Cloud capabilities.
Email administrators inheriting a Salesforce environment frequently find that authentication was set up partially (for one product but not others), that the historical Pardot configuration was never updated after the Account Engagement rebrand, or that the Sender Authentication Package on Marketing Cloud was paid for but never properly deployed. Any of these gaps produces inconsistent deliverability: some Salesforce-sent mail lands in the inbox, some lands in spam, and the patterns are hard to diagnose because the failures span product boundaries.
This guide is the complete authentication and configuration reference. It covers all three Salesforce email products, the specific DNS records each requires, and the cross-product considerations that determine whether your overall domain reputation stays healthy.
The Three Salesforce Email Products
Before configuring anything, identify which Salesforce products your organization actually uses. The setup is different for each.
| Product | Use Case | Authentication Setup |
|---|---|---|
| Core Salesforce (Sales/Service Cloud) | User-sent emails, case notifications, workflow alerts, Apex/Flow-triggered sends | SPF include + DKIM generated in Setup |
| Marketing Cloud Account Engagement (formerly Pardot) | B2B marketing automation, lead nurture, drip campaigns | Domain Management with verification key, DKIM CNAME, optional DMARC |
| Marketing Cloud Engagement | B2C marketing, transactional Journey Builder messages, high-volume campaigns | Sender Authentication Package (SAP) for custom DNS; default for accounts without SAP |
Many organizations use multiple products simultaneously. A typical enterprise might run Service Cloud for support cases, Account Engagement for B2B marketing, and Marketing Cloud Engagement for transactional customer notifications. Each product's authentication has to be configured independently, and all of them affect the overall reputation of your sending domain.
Configuring Core Salesforce Email Authentication
Core Salesforce sends email through Salesforce's own relay infrastructure. The sending IP is owned by Salesforce, but the From address typically uses your domain. To make this combination pass authentication, you need to authorize Salesforce in your SPF and configure DKIM.
Add the Salesforce SPF Include
Add Salesforce's SPF include mechanism to your existing SPF record:
v=spf1 include:_spf.salesforce.com include:[other-includes] -allThe _spf.salesforce.com include authorizes Salesforce's relay IPs to send mail for your domain. If your existing SPF record was simpler (just v=spf1 -all), add the Salesforce include before the all mechanism.
Be mindful of the SPF 10-DNS-lookup limit. Each include consumes lookups; if you already have several ESPs included, adding Salesforce can push you over the limit and cause SPF PermError, which fails authentication entirely. Use a SPF checker to verify your record stays under the limit after adding Salesforce.
Generate Salesforce DKIM Keys
In Salesforce Setup, search for "DKIM" and navigate to DKIM Keys under Email. Click "Create New Key" and configure:
- Selector: A short identifier for this key, like "sf2026" or "salesforce-prod"
- Alternate Selector: A second selector for key rotation, like "sf2026alt"
- Domain: Your sending domain
- Domain Match Policy: Choose whether the key signs all mail from the domain, only from specific addresses, or only from specific users
Salesforce generates two CNAME records (one for the primary selector, one for the alternate). Add both to your DNS. Once DNS propagates, return to the DKIM Keys page and click "Activate." Until activation, Salesforce sends without DKIM signing, and your mail will be unauthenticated.
Enable Compliance BCC for Visibility
Salesforce's Compliance BCC feature sends a copy of every outbound message to a nominated email address. This is invaluable for troubleshooting: you can see exactly what messages Salesforce is sending, inspect their headers, and verify authentication is working. Enable it in Setup under Email > Compliance BCC Email.
Pro deployment tip: Set Compliance BCC to a dedicated mailbox that you actively monitor during the rollout phase, then archive or delete the messages once you have verified authentication. Leaving it active long-term creates a meaningful storage footprint.
Configuring Account Engagement (Pardot) Deliverability
Account Engagement was rebranded from Pardot in 2022 but the underlying product architecture remains the same. Authentication is configured per sending domain through the Domain Management interface.
Add Your Domain to Domain Management
Navigate to Account Engagement Settings, then Domain Management. Click "Add New Domain" and enter the domain you want to send from. Account Engagement immediately generates a domain verification key.
Verify Domain Ownership
In the Actions column for your new domain, click "Expected DNS Entries." Account Engagement displays the DNS records you need to add. The first is a verification key (TXT record at a specific subdomain) that proves you control the domain. Add this record to your DNS and wait for propagation.
Add Account Engagement DKIM
The Expected DNS Entries page also displays a DKIM CNAME record. Account Engagement uses CNAME-based DKIM (delegating the actual key to Salesforce's DNS infrastructure rather than publishing the key in your zone), which allows Salesforce to rotate the key without requiring you to make DNS changes.
Add the CNAME to your DNS. Once propagated, the Activate button in Account Engagement becomes clickable. Click it to enable DKIM signing on outbound messages.
SPF for Account Engagement
Account Engagement provides SPF authentication by default through Salesforce's relay infrastructure. For production use, also add the Account Engagement SPF include to your domain's SPF record:
v=spf1 include:_spf.pardot.com include:[other-includes] -allThis ensures full SPF authentication for Account Engagement sends, particularly important if you ever move to a custom sending domain or change your default Salesforce email infrastructure.
Request a DMARC Policy
If you want DMARC protection for your Account Engagement sends, follow Salesforce's documented process to request DMARC configuration. This involves opening a case with Salesforce support and providing your desired DMARC policy. Salesforce configures the underlying infrastructure to support DMARC alignment for your domain.
Configuring Marketing Cloud Engagement Deliverability
Marketing Cloud Engagement (formerly ExactTarget) handles B2C marketing, Journey Builder messages, and high-volume transactional sends. Its authentication setup depends on whether your organization has purchased the Sender Authentication Package (SAP).
Without SAP: Default Salesforce Domains
Organizations without SAP send mail from default Salesforce domains. Authentication is handled by Salesforce, and you do not need to configure DNS for Marketing Cloud sending. The trade-off is that your sending appears to come from Salesforce-owned domains rather than your own brand, which damages recipient trust and Sender Reputation for B2C marketing where brand consistency matters.
The default-domain approach is appropriate for low-volume use cases or accounts that have not committed to long-term Marketing Cloud usage. For any organization seriously running B2C marketing through Marketing Cloud, SAP is effectively required.
With SAP: Full Custom DNS Configuration
The Sender Authentication Package provides a private sending domain, custom DKIM keys, optional dedicated IP addresses, and integration with your DMARC policy. SAP is sold as an add-on to Marketing Cloud at substantial additional cost; it is only available to accounts sending over 250,000 messages per month.
After purchasing SAP, Salesforce works with you to configure:
- Private domain: A subdomain you delegate to Salesforce (typically
m.yourdomain.comor similar). DNS for this subdomain is hosted by Salesforce. - Custom DKIM: DKIM keys are generated for your private domain and managed by Salesforce.
- SPF: Configured automatically for the private domain.
- Dedicated IPs (optional): Available as a separate add-on for additional cost.
- DMARC: Configurable through the standard Salesforce DMARC request process.
The setup process involves coordinating between your DNS team and Salesforce's implementation team, and typically takes 2-4 weeks to complete with proper testing.
Cross-Product Considerations and DMARC Alignment
The biggest deliverability risk in Salesforce environments is misalignment between products. DMARC requires that the From header domain align with either the SPF domain or the DKIM signing domain. If your different Salesforce products sign with different domains, DMARC failures can occur on a per-product basis without affecting others.
DMARC Alignment Strategy
The cleanest strategy is to use subdomain isolation: each Salesforce product sends from a different subdomain, and each subdomain has its own DKIM and DMARC configuration. For example:
sales.yourdomain.comfor core Salesforce mailmarketing.yourdomain.comfor Account Engagementengagement.yourdomain.comfor Marketing Cloud Engagement
Each subdomain gets its own DMARC policy and its own reputation. Problems with one product cannot damage the others. The trade-off is more setup complexity and more DNS records to manage.
Use DMARC Reports to Diagnose Per-Product Issues
DMARC aggregate reports show authentication results broken down by sending source. After implementing DMARC across your Salesforce stack, review reports weekly during the first 60 days to catch per-product failures. Common issues that show up:
- Account Engagement sending from a subdomain without proper DKIM activation
- Marketing Cloud SAP sends failing alignment because the private subdomain was not added to DMARC scope
- Core Salesforce sends failing because DKIM was generated but never activated
- Workflow-triggered sends from Apex code bypassing standard authentication paths
Salesforce Email Relay is a powerful but often-overlooked feature that routes Salesforce-generated mail through your own corporate mail servers (Microsoft 365, Google Workspace, or on-premise Exchange) before final delivery. This gives you complete control over authentication, archiving, and inspection, but it requires careful capacity planning because your mail servers absorb the full Salesforce sending volume. For high-volume Salesforce environments, Email Relay is the cleanest path to centralized authentication.
Common Salesforce Deliverability Issues
Salesforce-Sent Mail Going to Spam
The most common cause is incomplete DKIM setup: DKIM keys were generated but never activated, or DNS CNAME records were added incorrectly. Verify in DMARC reports that DKIM alignment is passing for Salesforce-sent traffic. Also verify SPF includes are present and the record stays under the 10-lookup limit.
High Bounce Rates from Account Engagement
Account Engagement does not enforce strong list hygiene by default. List hygiene issues compound quickly because Account Engagement makes it easy to import large prospect lists without verification. Use email verification before importing prospects, and configure prospect grading rules to suppress unengaged contacts automatically.
Marketing Cloud Send Delays
Marketing Cloud throttles outbound sending based on IP reputation, list quality, and historical engagement patterns. Sudden volume increases can trigger throttling that delays sends by hours. For predictable delivery timing, ramp send volumes gradually and avoid blast-and-go patterns from cold IPs.
Pardot/Account Engagement Documentation Confusion
Salesforce's documentation still uses both "Pardot" and "Account Engagement" in different places depending on when the article was last updated. Functionally they are the same product, but configuration paths and feature names may differ between old and new docs. When following Salesforce documentation, prefer the most recently updated version and verify the configuration paths match what you see in your actual Salesforce interface.
Ongoing Monitoring
Salesforce deliverability is not set-and-forget. The platform evolves, your sending patterns change, and inbox provider requirements continue to tighten. Build ongoing monitoring into your operational practices:
- Review DMARC aggregate reports monthly for per-product authentication failures.
- Monitor bounce rates by Salesforce product in the platform's built-in reports.
- Use Google Postmaster Tools and Microsoft SNDS to track reputation for the IPs and domains Salesforce uses on your behalf.
- Test inbox placement quarterly using seed list testing across major providers.
- Audit Salesforce DKIM keys annually and rotate them as part of standard security hygiene.
Frequently Asked Questions
Yes. Salesforce rebranded Pardot to Marketing Cloud Account Engagement in 2022. The underlying product, features, and configuration are the same; only the name changed. You may still see "Pardot" in older documentation, third-party guides, and some legacy interface elements within Salesforce itself.
SAP is required if you want to send Marketing Cloud mail from your own branded domain rather than Salesforce default domains. It is available only to accounts sending over 250,000 messages per month. For B2C marketing where brand consistency matters, SAP is effectively mandatory; for transactional or internal use cases, the default Salesforce domains may be acceptable.
The most common cause is incomplete authentication: DKIM was generated but never activated, SPF does not include the Salesforce mechanism, or DMARC alignment is failing for one specific product. Check DMARC aggregate reports to see which Salesforce sending source is failing alignment. Also verify your SPF record stays under the 10-DNS-lookup limit after adding Salesforce.
No. Each product manages its own DKIM independently. Core Salesforce generates keys in Setup, Account Engagement uses CNAME delegation through Domain Management, and Marketing Cloud with SAP gets its own keys at the private domain level. The keys are different by design and that is correct; what matters is that all three sign with domains that align with your From headers under DMARC.
Email Relay routes Salesforce-generated mail through your own corporate mail servers (Microsoft 365, Google Workspace, on-premise Exchange) before final delivery. Use it when you need centralized authentication, archiving, or DLP scanning across all corporate email. The tradeoff is that your mail infrastructure must handle the additional Salesforce volume, which requires careful capacity planning at high volumes.