SPF Flattening Tool

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 as the primary resolver with automatic fallback to Google DNS over HTTPS. 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 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 counts toward this limit. When a 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 providers are the largest contributors to your lookup count. The All IPs tab lists every resolved IPv4 and IPv6 range. 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 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. You can use the SPF Record Checker at any time to verify your published record is still valid and within the lookup limit.

The 10-lookup PermError is one of the most common causes of silent email delivery failures in organisations that have grown beyond a handful of email tools. It does not announce itself with a clear error message. From the sender's perspective, the email appears to send successfully. From the recipient's perspective, it may be filtered to spam or silently discarded with no bounce. The only reliable way to detect it is through DMARC aggregate reports showing a spike in SPF failures, or by checking the raw SPF result in an email header.

The root cause is architectural. SPF was designed in a simpler era when most domains had one or two mail servers. The include: mechanism was intended as a convenience to allow domain owners to delegate SPF management to their mail providers. In practice, each provider's include: often chains to two or three more includes internally. Google's _spf.google.com alone expands into three child includes. An organisation using Google Workspace, Microsoft 365, Salesforce, HubSpot, Zendesk, SendGrid, and Mailchimp can easily accumulate 12-15 lookups before accounting for any custom server entries. RFC 7208 has never been updated to raise the limit, so flattening is the only standards-compliant fix.

Beyond the lookup limit, flattening provides a secondary benefit: resilience against upstream SPF outages. An include: mechanism is a live DNS dependency. If your ESP's SPF DNS record is temporarily unavailable when a receiving server tries to evaluate your SPF, the lookup may return a TempError, causing uncertain behaviour at the receiver. A flattened record has no external DNS dependencies; it resolves in a single lookup against your own DNS zone, which you control entirely.

For organisations advancing their DMARC policy from p=none toward p=quarantine or p=reject, fixing SPF first is critical. At p=none, a PermError is logged in aggregate reports but causes no mail loss. At p=quarantine or p=reject, that same PermError becomes a filter or rejection event for every affected message. Flattening before tightening DMARC policy eliminates this class of collateral damage entirely. It is also a prerequisite for complying with the Google and Yahoo 2024 bulk sender requirements, which mandate a valid, evaluable SPF record for senders of more than 5,000 daily messages to Gmail. A PermError does not satisfy this requirement.

Most issues encountered when flattening an SPF record fall into a small number of patterns. Here is what each means and how to address it.

SPF flattening solves the DNS lookup problem, but it is worth understanding where SPF sits in the broader email authentication picture. Because SPF alone, even a perfectly flattened one, does not fully protect your domain.

SPF (Sender Policy Framework) validates the SMTP envelope sender. The MAIL FROM address used during the server-to-server handshake. It answers one question: is this IP authorised to send mail claiming to come from this domain? It does not validate the visible From: header in the email client, and it does not survive email forwarding (because the forwarding server's IP is not in the original SPF record). A flattened SPF record ensures that evaluation always completes within the 10-lookup limit and returns a clean pass or fail result. Use the SPF Record Checker after publishing your flattened record to confirm it is valid and within limits.

DKIM (DomainKeys Identified Mail) complements SPF by adding a cryptographic signature to outgoing messages, tied to a domain you control. Because the DKIM signature is in the message headers and is based on your d= domain rather than the sending server's IP, it survives forwarding and is the more reliable alignment mechanism for third-party sending platforms. When an ESP uses its own Return-Path domain, which breaks SPF alignment, DKIM alignment is what keeps DMARC passing. Verify your DKIM configuration with the DKIM Analyzer.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It requires that at least one mechanism passes with alignment to the visible From: header domain, and it specifies what to do when neither passes. None (monitor), quarantine (spam), or reject (block). DMARC also enables daily aggregate reports that show pass/fail rates across all your sending sources, which are the most practical way to catch SPF issues before they cause delivery problems. Check your current DMARC policy with the DMARC Checker or do a full tag-by-tag analysis with the DMARC Analyzer.

The optimal sequence for setting up email authentication from scratch is: (1) publish SPF and flatten if needed, (2) enable DKIM signing via your email providers, (3) publish DMARC at p=none with rua= configured, (4) review aggregate reports for 2-4 weeks, (5) advance DMARC to p=quarantine then p=reject as you confirm all legitimate sources pass. A clean, flattened SPF record is the foundation that makes step 3 onwards safe to execute.