Summary
It's common for companies to find both Pardot and ExactTarget (now known as Salesforce Marketing Cloud, or SFMC) within their Sender Policy Framework (SPF) record. This often stems from historical acquisitions by Salesforce, as these were once distinct platforms. While they are now part of the same parent company, their email sending infrastructures can operate independently, necessitating their inclusion in your domain's SPF record. Proper management of these entries is crucial to maintain email deliverability and avoid common SPF errors, such as the 10-DNS-lookup limit.
Key findings
- Single record rule: Despite using multiple Salesforce products, a domain should only have one SPF record. All authorized sending platforms, including Pardot and SFMC, must be consolidated into this single record.
- Acquisition history: Pardot and ExactTarget were separate entities acquired by Salesforce. They retained distinct (though sometimes overlapping) sending infrastructures, leading to both potentially needing SPF authorization.
- Typographical errors: Minor typos in domain names within an SPF record (e.g., exacttartget.com instead of exacttarget.com) can invalidate SPF authentication and should be corrected promptly.
- Complex setup: Managing SPF for multiple Email Service Providers (ESPs) and subdomains, particularly within large organizations, requires careful planning to avoid exceeding the 10-DNS-lookup limit.
Key considerations
- Verify current usage: Confirm with your marketing and IT teams which Salesforce platforms are actively used for sending email from your domain. This includes both current campaigns and any legacy systems.
- Consolidate includes: Ensure all legitimate sending sources for your domain are listed in a single SPF TXT record, using include mechanisms to reference external SPF records (like those for Salesforce). For guidance, see how to set up email authentication for multiple ESPs.
- Consult partners: Before making any changes to your SPF record, communicate with your marketing partners or Salesforce administrators to understand their current and historical email sending practices.
- Monitor and test: After any updates, use an SPF checker to ensure the record is valid and all necessary senders are authorized. Regularly monitor your DMARC reports for authentication failures that could indicate issues.
What email marketers say
Email marketers often encounter SPF record complexities, especially when dealing with multiple platforms from the same vendor, like Salesforce's Pardot and Marketing Cloud. Their concerns typically revolve around understanding which systems are active, avoiding accidental disruption of email flow, and ensuring correct authentication for optimal deliverability. Many find themselves trying to decipher historical configurations and legacy setups.
Key opinions
- Historical confusion: Marketers frequently deal with SPF records set up before their tenure, making it difficult to ascertain why specific entries like both Pardot and ExactTarget exist.
- Typo recognition: A common first step for marketers is to identify and correct any obvious typos in domain names within the SPF record, as this can be a simple fix for complex-looking issues.
- Risk aversion: Marketers are generally hesitant to make changes to DNS records without explicit confirmation from IT or their email service provider, fearing email delivery disruption.
- Seeking clarity: There's a strong desire to understand if one platform's sending infrastructure has superseded another's, especially post-acquisition.
Key considerations
- Internal communication: Establish clear communication channels between marketing, IT, and external partners (like agencies managing Salesforce) to ensure everyone is aware of the email sending landscape.
- Avoid hasty changes: Never remove SPF entries without confirming they are no longer in use, as this can lead to severe deliverability issues. Consult what happens when your domain is on a blocklist if misconfiguration leads to problems.
- Leverage documentation: Refer to official Salesforce documentation and guides (e.g., Salesforce Ben) for best practices on configuring SPF for Pardot and Marketing Cloud.
- Understand authentication: Familiarize yourself with the basics of SPF, DKIM, and DMARC to better understand the technical requirements for email authentication and how it impacts email deliverability.
Marketer view
Email marketer from Email Geeks notes that their IT team discovered both Pardot and ExactTarget (with a typo) in their SPF record, causing them to wonder if both are still in use or if one superseded the other for their marketing partner.
Marketer view
Email marketer from Email Geeks states that they're awaiting clarification from their marketing partner regarding the SPF entries and emphasizes they will not make any changes themselves until they receive confirmation.
What the experts say
Email deliverability experts highlight that while Pardot and ExactTarget (Marketing Cloud) are both Salesforce products, they originated as separate entities and sometimes utilize different sending IP ranges. This historical distinction means it's not unusual to see both referenced in an SPF record. Experts caution against arbitrary removal of SPF entries and stress the importance of verifying actual usage and ensuring compliance with SPF's technical limitations, like the 10-DNS-lookup rule, to prevent authentication failures and subsequent deliverability issues.
Key opinions
- Separate acquisitions: Experts confirm that ExactTarget and Pardot were distinct companies acquired by Salesforce, maintaining separate, though integrated, functionalities and sending pathways.
- Distinct IPs: These platforms don't always share the same sending IPs, justifying their separate inclusions in SPF records if both are actively used.
- Pardot's reliance: Pardot often sends emails using Marketing Cloud (ExactTarget) IPs, meaning an SFMC SPF include may implicitly cover some Pardot sending.
- Spoofing risk: Improper SPF configuration or removal can leave a domain vulnerable to spoofing. This is particularly relevant when comparing to broader platforms like O365, which can sometimes have less stringent default SPF policies if not carefully managed.
Key considerations
- Avoid removal without verification: Never remove SPF records (or parts of them) without confirming with your marketing and Salesforce teams that the associated sending service is no longer in use. Incorrect changes can lead to emails failing authentication.
- Address typos immediately: Ensure all domains within your SPF record are spelled correctly and are legitimate. Typographical errors, such as exacttartget.com, can cause SPF validation failures.
- Monitor SPF lookups: Be mindful of the 10-DNS-lookup limit for SPF records. Too many include mechanisms can lead to SPF TempError results.
- Implement DMARC: Beyond SPF, implementing DMARC provides a comprehensive authentication strategy, allowing you to monitor email authentication results and better understand email flow and potential issues.
Expert view
Expert from Email Geeks notes the difficulty in providing a definitive answer to why both Pardot and ExactTarget might be present without more context, but immediately identifies that the typo 'exacttartget.com' is not a registered domain and can be safely removed.
Expert view
Expert from Email Geeks confirms a typographical error in the original post regarding 'exacttartget.com' and states that the correct domain 'exacttarget.com' is indeed very much active and relevant for Salesforce sending.
What the documentation says
Official documentation and best practice guides from Salesforce and other authoritative sources consistently emphasize that a domain should have only one SPF record. When using multiple Salesforce products like Pardot and Marketing Cloud, the recommended approach is to integrate their respective SPF mechanisms into this single record using 'include' statements. This ensures that all legitimate sending IPs are authorized, maintaining email authentication and deliverability, while adhering to the SPF specification's limits.
Key findings
- One SPF record: Standard documentation confirms that only one SPF record is permitted per domain. Multiple records will cause authentication failures.
- Consolidated authentication: For platforms like Pardot and Marketing Cloud, their SPF requirements should be combined into your single SPF record, typically by adding their include mechanisms.
- Importance of authentication: SPF, along with DKIM and DMARC, forms the backbone of email authentication, crucial for preventing spoofing and ensuring inbox placement.
- DNS lookup limits: Documentation often highlights the SPF 10-lookup limit, a critical factor when adding multiple include mechanisms.
Key considerations
- Refer to official guides: Always consult the latest authentication setup guides from Salesforce (e.g., Trailhead, Salesforce Ben) for Pardot and Marketing Cloud to ensure correct SPF syntax and included domains.
- Regular validation: After any updates to your SPF record, use an SPF validation tool to check for errors, including syntax issues and exceeding the DNS lookup limit.
- Subdomain strategy: For complex setups, consider using subdomains for different email sending purposes, as each subdomain can have its own SPF record.
- Consolidate if possible: If a platform's sending is now covered by another (e.g., Pardot using Marketing Cloud IPs), it might be possible to streamline your SPF record, but this must be confirmed by Salesforce documentation or support.
Technical article
Salesforce Trailblazer Community documentation states that there can only be one SPF record per domain, emphasizing that multiple sending systems must be set up within this single record, typically through the use of 'include' mechanisms.
Technical article
Salesforce Ben documentation outlines that as an email sender, it is a requirement to add appropriate SPF records in your DNS to grant permission to Pardot or Salesforce (Marketing Cloud) to send emails using your organization's domain.
Related resources
5 resources
Related pages
Where should SPF, DKIM, and DMARC records be placed for email authentication?
How do SPF, DKIM, DMARC, and dedicated IPs affect email deliverability when using a third-party ESP?
How to troubleshoot SPF authentication issues with multiple ESPs, subdomains, and CNAMEs?
How to set up email authentication for multiple ESPs on the same sending domain?
What are the risks of using the same sending domain on multiple email platforms and IPs?
Why does SPF pass in headers but not Google Postmaster Tools, and what are domain alignment best practices?
How do broken SPF records, like those with too many DNS lookups or exceeding size limits, affect email deliverability and authentication?
A simple guide to DMARC, SPF, and DKIM
Why your emails fail at Microsoft: the hidden SPF DNS timeout
Demystifying the SPF TempError in your DMARC reports
