SPF flattening is the process of resolving the domains referenced in an SPF record—especially each include mechanism, a, mx, or redirect—and replacing them with the underlying IP addresses. Instead of asking a receiving mail server to chase multiple DNS references during SPF authentication, a flattened SPF record presents authorized sending IP addresses more directly inside the DNS TXT record.
This matters because SPF is a core part of email authentication, alongside DKIM and DMARC. When a message arrives, the recipient checks whether the connecting mail server is allowed to send for the domain used in the MAIL FROM identity. The IETF defines SPF behavior in RFC 7208, available here, including how DNS mechanisms are evaluated and why excessive lookups can break SPF validation.
How SPF Flattening Works in Practice
A typical SPF record may authorize Google Workspace, Microsoft 365, SendGrid, Amazon SES, Zoho, Mailchimp, Mandrill, Salesforce, Zendesk, Sendinblue, and other Email service providers. Each vendor’s SPF entry may contain a nested include, and that nested include may reference more DNS TXT record lookups. SPF flattening resolves those nested include chains into IP addresses.
For example, a domain may publish:
v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com ~allAfter SPF flattening, those includes may be converted into a list of IP addresses or CIDR ranges. This reduces dependence on runtime DNS lookups and helps preserve SPF authentication when the DNS lookup limit is close to being exceeded.
Why Flattening Supports DMARC Outcomes
SPF alignment is important for DMARC. A DMARC policy evaluates whether SPF or DKIM aligns with the visible From domain. If SPF authentication fails because of too many lookups, a domain relying heavily on SPF may see reduced SPF pass rate, more SPF failures, and weaker DMARC enforcement. With a quarantine policy or reject policy, those failures can cause receivers to quarantine or reject email.
The SPF 10-DNS-Lookup Limit and How It Causes Delivery Failures
SPF has a strict DNS lookup limit: no more than 10 DNS lookups are allowed during SPF evaluation. The DNS lookup limit applies to mechanisms such as include, a, mx, ptr, exists, and redirect. Once a receiving mail server exceeds 10 DNS lookups, SPF authentication can return a PermError.
The issue is common in modern email infrastructure because organizations use many third-party vendors for bulk marketing email, transactional email, CRM notifications, support systems, billing tools, and internal communications. A single SPF record can become overloaded quickly.
Why 10 DNS Lookups Are Easy to Exceed
The visible SPF record may look simple, but each nested include can expand into additional includes. A domain might include Google Workspace, Microsoft 365, SendGrid, Mailchimp, and Salesforce, but behind those entries are vendor-managed DNS TXT record references. A helpful overview of the mechanics is available in this SPF flattening explanation.
When the total exceeds 10 DNS lookups, the receiving mail server does not keep evaluating indefinitely. Instead, SPF validation may stop with PermError, causing SPF failures even if the sending IP addresses are legitimate.
SPF Bloating and Delivery Risk
SPF bloating happens when organizations keep adding vendors without removing old senders. Onboarding vendors is easy; record maintenance is harder. Over time, unused systems remain in the SPF record, the DNS lookup limit is consumed, and the domain becomes SPF incapable for new senders without cleanup.
This can affect email deliverability across multiple mail streams. For example, bulk marketing email may pass while transactional email fails, or Zendesk notifications may pass while Salesforce alerts fail. The DNS string limit can also become a problem if a DNS TXT record grows too long, requiring careful splitting at the DNS registrar.
Risks of Manual SPF Flattening: Stale IPs, Broken Includes, and Maintenance Gaps
Manual flattening may appear simple: resolve each vendor include, copy the IP addresses, and publish a flattened SPF record. The problem is that vendors change infrastructure. Vendor IP address changes happen frequently, especially with large providers like SendGrid, Amazon SES, Microsoft 365, and Google Workspace. Static SPF flattening can break when those changes are not reflected.
Stale IP Addresses and Static SPF Flattening
Static SPF flattening freezes today’s IP addresses into the SPF record. If a provider adds new IP addresses tomorrow, legitimate mail may fail SPF authentication. If a provider retires old IP addresses, the domain may continue authorizing infrastructure it no longer uses. That creates both email deliverability and security concerns.
Manual flattening also increases the chance of transcription errors. A missed CIDR range, malformed DNS TXT record, or outdated nested include can cause SPF validation problems. Community discussions such as this SPF flattening thread often highlight the operational risk of keeping flattened records synchronized manually.
Broken Includes and Hidden Dependencies
The danger is not only stale IP addresses. Some vendors rely on a nested include structure for regional routing, customer-specific sending pools, or failover. Replacing those includes with IP addresses may remove visibility into vendor changes. An SPF audit using tools such as dmarcian Detail Viewer, PowerDMARC, PowerSPF, or another SPF record flattener can reveal whether a nested include expands safely.
The PTR Mechanism Problem
The PTR mechanism is discouraged in SPF because it is slow, unreliable, and expensive for DNS evaluation. Email security experts generally recommend removing PTR-based SPF logic and using explicit IP addresses or trusted includes instead.
When Manual Flattening May Be Acceptable
Manual flattening can work for small domains with one or two stable sending services, a simple SPF configuration, and disciplined record maintenance.
When Manual Flattening Becomes Dangerous
Manual flattening becomes risky when a domain uses many third-party vendors, has multiple mail stream categories, or operates under strict DMARC policy enforcement with softfail, fail directive, quarantine policy, or reject email outcomes.
How Automatic SPF Flattening and Auto-Updates Keep Records Accurate
Automatic SPF flattening solves the biggest weakness of static SPF flattening: stale data. Instead of flattening once and forgetting, an automated system continuously checks vendor SPF sources, resolves nested include chains, monitors IP addresses, and updates the published SPF record when provider infrastructure changes.
Dynamic SPF Flattening vs. Static SPF Flattening
Dynamic SPF flattening is different from static SPF flattening because it treats SPF management as an ongoing process. A hosted SPF service or automatic SPF flattening platform can maintain a flattened SPF record while tracking vendor IP address changes in the background. Services such as AutoSPF focus on this operational simplicity by automating SPF record updates before stale data causes SPF failures. An SPF flattener can streamline this task by managing SPF dependencies and ensuring that authorized IP addresses remain up-to-date.
This approach improves SPF compliance because the DNS TXT record remains within the DNS lookup limit while still authorizing the right IP addresses. It also helps preserve SPF authentication across marketing, transactional email, support, and corporate mail.
Auto-Updates and SPF Monitoring
Automatic SPF flattening typically includes SPF monitoring, change detection, and alerting. If SendGrid adds IP addresses, Microsoft 365 changes an include, or Amazon SES updates a sending range, the system can refresh the flattened SPF record. This protects the SPF pass rate and reduces the chance of PermError caused by exceeding 10 DNS lookups.
Some tools also provide Domain Overview dashboards, SPF survey-style reporting, and source mapping. dmarc.io, created by Tim Draegen and Asher Morin, is often referenced for understanding mail sources; its source discovery approach is useful when identifying who is sending mail for a domain.
Hosted SPF and Delegated Management
Hosted SPF can work by publishing a smaller SPF record that redirects or includes a managed DNS TXT record controlled by the SPF provider. This allows the provider to perform SPF flattening, maintain IP addresses, and handle SPF capabilities that would otherwise require manual DNS updates.
Vendors such as dmarcian, PowerDMARC, and PowerSPF provide tools and guidance for SPF authentication, DMARC, and DNS-based email authentication. PowerDMARC’s SPF Flattening Tool is one example of how administrators can evaluate or simplify records.
Best Practices for Implementing Automated SPF Flattening Safely
Automated SPF flattening should be implemented carefully. The goal is not just to reduce 10 DNS lookups; it is to preserve accurate authorization, minimize SPF failures, and keep email authentication aligned with business mail flows.
Start With an SPF Audit
Begin with an SPF audit. Identify every sending source, including Google Workspace, Microsoft 365, Zoho, Amazon SES, SendGrid, Mailchimp, Mandrill, Salesforce, Zendesk, and Sendinblue. Map each mail stream to a business owner. Then remove unused SPF entries to reduce SPF bloat before deploying a flattened SPF record.
dmarcian’s guidance on SPF best practices is useful for understanding how to simplify records, avoid unnecessary mechanisms, and maintain SPF compliance.
Segment Domains and Mail Streams
Use subdomain segmentation when possible. Corporate mail, bulk marketing email, transactional email, and support ticketing should not always share the same SPF record. Separate subdomains allow more precise SPF configuration, easier SPF monitoring, and better DMARC policy control.
See also: SPF PermError Explained: Common Causes And Quick Fixes
