Why should ESP SPF include recommendations be avoided on corporate domains?
Matthew Whittaker
Co-founder & CTO, Suped
Published 23 Jun 2025
Updated 19 Aug 2025
7 min read
It's a frustratingly common scenario: you're working to configure your email authentication, and your Email Service Provider (ESP) provides clear instructions to add an SPF include statement directly to your corporate domain’s DNS records. While their intentions might be good, this recommendation is often problematic and can lead to significant deliverability issues down the line. I've seen this mistake made countless times, and it stems from a fundamental misunderstanding of how SPF truly works in conjunction with ESPs.
Many ESPs recommend this approach because it seems straightforward, but it overlooks the nuances of email authentication, especially the SPF 10-DNS lookup limit and the distinct roles of different From addresses. This guide will explore why adding ESP SPF include recommendations to your primary corporate domain is generally a practice to avoid and what the correct approach should be for optimal email deliverability and security.
SPF (Sender Policy Framework) is an email authentication method designed to detect spoofing by allowing recipient mail servers to verify that an email claiming to come from a specific domain was indeed sent by an authorized IP address for that domain. It primarily authenticates the RFC5321.From address, also known as the Mail From or Return-Path address. This is often different from the RFC5322.From address, which is the visible From address displayed in email clients.
When you send emails through an ESP, they typically handle bounces and other feedback by setting the Return-Path (RFC5321.From) to a subdomain they control, such as bounces.esp.com or sends.yourdomain.com. In such cases, the SPF record that needs to be configured is for bounces.esp.com or sends.yourdomain.com, not your primary yourdomain.com. This separation allows the ESP to manage bounces and feedback loops effectively, which is essential for maintaining good sender reputation and deliverability.
RFC5321.From (Mail From)
This is the address used for the actual mail transmission, often referred to as the bounce address or Return-Path. SPF checks this domain to verify the sending IP.
RFC5322.From (Header From)
This is the email address that users see in their inbox. While DMARC requires alignment of this domain with SPF or DKIM, SPF itself doesn't directly authenticate it.
Adding an ESP's SPF include to your corporate domain's SPF record is often unnecessary because your corporate domain isn't (or shouldn't be) the RFC5321.From domain when sending via an ESP. The ESP typically handles the RFC5321.From with their own or a delegated subdomain. If the primary corporate domain is used for internal email (e.g., microsoft.com for Microsoft 365), then its SPF record should only reflect those authorized senders.
The dangers of misconfigured SPF records
One of the most critical reasons to avoid adding unnecessary ESP includes to your corporate domain’s SPF record is the 10-DNS lookup limit. SPF records are limited to a maximum of 10 DNS lookups to prevent abuse and ensure efficient processing by mail servers. Each include, a, mx, and ptr mechanism in an SPF record counts towards this limit. If your SPF record exceeds 10 lookups, it results in a PermError, causing receiving mail servers to treat your email as unauthenticated, which can lead to it being marked as spam or rejected outright. You can read more about this on DMARCLY's blog about too many DNS lookups.
Corporate domains often already have several includes for their legitimate internal email systems (e.g., Google Workspace, Microsoft 365), CRM platforms, and transactional email services. Each additional ESP include, particularly if the ESP themselves uses multiple includes, quickly pushes you over this limit. Once you hit that PermError, your legitimate emails, regardless of their content or reputation, face a high risk of landing in the spam folder or being rejected. This undermines your email deliverability and can damage your sender reputation.
Standard SPF setup
This shows how a standard corporate domain SPF looks when properly configured.
Problematic SPF setup (due to ESP recommendations)
Adding ESP includes to a corporate domain can easily exceed the DNS lookup limit, causing SPF to fail and legitimate emails to be rejected. This example assumes an ESP include that itself requires multiple lookups, leading to an immediate PermError.
Example Corporate SPF Record Exceeding 10 LookupsDNS
Beyond the technical limits, these recommendations reflect a lack of precise guidance from ESPs. Many ESPs provide generic SPF advice that doesn't account for the complexity of a corporate email environment, where multiple sending sources are common. As observed by Word to the Wise, this incorrect SPF advice does indeed cause problems. Some ESP knowledge bases are not authored by technical experts, leading to outdated or misinformed instructions. This can be especially frustrating when trying to ensure email compliance and deliverability for an organization. I've even seen Mailchimpremove their SPF include recommendations from their authentication process in the past, which was a step in the right direction, but many others still lag.
Best practices for managing SPF with multiple senders
The optimal way to manage SPF records when using an ESP is to leverage subdomains. Instead of adding the ESP's include to your primary corporate domain, create a dedicated subdomain, such as email.yourdomain.com or mail.yourdomain.com, specifically for sending email through that ESP. This subdomain's SPF record would then include only the ESP's authorized senders, keeping your primary domain's SPF record clean and below the 10-lookup limit.
This approach aligns with the principle that SPF authenticates the Return-Path (RFC5321.From) domain. When you use a subdomain configured with your ESP, the Return-Path will correctly reflect that subdomain, and its dedicated SPF record will pass authentication. This separation is crucial for maintaining robust email authentication practices across your corporate and marketing mail streams.
For DMARC compliance, which requires alignment between the RFC5322.From (Header From) and either the SPF or DKIM domains, you can still use your corporate domain for the Header From address. DMARC will typically align SPF based on the Return-Path domain (your dedicated subdomain) or DKIM based on the signing domain, ensuring your emails pass authentication checks. This strategy keeps your primary domain's SPF lean while allowing you to send branded emails through multiple ESPs without risking SPF PermErrors. Learn more about DMARC, SPF, and DKIM.
Recommended approach
Use subdomains: Create a dedicated subdomain for each ESP (e.g., mail.yourdomain.com) and add the ESP's SPF include to that subdomain's DNS.
Primary domain SPF: Keep your primary corporate domain's SPF record clean, including only necessary internal senders (e.g., Google Workspace, Microsoft 365).
DMARC alignment: Use DMARC to ensure brand alignment by setting up DKIM for your primary domain, which ESPs can sign on your behalf.
It's important to remember that SPF authenticates the Return-Path domain, not necessarily the Header From domain. By separating these concerns, you can maintain compliance with SPF standards, avoid hitting the 10-DNS lookup limit (which causes emails to fail SPF validation), and ensure your emails are delivered as intended. This also provides greater control over your email infrastructure and minimizes potential deliverability issues.
Views from the trenches
Best practices
Always use a subdomain for email sending through an ESP to manage SPF separately.
Ensure your primary corporate domain's SPF record only includes your internal email infrastructure.
Prioritize DMARC implementation for overall email authentication and brand protection.
Regularly review your SPF record for the 10-DNS lookup limit and optimize it.
Common pitfalls
Adding ESP SPF `include` statements directly to your corporate domain.
Exceeding the SPF 10-DNS lookup limit, leading to PermErrors and deliverability issues.
Relying solely on ESP documentation for SPF setup without understanding the underlying mechanics.
Not configuring SPF on the correct (Return-Path) domain, causing validation failures.
Expert tips
Be cautious of DNS providers that still offer deprecated SPF record types.
If your corporate domain's SPF currently includes ESPs and emails are not rejected, prioritize DMARC implementation and monitoring first.
Focus on robust email authentication setup, including SPF, DKIM, and DMARC, as a holistic strategy.
Remember that many ESP knowledge bases are not written by technical email deliverability experts.
Expert view
Expert from Email Geeks says many ESP SPF recommendations are completely wrong; customers should not add include statements to their corporate domain, as this is a widespread issue across many ESPs.
2021-09-29 - Email Geeks
Expert view
Expert from Email Geeks says SPF verifies the RFC5321.From (bounce address) and when using an ESP, the corporate domain should never be in the bounce address. Instead, a subdomain pointing at the ESP should handle bounces and have the SPF text record.
2021-09-29 - Email Geeks
The path to correct SPF implementation
Avoiding ESP SPF include recommendations on your corporate domain is a crucial step toward better email deliverability and maintaining a healthy sender reputation. By understanding the distinction between the RFC5321.From and RFC5322.From addresses and adhering to the SPF 10-DNS lookup limit, you can prevent common pitfalls that lead to emails being blocklisted (or blacklisted) or sent to spam folders.
My recommendation is to always use a dedicated subdomain for your ESPs and correctly configure the SPF for that subdomain. This strategy not only optimizes your email authentication but also provides a more robust and scalable solution for your email sending infrastructure. Prioritizing correct SPF setup, alongside DKIM and DMARC, is fundamental for ensuring your legitimate emails reach their intended recipients.
Microsoft 365), CRM platforms, and transactional email services. Each additional ESP include, particularly if the ESP themselves uses multiple includes, quickly pushes you over this limit. Once you hit that PermError, your legitimate emails, regardless of their content or reputation, face a high risk of landing in the spam folder or being rejected. This undermines your email deliverability and can damage your sender reputation.
Mailchimpremove their SPF include recommendations from their authentication process in the past, which was a step in the right direction, but many others still lag.
Google Workspace, Microsoft 365).
