Summary
Experts, marketers, and documentation all converge on the recommendation to avoid directly including ESP SPF records on corporate domains. There's a consensus that incorrect SPF advice from ESPs is common and that the `include:` mechanism presents several risks. Key concerns include the hard limit of 10 DNS lookups in SPF records (potentially causing SPF failures), the security implications of relying on ESP infrastructure, the maintenance overhead of updating records when switching ESPs, and the loss of control over authentication policies impacting DMARC compliance. The best practice is to use subdomains to isolate sender reputation, properly handle bounce addresses, and segregate email streams (transactional vs. marketing). Consider SPF flattening as a resolution to DNS lookups if absolutely necessary. Ensuring Reverse DNS matches, and properly reviewing the TXT record limit are also key considerations.
Key findings
- Incorrect SPF Advice: ESPs frequently provide incorrect SPF recommendations for including ESP records in root domains.
- DNS Lookup Limit Risks: Using `include:` can quickly exhaust the 10 DNS lookup limit, causing SPF failures and impacting deliverability.
- Security Risks: Depending on an ESP's security poses a risk; compromised ESP infrastructure impacts domain reputation.
- Maintenance Overhead: Switching ESPs requires updating SPF records, creating administrative burden.
- Control and DMARC: ESPs impact organizational control over authentication and DMARC.
- 5321/5322 Handling: Corporate domains should not be in bounce addresses (5321.from). A subdomain pointing to the ESP should have the SPF record.
- Reverse DNS: Having a Reverse DNS that matches the sending domain for best deliverability is key.
- TXT Record Limits: RFC's indicate that the maximum length of a txt record is 255 characters. To avoid problems with older systems it is best to keep the SPF record under this limit.
Key considerations
- Isolate Email Streams: Segregate email streams through subdomains to manage deliverability and reputation independently.
- Weigh risks: Thoroughly weigh risks before proceeding with any configuration.
- Assess Existing Records: If SPF for sending domain (5322.from) exists without rejections, changing might be unnecessary.
- Optimize with SPF Flattening: Consider SPF flattening to reduce DNS lookups, though this adds complexity.
- Bounce Handling: Ensure correct use of SPF to support bounce handling (5321 address).
What email marketers say
12 marketer opinions
Including ESP-provided SPF records directly on corporate domains is generally discouraged due to potential deliverability, security, and maintenance issues. While some ESP documentation still recommends this approach, it's often safer to use subdomains to isolate reputation, avoid DNS lookup limits, and maintain control over authentication policies. Using subdomains enables easier ESP switching, reduces the risk of shared ESP infrastructure problems affecting the main domain, and simplifies email stream management.
Key opinions
- Deliverability Impact: Including an ESP's SPF record can negatively impact deliverability if the ESP experiences spam or blacklisting issues, or if the SPF record is misconfigured, leading to SPF validation failures.
- DNS Lookup Limits: Using the `include` mechanism can quickly exhaust the SPF DNS lookup limit of 10, potentially causing SPF failures.
- Security Risks: Blindly including an ESP's SPF record can pose a security risk if the ESP's infrastructure is compromised, potentially affecting the domain's reputation.
- Maintenance Headaches: Direct inclusion creates maintenance overhead, requiring updates to the SPF record when switching ESPs to avoid deliverability problems.
- Subdomain Isolation: Subdomains are a safer approach for reputation isolation, offering a degree of separation and control.
- DMARC Compliance: Managing SPF directly on the main domain enables consistent authentication policies across all email streams, improving DMARC compliance.
Key considerations
- Subdomain Delegation: Consider delegating control of SPF records to subdomains for email sending, providing the ESP more control and reducing the risk to the primary domain.
- SPF Record Length: Be aware of SPF record lengths and the potential need for SPF flattening to stay within DNS limits.
- Proactive Reputation Management: Implement proactive reputation management practices to monitor the ESP's and the sending domain's reputation, addressing any issues promptly.
- Transactional vs. Marketing segregation: Segregate your transactional vs marketing email streams into different subdomains
- Review Documentation: Carefully review and evaluate any SPF configurations and recommendations
Marketer view
Email marketer from SparkPost answers that blindly including ESP SPF records can pose a security risk. If the ESP's infrastructure is compromised, your domain's reputation could be affected. Using a subdomain limits the blast radius and provides a degree of isolation.
14 Jul 2022 - SparkPost
Marketer view
Email marketer from Mailjet shares that including an ESP's SPF record directly into your corporate domain can create future maintenance headaches. If you switch ESPs, you must remember to update your SPF record to avoid deliverability issues. It's better to use a dedicated subdomain for email sending and delegate SPF control to the ESP.
13 Feb 2025 - Mailjet
What the experts say
7 expert opinions
Experts generally advise against directly including ESP's SPF records into corporate domains. Incorrect SPF advice is common. The primary concern revolves around potential DNS lookup limits when using `include` mechanisms. For proper bounce handling, ESP subdomains should be used with SPF records instead of corporate domains. For deliverability, it is also best to ensure a Reverse DNS match and delegate DNS Control. If 5322.from (sending domain) SPF records exist and no rejections are occurring, changes aren't always necessary. Keeping email streams separate, through subdomains, is also deemed as beneficial for deliverability.
Key opinions
- Incorrect SPF Advice: ESP support sites often provide incorrect SPF recommendations, specifically advising customers to add include statements to their corporate domains, which is wrong.
- DNS Lookup Limits: Using the include mechanism in SPF records can quickly reach the DNS lookup limit, leading to potential deliverability issues.
- Bounce Address Handling: The corporate domain should not be in the bounce address. A subdomain pointing to the ESP should be used, and that subdomain should have the SPF record, not the corporate domain.
- Reverse DNS Mismatch: Including another server's SPF record prevents a reverse DNS match to the sending domain, negatively impacting deliverability.
- Subdomain Delegation: Delegating DNS control to subdomains and use of these for email is advisable to maintain separation and control.
- TXT Record Limits: Ensuring the SPF records are kept below TXT record limits is vital to ensure backwards compatibility and prevent future issues.
Key considerations
- Assess Existing Records: Before making changes, determine if existing SPF records for the sending domain are causing issues. If not, adjustments may be unnecessary.
- Implement Subdomains: Consider segregating email streams using dedicated subdomains and managing SPF records separately.
- Maintain reverse DNS Alignment: Where possible ensure you maintain Reverse DNS aligment with sending domains.
- Evaluate SPF set-up: Check that the record complies with current best practices.
Expert view
Expert from Word to the Wise highlights the RFC's indicate that the maximum length of a txt record is 255 characters. To avoid problems with older systems it is best to keep the SPF record under this limit.
29 Jan 2023 - Word to the Wise
Expert view
Expert from Email Geeks expresses concern over ESP support sites providing incorrect SPF recommendations, specifically advising customers to add `include:spf.esp.example` to their corporate domain. She argues this is wrong.
7 Jul 2023 - Email Geeks
What the documentation says
5 technical articles
Technical documentation consistently advises against directly including ESP SPF records on corporate domains due to the hard limit of 10 DNS lookups within SPF records. Overuse of `include:` mechanisms can quickly exceed this limit, resulting in `permerror` status and SPF failures, leading to deliverability issues, potential spam marking, or outright rejection of emails. Additionally, using includes can reduce organizational control over SPF records, making it harder to enforce consistent authentication policies and maintain DMARC compliance. Includes are also susceptible to changes and DNS overhead at the referenced domain which can lead to future DNS lookup limit issues.
Key findings
- DNS Lookup Limit: SPF has a hard limit of 10 DNS lookups. `include:` mechanisms contribute to this limit and can easily cause it to be exceeded.
- SPF Failure: Exceeding the DNS lookup limit results in a `permerror` status, leading to SPF failures. Incorrect syntax can also cause SPF failure
- Deliverability Impact: SPF failures can lead to emails being marked as spam, rejected, or experiencing deliverability issues.
- Control and Compliance: Direct ESP includes reduce organizational control over SPF records, hindering consistent authentication policies and DMARC compliance.
- SPF Record Changes: `include` can be subject to changes at the reference domain which can cause unexected DNS overhead.
Key considerations
- Optimize SPF Records: Avoid unnecessary `include:` statements, especially generic ESP includes on the primary domain, to stay within the DNS lookup limit.
- Manage SPF records: Careful management of SPF records and use of include records is essential.
- Track SPF usage: Regularly review and monitor the number of DNS lookups in SPF records.
- Consider SPF Flattening: If including a ESP is a neccessity, consider a process such as SPF Flattening to avoid issues.
Technical article
Documentation from DMARC.org details that organizations should maintain control over their domain's SPF records. Giving ESPs direct control through `include:` mechanisms can make it difficult to enforce consistent authentication policies across all email streams, impacting DMARC compliance.
1 Mar 2022 - DMARC.org
Technical article
Documentation from Cloudflare details that `include:` mechanisms are susceptible to changes at the referenced domain. It can add management and DNS lookup overhead, and may lead to DNS lookup limits being reached.
6 Nov 2021 - Cloudflare
Do small email senders need their own SPF/DKIM records or can they rely on their ESP?
How can I improve SPF alignment and email deliverability when using Hubspot?
How can I optimize my SPF record to stay within the lookup limit when using multiple email sending services?
How do I properly set up SPF and DKIM records for email marketing, including handling multiple SPF records, IP ranges, bounce capturing, and Google Postmaster Tools verification?
How do I set up an SPF record when using multiple email sending services?
