Why do some ESPs require unnecessary SPF includes for DKIM, and what are the dangers of this practice?
Matthew Whittaker
Co-founder & CTO, Suped
Published 13 Jul 2025
Updated 16 Aug 2025
8 min read
Occasionally, I encounter scenarios where an Email Service Provider (ESP) insists that a client adds an SPF include to their root domain for DKIM authentication. This practice is often unnecessary and can introduce significant risks, potentially leading to email deliverability issues. It's a common misconception that SPF and DKIM are intrinsically linked in this way.
My goal is to clarify why this requirement is misguided and highlight the potential dangers it poses to a sender's email program. Understanding the independent roles of SPF and DKIM is crucial for maintaining a healthy email sending reputation and ensuring messages reach the inbox.
Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are two distinct, yet complementary, email authentication protocols. They serve different purposes in verifying email origin and integrity. SPF focuses on validating the sending IP address against a list of authorized senders published in the domain's DNS record. It checks the Mail From address, also known as the envelope sender. If the sending IP is not authorized, the email may be flagged as suspicious or rejected.
DKIM, on the other hand, provides a cryptographic signature that verifies the content of the email has not been tampered with in transit and confirms the sender's identity by checking the From (header) address. This signature is added to the email header and can be validated by the recipient server using a public key published in the sender's DNS. DKIM's primary goal is to ensure message integrity and authorship, making it harder for phishers to spoof a domain.
The key distinction is that DKIM operates independently of SPF's IP-based authentication. A valid DKIM signature does not rely on an SPF record or any SPF mechanism. While both are crucial for a strong email authentication posture, especially when combined with DMARC, forcing an SPF include for DKIM is technically unnecessary.
Understanding the protocols
SPF and DKIM operate on different principles and validate different aspects of an email. While they both contribute to email security and deliverability, they are not dependent on each other for their core functionality. Proper email authentication requires both, but not in a way where one must include the other.
Reasons for unnecessary SPF include requests
The reasons behind ESPs making these unnecessary SPF include requests are varied, but often point to outdated practices or a misunderstanding of how email authentication truly works. In some cases, it's simply a matter of legacy documentation that hasn't been updated to reflect current standards. There was a time when Microsoft properties, for instance, had peculiar ways of handling SPF lookups that might have led to such recommendations, though those issues have since been resolved.
Another, more cynical, possibility I've heard is that some ESPs use SPF records as a crude way to measure their market share or presence. By requiring clients to include their SPF records, they can then analyze public DNS data to gauge their adoption. While this might serve an internal business metric, it prioritizes the ESP's data collection over proper email deliverability and security for their clients, which is an unacceptable trade-off.
Ultimately, many of these misguided recommendations stem from a general lack of deep technical understanding within some ESP support or onboarding teams. While I hesitate to label an ESP as technically incompetent, it's clear that some internal training materials are flawed, leading to incorrect advice being disseminated to clients. This can lead to clients being told their emails were delivered, when in reality, they were actively rejected for spam. This misreporting further obscures the underlying issues.
Incorrect ESP assumptions
Some ESPs assume that to ensure proper DMARC alignment and prevent spoofing, their IP addresses (or included domains) must be listed in the client's SPF record, even for mail signed with the client's DKIM key. They might believe this simplifies their internal processes or provides an extra layer of security.
Technical reality
For DKIM authentication, the ESP typically provides a CNAME record that points to their DKIM key. This allows the ESP to sign emails on behalf of the client's domain. SPF is entirely separate. As long as the DKIM signature is valid and aligns with the From domain, SPF pass is not strictly necessary for DMARC to pass, though having both is ideal.
The hidden risks of over-including SPF records
Adding unnecessary SPF includes, particularly for an ESP that is primarily handling DKIM signing, introduces significant risks. The most critical danger is exceeding the 10 DNS lookup limit for SPF records. Each include, a, or mx mechanism in your SPF record counts towards this limit. Once exceeded, receiving mail servers will return a PermError, causing all SPF checks to fail, regardless of whether the sending IP is valid.
An SPF PermError can severely impact your email deliverability. While a valid DKIM signature might still allow some emails to pass DMARC, many receiving servers, especially those with stricter policies, will outright reject or quarantine emails that fail SPF due to a PermError. This means legitimate emails could end up in spam folders or not delivered at all, leading to lost engagement and missed opportunities. Moreover, recovering from a damaged domain reputation caused by such failures can be a lengthy process.
Another danger lies in the increased complexity of your DNS records. The more includes you have, the harder it becomes to manage and troubleshoot. Each new ESP or service added to your SPF record brings you closer to that 10-lookup limit. Organizations often use multiple third-party services for email, making it easy to unwittingly exceed the limit. This also makes your SPF record more brittle; a change by one of your included services could inadvertently break your SPF authentication.
Example of an SPF record approaching the 10-lookup limitdns
Adding unnecessary include mechanisms to your SPF record can quickly lead you to hit the 10 DNS lookup limit. When this happens, your SPF record will result in a PermError, causing all SPF checks to fail and potentially sending all your legitimate emails straight to spam or outright rejecting them. This is a critical issue that can severely damage your domain reputation.
SPF check outcome
Impact on deliverability
SPF pass
Email authenticated, good for inbox placement, contributes positively to sender reputation. Helps ensure deliverability.
To avoid these pitfalls, the best practice is to understand that DKIM authentication, when managed by an ESP, typically involves publishing a CNAME record that points to the ESP's DKIM key. This method allows the ESP to sign emails on your behalf without any need for an SPF include. If an ESP is pushing for an SPF include solely for DKIM, it's a strong indicator of a fundamental misunderstanding on their part.
I always recommend auditing your existing SPF record regularly. Remove any unnecessary includes, especially those tied to services that are already handled via DKIM. For third-party ESPs, consider setting up sending from a subdomain. This allows you to manage a separate, simpler SPF record for that subdomain, reducing the risk of hitting the 10-lookup limit on your main domain. This strategy is also discussed in depth regarding why ESP SPF recommendations should be avoided on corporate domains.
Finally, ensure your DMARC policy is configured correctly. DMARC relies on either SPF or DKIM to pass authentication and align with the From domain. With proper DKIM setup, you can often achieve DMARC compliance even if SPF encounters issues (e.g., due to forwarding). Implementing a strong DMARC policy safely provides comprehensive protection and invaluable visibility into your email ecosystem.
Views from the trenches
Best practices
Always prioritize DKIM for your primary email authentication, especially when using third-party ESPs.
Regularly audit your SPF record to ensure it does not exceed the 10-DNS lookup limit.
Use a dedicated subdomain for marketing emails sent via ESPs to simplify SPF management for your main domain.
Common pitfalls
Blindly adding ESP SPF includes without understanding their necessity for DKIM.
Exceeding the SPF 10-DNS lookup limit, leading to authentication failures.
Relying on an ESP's 'delivered' reports without verifying actual inbox placement.
Expert tips
If an ESP insists on an unnecessary SPF include, ask for a technical explanation of its purpose for DKIM. If they cannot provide a valid reason, push back or seek alternative solutions.
Consider SPF 'flattening' services if you have many legitimate includes and are nearing the limit, but be aware of their limitations and potential for stale records.
Monitor DMARC aggregate and forensic reports to identify any SPF or DKIM failures and pinpoint their source, which can reveal misconfigurations.
Expert view
Expert from Email Geeks says they had a client whose ESP wouldn't enable custom DKIM signing until an unnecessary SPF include was published in their root domain, a practice that can lead to significant problems.
2022-05-25 - Email Geeks
Expert view
Expert from Email Geeks says they found that some ESPs report emails as 'delivered' even when logs clearly show active rejections for spam, indicating technical incompetence.
2022-05-25 - Email Geeks
Securing your email sending
The practice of some ESPs requiring unnecessary SPF includes for DKIM signing is a clear example of how outdated advice or technical misunderstandings can create significant problems for email senders. It risks pushing domains over the 10-DNS lookup limit, resulting in SPF PermErrors that undermine deliverability and sender reputation. This practice also adds unnecessary complexity to DNS management, making it harder to maintain a clean and effective authentication setup.
As senders, it's vital to be informed and proactive. Understand the distinct roles of SPF and DKIM, and challenge any ESP recommendations that seem illogical or could jeopardize your email program. Focus on implementing DKIM correctly via CNAME records for third-party services, maintain a lean SPF record, and leverage DMARC for comprehensive authentication and reporting. By doing so, you can secure your email sending and ensure your messages consistently reach their intended recipients.
Microsoft properties, for instance, had peculiar ways of handling SPF lookups that might have led to such recommendations, though those issues have since been resolved.
