When is SPF flattening needed and how to validate SPF records?

Key findings

• DNS lookup limit: SPF records are restricted to a maximum of 10 DNS lookups. Exceeding this limit causes validation failures.
• Character limit: SPF records also have a 255-character string limit, which can be reached even without hitting the lookup limit if many IP addresses are listed.
• Purpose of flattening: SPF flattening aims to reduce the number of DNS lookups by replacing domain names with their resolved IP addresses directly in the SPF record.
• Dynamic vs. manual: Flattening can be done manually, which requires constant updates as IP addresses change, or dynamically using a service that monitors and automatically updates the record.

Key considerations

• Audit senders: Before flattening, identify all legitimate sending sources for your domain and ensure their SPF mechanisms are necessary for your primary domain's SPF record. Often, services send from their own return paths, not yours.
• Subdomain strategy: Consider using subdomains for different email services. Each subdomain can have its own SPF record, which helps manage DNS lookups on the apex domain.
• Risk of manual flattening: Manually flattening SPF records can lead to outdated IP addresses if service providers change their sending infrastructure, potentially causing deliverability issues. This is because IP ranges are not static and can change.
• Validation frequency: Regularly validate your SPF record (and other DNS records) using an SPF lookup tool to catch errors early and prevent email delivery problems.

Key opinions

• Need for automation: Many marketers seek dynamic SPF flattening services to avoid manual updates, especially when managing multiple email platforms across their company.
• Cost concerns: There's an interest in understanding the varying costs and value propositions of different SPF flattening solutions available in the market.
• Complexity of includes: Specific third-party services, like Freshdesk, can add a significant number of lookups (e.g., 7 from one include), making it difficult to stay within the 10-lookup limit.
• Auditing necessity: Marketers recognize the need to thoroughly audit each included domain in their SPF record to identify unnecessary lookups.

Key considerations

• Return path importance: Marketers should focus on the return path domain for SPF records, as services not sending from the apex domain don't require an SPF include there.
• DMARC report utility: Utilizing DMARC reports can help quickly validate the return path of each sending domain and identify unnecessary SPF records.
• Bundled solutions: Dynamic SPF features are often bundled with DMARC monitoring services, offering a comprehensive solution for email authentication management.
• Signature services: Be cautious with email signature services, as some might forward mail in a way that requires an SPF record on your domain, adding unexpected lookups.

Key opinions

• Subdomain management: If SPF is configured correctly, extensive flattening may not be necessary; instead, focus on better subdomain management to distribute lookups.
• Return path validation: SPF records are only needed for the return path domain, not for every domain mentioned in an email's headers. Verifying the return path of each service is critical.
• Unnecessary inclusions: Many includes in an SPF record may be redundant if the services are not actually sending from your primary domain's return path.
• DMARC reports for auditing: DMARC aggregate reports provide visibility into sending sources and their return paths, making it easier to identify which SPF records are truly needed.

Key considerations

• Deep audit of services: Conduct a thorough audit of all sending services to verify if they genuinely require an SPF record on your apex domain or if they use their own return paths.
• Dynamic SPF pros and cons: While dynamic SPF can solve lookup limits, it requires trusting a third-party service to maintain the accuracy of your SPF record, as manual flattening shifts the maintenance burden.
• Hidden forwarders: Be aware that some email signature or content services might forward emails, implicitly requiring an SPF record for your domain if they modify the return path.
• Impact on deliverability: An SPF record exceeding the DNS lookup limit will fail authentication, leading to messages being rejected, quarantined, or sent to spam folders.

Key findings

• Strict lookup limit: RFC 7208 (the SPF specification) clearly defines that SPF processing SHOULD NOT perform more than 10 DNS lookups that resolve SPF mechanisms.
• Lookup-triggering mechanisms: Mechanisms like a, mx, ptr, and include (or redirect) each count as a DNS lookup.
• Non-lookup mechanisms: Mechanisms like ip4, ip6, and exists do not count towards the 10-lookup limit.
• Single TXT record: RFCs advise that a domain should publish only one SPF TXT record. Multiple SPF records for the same domain can lead to PermError results.

Key considerations

• DNS query errors: Failing to adhere to lookup limits can result in PermError or TempError messages during SPF validation.
• Dynamic SPF solutions: Documentation often implies that while manual flattening is possible, dynamic SPF services are better equipped to handle the constantly changing IP addresses of included domains.
• SPF record structure: Ensure your SPF record starts with v=spf1 and ends with an all mechanism (e.g., ~all, -all). This is fundamental for proper SPF syntax.
• Vendor specific changes: Some vendors like Freshdesk (as noted in discussions) may change their sending practices, moving to their own return paths, which makes previous SPF includes obsolete. Regular review of vendor documentation is necessary.