Why are ESPs recommending incorrect SPF record configurations?

Key findings

• Misapplication of SPF: Many ESPs incorrectly advise customers to add SPF records for the RFC 5322.from (From header) domain, even though SPF primarily authenticates the RFC 5321.from (return-path).
• DNS lookup limits: This misconfiguration frequently pushes domains over the RFC 7208 specified limit of 10 DNS lookups, leading to SPF failures.
• Impact on deliverability: Exceeding lookup limits can cause emails to be rejected or land in spam folders, affecting overall deliverability.
• Outdated documentation: A significant cause is often outdated or technically incorrect support documentation from ESPs and hosting providers.
• Complexity for users: The incorrect advice makes SPF configuration unnecessarily complex for end-users, especially those using multiple email services, impacting their ability to maintain proper email authentication.

Key considerations

• Review existing SPF records: Regularly check your SPF record for accuracy and to ensure it does not exceed the 10 DNS lookup limit, which can lead to SPF failures.
• Understand SPF mechanism: Differentiate between the RFC 5321 (envelope sender) and RFC 5322 (header from) domains, as SPF validates the former.
• Prioritize legitimate senders: Only include legitimate sending sources in your SPF record to maintain a lean and effective configuration.
• Consult expert resources: Seek guidance from experienced deliverability professionals or authoritative documentation to validate SPF configurations.
• Advocate for better documentation: Encourage ESPs to update their technical documentation to reflect correct SPF implementation best practices.

Key opinions

• Unnecessary complexity: Many marketers find it tiring to repeatedly explain that SPF is often not needed in the organizational domain for ESP-handled sends, particularly when the ESP uses its own return-path.
• Risk of over-inclusion: Adding unnecessary includes for ESPs can clutter the SPF record, pushing it past the 10 DNS lookup limit, as detailed in common SPF issues.
• Impact on smaller businesses: Small businesses, focused on their core operations, rely heavily on vendor advice, making incorrect guidance particularly problematic for their email deliverability.
• Desire for simplicity: Some ESPs may prioritize ease of setup over technical accuracy, leading to generalized, potentially incorrect instructions.
• Propagation of misinformation: Once incorrect information is published, it can spread through other blog posts and documentation, becoming "conventional wisdom" even if it's flawed.

Key considerations

• Verify ESP instructions: Always cross-reference ESP SPF instructions with general email authentication best practices.
• Beware of DNS overhead: Be vigilant about the total number of DNS lookups your SPF record requires to prevent validation failures.
• Educate clients and teams: Proactively explain the nuances of SPF, especially the distinction between the 5321.from and 5322.from domains.
• Consider subdomain strategy: For external sending, consider using subdomains to manage SPF records independently and avoid conflicts with the organizational domain.
• Approach DMARC cautiously: Be wary of advice to rush to an enforcing DMARC policy without proper monitoring and understanding of your email flows.

Key opinions

• Fundamental technical error: Experts are dismayed by the pervasive incorrect SPF guidance, particularly regarding not adding SPF records for the RFC 5322.from (From header) domain.
• Lookup limit violations: A major concern is how this advice causes companies to exceed the 10 DNS lookup limit, leading to email rejection or misdelivery and issues like SPF alignment failures.
• Flawed documentation: Experts point to poor or incorrect technical support pages at ESPs as a primary source of these issues, often unchecked by delivery specialists.
• Security risks: Incorrect SPF configurations, especially those broadly allowing domains, pose security risks by potentially authorizing unauthorized senders.
• Disregard for best practices: The continued recommendation of flawed SPF setups suggests a lack of attention to current email authentication best practices within some ESPs.

Key considerations

• Adhere to RFC standards: Always align SPF configurations with RFC 7208 to avoid common pitfalls like exceeding lookup limits or SPF resolution failures.
• Strictly manage include statements: Be judicious with include mechanisms to prevent DNS overhead and maintain a valid SPF record.
• Differentiate SPF domains: Emphasize that SPF authenticates the RFC 5321.from (return-path), not necessarily the RFC 5322.from (header from), which ESPs often handle via subdomains.
• Prioritize accurate documentation: For ESPs, investing in technically sound documentation is crucial for customer success and overall email ecosystem health.
• Understand ESP sending practices: Recognize that some ESPs use their own domains for SPF, meaning client domains don't need additional SPF records, a point often missed in documentation, such as with Mailchimp's SPF recommendations.

Key findings

• Misguided include directives: Many documents instruct users to add includes for the ESP's domain directly into the primary organizational domain's SPF record, even when the ESP is handling the return-path on a subdomain.
• Alternative IP address suggestions: Some documentation offers adding a specific IP address as an alternative to an include, noting that IPs don't count towards DNS lookups, which, while true, still reflects a flawed understanding of when an include is necessary.
• Ignoring return-path: The documentation often overlooks the critical distinction between the RFC 5321.from (return-path, authenticated by SPF) and RFC 5322.from (header from), simplifying setup to the user's detriment, as discussed in the impact of from domain records.
• Implications for multi-vendor setups: For domains using multiple email senders (e.g., Google Workspace, an ESP, a CRM), following each vendor's potentially incorrect advice quickly leads to exceeding the 10 DNS lookup limit, causing SPF authentication issues.
• Confusing "SPF record" placement: Documents frequently imply that the SPF record must always be on the main organizational domain, even when a subdomain is used for sending through the ESP.

Key considerations

• Critically evaluate instructions: Always question and verify SPF setup instructions, especially if they seem overly simplistic or direct you to add includes that appear unnecessary.
• Prioritize DNS lookup count: Be highly aware of the 10 DNS lookup limit; if an include pushes you over, seek clarification or an alternative, as highlighted in Mailjet's authentication guide.
• Understand ESP domain usage: Determine if the ESP uses your domain for the RFC 5321.from (envelope sender) or their own subdomain. If it's their subdomain, an SPF record on your primary domain for that ESP might be redundant or incorrect.
• Push for accurate documentation: Provide feedback to ESPs and hosting providers to encourage them to correct their SPF configuration guides.
• Security implications: Recognize that broadly authorizing IP ranges or domains via SPF includes can have security implications, allowing unauthorized entities to potentially spoof your domain.