Why should ESP SPF include recommendations be avoided on corporate domains?

Key findings

• SPF lookup limit: Each include mechanism in an SPF record counts as a DNS lookup. SPF records have a strict limit of ten DNS lookups. Exceeding this limit results in a PermError, causing legitimate emails to fail SPF authentication and potentially be rejected or sent to spam.
• Return-path domain: SPF primarily authenticates the 5321.from address, also known as the Return-Path or bounce address. When using a third-party ESP, this address usually points to a subdomain controlled by the ESP for proper bounce handling.
• Corporate vs. sending domain: Your corporate domain (the 5322.from address) should ideally not have its SPF record bloated with numerous ESP includes. Instead, the SPF record should be on the subdomain used for the Return-Path, which the ESP manages.
• Mailchimp's approach: Some ESPs, like Mailchimp, have adopted best practices by removing the need for customers to add their SPF includes to their corporate domain, as the Return-Path is already handled by an ESP-controlled subdomain.

Key considerations

• DNS complexity: Incorrect SPF setup can lead to widespread issues beyond deliverability, impacting other DNS records (e.g., CNAME conflicts for websites or other email services) on the main domain.
• Multiple ESPs: Organizations often use multiple ESPs for different sending purposes (e.g., transactional, marketing). Adding an include for each to the corporate domain quickly hits the 10-lookup limit, causing deliverability problems across all services. Learn how to troubleshoot SPF authentication issues.
• Bounce handling: Proper bounce handling relies on the ESP controlling the Return-Path domain. If the corporate domain is used for the Return-Path and its SPF record is misconfigured or incomplete for the ESP's IPs, bounces might not be processed correctly.
• Deliverability impact: While some legacy filters might check the 5322.from domain's SPF, the primary check is on the 5321.from. A misconfigured SPF record on the 5322.from can lead to rejections if DMARC is in place. For more, see our article on the impact of the From domain record on SPF.

Key opinions

• Frustration with ESP advice: Many marketers express frustration that ESP support sites provide SPF recommendations that are considered incorrect or outdated, particularly regarding the inclusion of ESP SPF records on primary corporate domains.
• Corporate policy to refuse broad IP includes: Some corporate policies explicitly reject ESP requests to include large IP ranges in their main SPF records to maintain tighter control and avoid potential issues.
• Misunderstanding DNS implications: Marketers, who may not be DNS or email experts, often follow ESP instructions without fully understanding the implications of CNAMEs or other DNS record changes, which can lead to conflicts with other services like websites or corporate email.
• DMARC enforcement by ESPs: Some ESPs enforce DMARC setup, sometimes with a p=reject policy, without adequate reporting mechanisms or explanations of potential privacy issues with RUA addresses. Understand why ESPs enforce DMARC.

Key considerations

• Importance of proper SPF setup: Effective SPF records are vital for preventing spam, spoofing, and phishing attacks, directly impacting sender reputation and overall deliverability. Learn the best practices for email domain authentication.
• Role of subdomains: Utilizing a subdomain for marketing email sending, with its own dedicated SPF record managed by the ESP, is generally considered a safer and more manageable approach than modifying the root corporate domain's SPF. This ensures that the email platform can adequately handle things like bounces and feedback loops.
• Maintaining a healthy sending reputation: A strong sending reputation is built on trust and proper email authentication. Misconfiguring SPF can negatively impact this reputation. For more details, see this guide to SPF records.
• Simplified authentication processes: Marketers benefit greatly from ESPs that streamline authentication by handling the Return-Path SPF on their own subdomains, reducing the need for clients to manually adjust complex DNS records on their corporate domains.

Key opinions

• Misleading ESP documentation: Experts commonly encounter ESP knowledge base articles that offer incorrect SPF recommendations, particularly advising clients to add includes to their corporate domain rather than a dedicated sending subdomain.
• Focus on 5321.from: SPF is designed to verify the 5321.from (bounce) address. For optimal bounce handling, this should be an ESP-specific subdomain, which then carries the SPF record, not the corporate 5322.from domain. This is critical for email service provider best practices.
• DNS lookup limits: While adding an occasional include might not immediately break SPF, it increases DNS overhead and brings the SPF record closer to the 10-lookup limit, which leads to PermErrorfailures.
• DMARC deployment risks: Implementing DMARC with a p=reject policy prematurely, without thorough testing and reporting, can lead to legitimate emails being blocked, even for large, well-known brands.

Key considerations

• Legacy DNS practices: Some DNS providers still permit the creation of deprecated SPF record types (e.g., SPF type RR instead of TXT), which can cause authentication failures and require manual checks.
• Importance of DMARC reporting: ESPs that advise DMARC implementation should also explain the importance of RUA (reporting URI for aggregate reports) and RUF (reporting URI for forensic reports) addresses for monitoring and understanding email authentication results.
• Subdomain delegation: The ideal scenario is delegating a subdomain's name servers to the ESP, giving them full control over the DNS records for that sending domain. While not common in the non-enterprise space, it simplifies management for the client. For more, see the Word to the Wise blog.
• Avoiding unnecessary changes: If a client's 5322.from domain SPF record is not causing rejections, experts recommend a don't fix a problem that doesn't exist approach. This minimizes the risk of introducing new issues. Learn about common SPF misconceptions.

Key findings

• Single SPF record rule: RFC 7208 mandates that a domain should publish only one SPF record (a TXT record beginning with v=spf1), making concatenation of multiple SPF records into one essential. Read more in our simple guide to DMARC, SPF, and DKIM.
• 10-lookup limit: The SPF specification strictly limits the number of DNS lookups during SPF evaluation to ten. Exceeding this limit results in a PermError, causing authentication to fail.
• SPF and Return-Path: SPF's primary function is to verify the MailFrom address (RFC 5321.From), also known as the Return-Path. This is distinct from the visible Header From address (RFC 5322.From).
• DMARC alignment: For DMARC to pass, either SPF or DKIM must align with the Header From domain. This often means having a DKIM signature with the corporate domain, or setting up a subdomain for the Return-Path that aligns with the Header From for SPF alignment.

Key considerations

• Documentation clarity: While technical documentation outlines correct usage, simplified guides from ESPs can often miss nuances, leading to misconfigurations (e.g., advising include:amazonses.com directly on a root domain).
• SPF record limitations: The RFC does not specify a maximum length for an SPF record, but practical limitations exist due to DNS packet size and resolver capabilities, which can lead to issues like DNS timeouts.
• Evolution of authentication: Email authentication has evolved from earlier protocols like Sender ID and DomainKeys. While some older systems may still refer to them, current best practices focus on SPF, DKIM, and DMARC. For a general understanding, refer to what Sender Policy Framework means.
• Impact of alignment: Proper alignment between the Return-Path and Header From domains, often achieved via DKIM or a CNAME for the Return-Path, is increasingly important for maximizing deliverability, especially with stringent DMARC policies at receiving mail servers.