Recursively resolves all include: and redirect= mechanisms via Cloudflare DoH (Google DoH fallback). Deep include chains may take 5-15 seconds.
What this tool does
Free SPF flattening tool -- resolve SPF include chains, fix the 10-lookup PermError, and optimise SPF records for email deliverability
How this SPF record flattener works, what the DNS lookup limit means, and when you need SPF flattening to fix email authentication failures
This free SPF flattening tool performs a complete recursive resolution of your domain's SPF record, following every include: and redirect= mechanism through all levels of nesting until all IP addresses authorised to send email on your behalf are collected. The resolution uses Cloudflare DNS over HTTPS (cloudflare-dns.com/dns-query) as the primary resolver with automatic fallback to Google DNS over HTTPS (dns.google/resolve) -- both are globally distributed, privacy-respecting resolvers that return live DNS data. The tool resolves up to 6 levels of include chain depth, handles ip4:, ip6:, include:, redirect=, a:, and mx: mechanisms, deduplicates all resolved IPs, and builds the output record using only explicit ip4: and ip6: entries plus your chosen policy qualifier (-all, ~all, or ?all). The result is a single-line DNS TXT record that can be directly published as your domain's SPF record, requiring exactly one DNS lookup to evaluate instead of the potentially dozens required by a nested include chain.
The 10-lookup limit is defined in RFC 7208 (the current SPF specification) as a hard ceiling on the number of DNS queries that may be triggered during SPF record evaluation. Each include:, a:, mx:, ptr:, exists:, and redirect= mechanism that requires a live DNS lookup counts toward this limit. The limit exists to prevent denial-of-service scenarios where a malicious SPF record could trigger unbounded recursive DNS queries against arbitrary servers. When the receiving mail server encounters more than 10 such mechanisms while evaluating your SPF record, it immediately returns a PermError status. Under a DMARC policy of p=quarantine or p=reject, this PermError is treated as an authentication failure -- meaning legitimate email from your domain is filtered to spam or rejected outright, not because it came from an unauthorised server, but purely because your SPF record is too deeply nested. This is a surprisingly common cause of enterprise email deliverability failures, particularly for organisations using five or more email service providers simultaneously.
The include tree visualisation tab shows the full recursive structure of your SPF record as a collapsible tree, with each node showing the domain, its SPF record, and how many IP addresses it contributes. This makes it immediately clear which email service providers are the largest contributors to your lookup count and IP pool. The All IPs tab lists every resolved IPv4 and IPv6 range as individual chips that can be scanned or exported. The Flat Record tab shows the complete ready-to-publish SPF record with a one-click copy button. A critical maintenance note: the flattened record captures a snapshot of your email providers' IP ranges at the moment of flattening. Major ESPs including Google, SendGrid, and Mailchimp regularly rotate their IP infrastructure, so a flattened record requires re-running this tool and updating your DNS every 60-90 days to avoid authorisation gaps. For automated maintenance, consider a dynamic SPF flattening service that monitors upstream includes and updates your DNS records automatically when IP ranges change.
Features and checks
Recursive Resolution
Follows include: and redirect= chains up to 6 levels deep, resolving every nested SPF record until all IPs are collected.
Cloudflare DoH
All DNS queries use Cloudflare DNS over HTTPS for low-latency, privacy-preserving, live resolution without caching delays.
Google DoH Fallback
If Cloudflare DoH is unreachable, queries automatically retry via Google Public DNS over HTTPS for high availability.
Lookup Count Check
Counts the number of DNS-lookup mechanisms in your original SPF record and warns if you are approaching or over the 10-lookup limit.
PermError Detection
Immediately flags records with more than 10 lookups with a PermError warning and explains the deliverability impact.
IP Deduplication
All IPv4 and IPv6 ranges resolved across the full include tree are deduplicated before the flat record is built.
Policy Selector
Choose -all (hard fail), ~all (soft fail), or ?all (neutral) for the all qualifier appended to the flattened record.
Include Tree View
Collapsible tree visualisation showing each included domain, its SPF record, and how many IPs it contributes at each level.
All IPs Tab
Lists every resolved IP range as individual chips, with IPv4 and IPv6 ranges displayed separately for easy scanning.
Copy-Ready Output
One-click copy of the complete flattened SPF record formatted for immediate use as a DNS TXT record value.
Original Record Display
Shows your current unpublished SPF record alongside the flat output so you can compare before updating DNS.
Resolve Time
Measures and displays the total resolution time in milliseconds so you can identify slow or timing-out DNS lookups.
Examples
SPF flattening examples -- from single-provider records to over-limit enterprise setups and deep include chains
Five real-world SPF configurations showing when flattening is needed, what the results look like, and how lookup counts change
ExcellentGoogle Workspace only -- 2 lookups, clean record, no flattening needed
Domain: yourcompany.com
Original: v=spf1 include:_spf.google.com ~all
Lookups: 2 (well within limit)
Resolved: 35 IPs (Google mail server ranges)
Flat: v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ... ~all
Verdict: Flattening reduces to 1 lookup for maximum safety
A domain sending exclusively via Google Workspace uses only 2 DNS lookups -- safely within the limit. Flattening is still beneficial as it eliminates the dependency on Google's SPF record staying within bounds if they add more includes in future. The flat record resolves to 35 IP ranges covering all Google mail infrastructure.
GoodMulti-ESP setup -- 7 lookups, approaching the limit
Domain: saas-company.com
Original: v=spf1 include:_spf.google.com include:sendgrid.net
include:servers.mcsv.net include:mktomail.com ~all
Lookups: 7 (approaching 10-lookup limit)
Resolved: 120+ IPs across 4 providers
Flat: v=spf1 ip4:... [120 ip4 entries] ~all
Lookups after flatten: 1
A SaaS company using Google, SendGrid, Mailchimp, and Marketo reaches 7 lookups. Adding even one more ESP would risk hitting the limit. Flattening drops this to a single lookup regardless of how many providers are added to the resolved IP list, giving headroom for future additions without SPF breakage.
WarningOver-limit record -- 13 lookups, SPF returning PermError
Domain: enterprise.com
Original: v=spf1 include:_spf.google.com include:sendgrid.net
include:amazonses.com include:mailgun.org
include:servers.mcsv.net include:mktomail.com
include:_spf.salesforce.com include:spf.mandrillapp.com ~all
Lookups: 13 (EXCEEDS 10-lookup limit -- PermError)
Status: SPF failing for all mail regardless of sender
Fix: Flatten immediately -- all legitimate mail is at risk
An enterprise with 8 email providers exceeds the 10-lookup limit, causing SPF PermError on every email. This means even legitimate email from Google, SendGrid, and Salesforce is failing SPF validation. Under a p=quarantine DMARC policy, this routes all outbound email to spam folders. Flattening resolves this immediately by reducing to 1 lookup.
ExcellentDeep include chain -- 3 levels deep, all resolved correctly
Domain: platform.io
Root SPF: v=spf1 include:_spf.google.com include:sendgrid.net -all
Level 2: _spf.google.com -> include:_netblocks.google.com
{'->'} include:_netblocks2.google.com
{'->'} include:_netblocks3.google.com
Level 3: _netblocks.google.com -> ip4: ranges
Lookups: 6 total (safe)
Tree depth: 3 levels resolved
Flat: v=spf1 [all IPs] -all (1 lookup)
Google's SPF record uses three levels of include nesting (_spf.google.com includes _netblocks.google.com which contains the actual IPs). This tool resolves all three levels automatically, collecting all IP ranges at each depth. The include tree visualisation shows each level as an expandable node so you can see exactly which sub-domain contributed which IP ranges.
WarningRedirect mechanism -- less common, fully supported
Domain: subsidiary.com
Original: v=spf1 redirect=_spf.parentcorp.com
Lookups: 1 + (all lookups from parent record)
Parent: v=spf1 include:_spf.google.com include:sendgrid.net -all
Total: 3 lookups (currently safe)
Resolved: 55 IPs
Flat: v=spf1 ip4:... [55 entries] -all
A subsidiary domain using redirect= to inherit the parent company's SPF policy. Redirect mechanisms are fully supported by this flattener -- the tool follows the redirect to the parent domain and recursively resolves that record. This is common in enterprise setups where multiple subsidiary domains share a single mail infrastructure.
FAQ
Frequently asked questions about SPF flattening, the DNS lookup limit, PermError, and SPF record optimisation
Common questions about how SPF flattening works, when you need it, and how to maintain a flattened SPF record
What is SPF flattening and when do I need it?
SPF flattening is the process of recursively resolving all include: and redirect= mechanisms in an SPF record to their actual underlying IP addresses, then replacing the nested lookup chain with explicit ip4: and ip6: entries. You need SPF flattening when your domain uses multiple email service providers -- such as Google Workspace, SendGrid, Mailchimp, Salesforce, and HubSpot simultaneously -- because each include: directive adds one or more DNS lookups. RFC 7208 limits SPF evaluation to exactly 10 DNS lookups. When you exceed this limit, the receiving mail server returns a PermError status, meaning your SPF record fails validation regardless of whether the sending IP is legitimately authorised.
Why does SPF have a 10 DNS lookup limit and what happens when you exceed it?
The 10-lookup limit was established in RFC 7208 (the SPF specification) to prevent denial-of-service attacks where a malicious SPF record could trigger an unbounded chain of DNS queries against arbitrary servers, amplifying the attack and consuming server resources. When a receiving mail server evaluates your SPF record and encounters more than 10 mechanisms that require a DNS lookup (include:, a, mx, ptr, exists:, redirect=), it returns a PermError result. This PermError is treated as an SPF failure. If your DMARC policy is p=quarantine or p=reject, this means legitimate email from your domain may be sent to spam or rejected outright -- not because it came from an unauthorised server, but purely due to the lookup count.
How does SPF record flattening work technically?
SPF flattening works by performing a depth-first traversal of the include: and redirect= chain in your SPF record. Starting with your domain's root SPF record, the flattener fetches the TXT record, parses it, and for each include: mechanism, recursively fetches and parses the included domain's SPF record. This continues until all include chains are resolved or a depth limit is reached (typically 5-6 levels). At each level, any ip4: and ip6: entries are collected directly, and any a: or mx: mechanisms are resolved to their current IP addresses via additional DNS lookups. The final output is a single SPF record containing only explicit ip4: and ip6: entries plus the policy qualifier (-all, ~all, or ?all), requiring only one DNS lookup to evaluate.
What is the difference between -all, ~all, and ?all in an SPF record?
The all mechanism at the end of an SPF record defines how receiving servers should treat mail from senders not listed in the record. -all (hard fail) instructs receiving servers to reject mail that does not match any mechanism in the record -- this is the most secure option and recommended for domains where you fully control and know all sending sources. ~all (soft fail) instructs servers to mark non-matching mail as suspicious but typically still deliver it, usually with a header flag -- this is appropriate for domains that are still validating their sending sources. ?all (neutral) takes no position and effectively disables enforcement, treating all mail the same regardless of SPF result. For a flattened record where you have resolved all IPs, -all is the correct choice as you have explicitly enumerated every authorised sender.
How many IP addresses can a flattened SPF record contain?
There is no RFC-defined hard limit on the number of ip4: and ip6: entries in an SPF record, but practical limits exist due to DNS TXT record size constraints. A single DNS TXT record string is limited to 255 characters, but multiple strings can be concatenated within a single TXT record response up to a total of approximately 2048 bytes (varying by DNS server implementation). In practice, very large corporate SPF records can easily contain 100-200 IP ranges when flattened. If your flattened record approaches 2000 characters, you may need to split authorised senders across subdomains and use include: to reference those subdomains, keeping the total to two or three includes within the 10-lookup budget.
What are the downsides of SPF flattening and how do I maintain a flattened record?
The primary downside of SPF flattening is that it captures a snapshot of your email providers' IP addresses at the time of flattening. Major ESPs like Google, SendGrid, Mailchimp, and Salesforce regularly add, remove, and rotate IP addresses in their infrastructure. When they do, your flattened SPF record becomes out of date -- it may either fail to authorise legitimate mail from new IPs (causing SPF failures) or continue to authorise IPs that have been reassigned to other senders (a security risk). To maintain a flattened record, set a calendar reminder to re-run this flattening tool every 60-90 days and update your DNS TXT record with the refreshed output. Alternatively, consider a dynamic SPF flattening service that automatically monitors your includes and updates your DNS records when upstream IPs change.
How do I check how many DNS lookups my current SPF record uses?
Enter your domain in this SPF flattening tool and the Original Lookups counter in the results summary will show you the number of DNS lookups required to evaluate your current SPF record. Each include:, redirect=, a, mx, ptr, and exists: mechanism counts as one lookup. Note that ip4: and ip6: entries do not count toward the lookup limit because they specify IPs directly without requiring a DNS query. The lookup counter in this tool counts the mechanisms in your root SPF record only -- the recursive lookups required inside each include chain also count toward the limit during evaluation, which is why the actual lookup count during evaluation is often much higher than the count of mechanisms visible in your root record.
Can SPF flattening break my email deliverability?
Incorrectly applied SPF flattening can break deliverability if the flattened record is missing IP addresses that your email providers use for sending. This can happen if: the flattening tool did not fully resolve all include chains (for example, if a DNS timeout occurred during resolution), if you copy the record with errors, or if you use the flattened record as a replacement for the original but the original included mechanisms that resolve to more IPs than were captured. Before replacing your live SPF record, verify the flattened output by checking that it contains IPs from all your sending services. After publishing, send a test email through each provider and check the email headers for SPF: pass results. You can also use the SMTP tester on this site to re-validate the configuration after the DNS change propagates.
How do I publish a flattened SPF record in DNS?
To publish the flattened SPF record, log into your DNS control panel (Cloudflare, GoDaddy, Namecheap, Route 53, or your hosting provider's DNS management interface). Find the existing TXT record at your domain root (typically displayed as @ or your domain name) that starts with v=spf1. Delete or edit this record and replace the entire value with the flattened record from this tool. Do not add the flattened record as a second TXT record -- domains must have exactly one SPF record and having two TXT records starting with v=spf1 causes an SPF PermError. After saving, DNS propagation typically takes 5 minutes to a few hours depending on your TTL setting. Re-run this tool or use an SPF checker to confirm the new record is live and valid.
What is the include tree visualization in this SPF flattening tool?
The include tree tab in this tool shows the full recursive structure of your SPF record as a collapsible tree diagram. The root node shows your domain's SPF record, and each include: or redirect= mechanism expands into a child node showing the included domain, its SPF record, and how many IPs it contributes. This visualization makes it immediately clear which of your email service providers are contributing the most IP addresses and how deep the include chain goes. Domains using more than three levels of nested includes are the most common cause of lookup limit issues because the lookup count compounds at each level. The tree view is particularly useful for identifying redundant includes -- cases where two different includes from different services resolve to overlapping IP ranges that can potentially be consolidated.
Related Email Tools
Need a disposable email address?Stop exposing your real address -- get a free instant throwaway with no signup and no trace.
Get Free Temp Mail ->