SPF flattener — count lookups, expand nested includes, generate a flat record
Type a domain. The browser resolves the published SPF record at the apex, recursively follows every include, a, mx, redirect, and exists mechanism via DNS over HTTPS, counts the total DNS lookups against the RFC 7208 limit of 10, counts void lookups against the separate limit of 2, and generates a flattened version with all mechanisms resolved to direct ip4 and ip6 addresses. You see the original record, the lookup math, the flattened output ready to publish, and warnings if the result exceeds 255 characters per TXT string or 450 characters total. No account, no rate limits; the whole resolution runs in your browser.
Flatten a domain's SPF record
Enter any domain. The lookup runs in your browser via Cloudflare's DNS over HTTPS. Large recursive includes may take a few seconds.
DNS over HTTPS via cloudflare-dns.com · No data sent to our servers
SPF flattening replaces every DNS-querying mechanism in your record with the IP addresses those mechanisms resolve to — turning a chain of nested lookups into a static IP list
RFC 7208 — the SPF specification — sets a hard limit of 10 DNS lookups during the evaluation of any single SPF record. The mechanisms that consume a lookup are include:, a, mx, ptr, exists, and the redirect= modifier. The mechanisms that do not consume a lookup are ip4:, ip6:, and all. Receivers must return a permerror result when evaluation exceeds 10 lookups, regardless of how syntactically correct the rest of the record is. A separate, less-cited limit caps "void lookups" — DNS queries returning NXDOMAIN or an empty response — at 2 per evaluation; exceeding it also produces a permerror.
The arithmetic gets unforgiving fast with realistic sender stacks. Google Workspace alone consumes around 4 lookups when you expand its nested includes; Microsoft 365 (spf.protection.outlook.com) adds 2; SendGrid adds 1; Mailchimp's transactional and marketing branches add 3+; Salesforce adds 2+; HubSpot adds 1-2. A company running Google + a transactional provider + a marketing platform + a CRM + one or two niche tools easily lands at 12-14 lookups. The record looks clean — half a dozen include: entries — but every receiver evaluating it returns permerror, every DMARC alignment check fails on the SPF leg, and inbox placement degrades across Gmail, Outlook, and Yahoo simultaneously. The failure is silent: no bounce explains "SPF too many lookups" in plain language, and operators usually find it by running a check like the one above.
Flattening solves the lookup problem by pre-resolving every querying mechanism at the time you publish the record. The tool walks each include's TXT record, follows nested includes recursively, collects every ip4: and ip6: address it finds, and rewrites your SPF as a flat list. Result: a record with zero include: mechanisms (or a small number, if you keep one or two strategically) and a long list of IP literals. The lookup count drops to 1 — just the root SPF lookup itself — and receivers evaluate the entire record without ever hitting the 10-lookup ceiling.
The tradeoff is maintenance. When Google adds a new sending range to _spf.google.com, your live include:_spf.google.com picks up the change automatically; your flattened record does not. Major providers update their published IP ranges silently and on their own schedule — typically a few times per year for the large ones, more frequently for smaller services. A stale flattened record means legitimate mail from a newly-introduced provider IP starts failing SPF, which means failing DMARC alignment, which means inbox degradation. The discipline is: flatten when you must, monitor monthly, re-flatten when the next check reveals drift. Hosted SPF services (AutoSPF, EasySPF, Sendmarc PowerSPF) automate that loop for a monthly fee; the tool above is what you reach for when you want to do the work yourself or audit what a hosted service is doing.
Every mechanism in an SPF record, how many lookups it costs, and what to watch for
include:domain 1 lookup minimum, plus all nested lookups inside that included record. The most common source of overruns. Each major SaaS provider publishes its own SPF, and those records often nest 2-4 more includes inside them.
a · a:domain 1 lookup. Resolves the A/AAAA record for the domain (or the SPF record's domain if bare). Replace with ip4: or ip6: when you know the IP.
mx · mx:domain 1 lookup for the MX record, then 1 additional lookup per MX server returned to resolve its IPs. A domain with 3 MX servers consumes 4 lookups for a single mx mechanism.
redirect=domain 1 lookup, plus all lookups inside the redirected record. Behaves like an entire SPF replacement. Combining redirect with other mechanisms is technically invalid per RFC 7208.
exists:domain 1 lookup. Tests whether a domain name resolves at all. Rare in modern senders; used in macro-based SPF for per-recipient evaluation.
ptr · ptr:domain 1 lookup, but RFC 7208 explicitly discourages ptr due to performance and reliability concerns. Remove it. Always.
ip4:address · ip6:address 0 lookups. Static IP literal — the flattening target. Accepts both individual addresses and CIDR ranges.
all · -all · ~all · ?all · +all 0 lookups. Final disposition: -all hard fail, ~all soft fail (most common), ?all neutral, +all pass everything (effectively disables SPF — never use). Always the last mechanism in the record.
Flattening is one of five reasonable approaches to staying under 10 lookups. The right choice depends on how often your sending stack changes
1. Remove what you do not use
Always the first step. Most SPF records carry includes for services the company tried six months ago and never sunset. Mailgun, Postmark, that ESP someone evaluated and never migrated to — strip them. The cleanest record is the one that authorizes only what is actually sending today. We typically see 2-4 lookups recovered just from removing stale entries.
2. Replace mx and a with direct IPs
If your mail server IPs are stable — which they usually are for self-hosted Postfix or a hosted MTA — replace mx and a mechanisms with ip4: literals. A single mx mechanism can consume 4+ lookups when nested. Direct IPs consume zero. The tradeoff is monitoring: when you re-IP, update SPF.
3. Flatten everything (this tool)
The nuclear option. Replace every include: with the IPs those includes resolve to today, drop the lookup count to 1, and accept the maintenance burden of re-flattening monthly. Right for senders whose provider stack is stable (Google + 1-2 SaaS), wrong for senders constantly evaluating new tools.
4. Subdomain delegation
Route different sender types through different subdomains: transactional from tx.example.com, marketing from mkt.example.com, internal from mail.example.com. Each subdomain has its own SPF record, each stays under 10 lookups, and the apex carries only the most critical senders. Adds DNS complexity but cleanly solves the architectural problem.
5. Hosted SPF (AutoSPF, EasySPF, PowerSPF)
Replace your SPF with a single include pointing to a hosted service. They resolve and refresh your provider IPs continuously, you maintain a one-line SPF record, and you pay a monthly fee ($10-$30/month at typical SMB volumes). Right for teams that change providers frequently and want to outsource the upkeep. The tradeoff is dependency: if their service goes down or changes terms, your authentication breaks.
Flattening fixes permerror. It does not fix DMARC alignment, DKIM signing, or BIMI eligibility — those are separate problems on the same record set
An SPF record at zero lookups still fails DMARC if the envelope sender domain does not align with the From header. A flat SPF record is still useless without DKIM signing, because DMARC requires either SPF or DKIM to pass and align; a sender that fails SPF alignment but passes DKIM alignment still passes DMARC. The right mental model is: SPF authorizes IPs to send for your domain, DKIM proves the message has not been tampered with, DMARC orchestrates both with policy. Fixing SPF lookups gets you past the permerror failure mode; it does not get you to enforcement-grade authentication on its own.
The longer work — the one our managed customers hire us for — is the rollout from no authentication to p=reject DMARC: ingesting aggregate reports to identify every legitimate sender, fixing SPF and DKIM alignment for each one, getting the right subdomain delegation in place, and validating the chain end-to-end before declaring enforcement. The SPF flattener above is one step in that work. If the result is "you are at 14 lookups and your DMARC reports show 30% failure," that is the conversation to have, not the one about which flattener to use.
Questions teams ask when running the SPF flattener for the first time
How often do I need to re-flatten?
+
Once a month is the operationally honest answer. Major providers — Google, Microsoft, SendGrid — update their published SPF ranges a few times per year, often without public announcement. Smaller providers update more frequently. A flattened record that worked perfectly in January starts dropping legitimate mail in March when one of the providers adds a new sending region.
The discipline that works in practice: schedule a monthly calendar reminder, run the flattener, compare the new output with what is currently published, update if anything changed. Many teams automate this with a script that runs nightly and emails when drift is detected. For teams that do not want to maintain the loop themselves, hosted SPF services do it continuously for a monthly fee.
My flattened record is over 255 characters. Is that broken?
+
Not broken, but you need to format it carefully. The 255-character limit is per-string within a TXT record, not the total record length. Most DNS providers let you publish a single TXT record containing multiple strings, each ≤ 255 characters; receivers concatenate them at evaluation time. So a 600-character SPF record can be published as three quoted strings of ≤ 255 characters each, and receivers see it as one continuous SPF policy.
The practical limit you do need to watch is approximately 450-500 characters total, because some DNS providers (and some older receivers) handle very long multi-string TXT records inconsistently. Once you cross that threshold, the cleaner solution is subdomain delegation — split your senders across tx.example.com, mkt.example.com, and similar, each with its own shorter SPF record.
Can I flatten Microsoft 365's include? Google Workspace's?
+
Technically yes, operationally not recommended for those two specifically. Microsoft and Google both update their sending IP ranges on their own schedule and at higher frequency than smaller providers. A flattened Microsoft 365 include that is two months old has a non-trivial chance of missing newly-added sending IPs, causing legitimate mail from your tenant to fail SPF.
Microsoft's documented recommendation is to keep include:spf.protection.outlook.com in your top-level SPF and flatten less-frequently-updated includes around it. Google publishes a similar recommendation. The pattern that works: keep the 1-2 major provider includes live, flatten everything else, and end up at 3-4 total lookups instead of 12-14.
What's a "void lookup" and how do I avoid hitting the limit of 2?
+
A void lookup is a DNS query that returns no record — either NXDOMAIN (the domain does not exist) or an empty response (the domain exists but has no record of that type). RFC 7208 caps these at 2 per SPF evaluation; the third void lookup produces a permerror, regardless of how many regular lookups you have.
The usual sources: an include: pointing to a domain that has been decommissioned (the SaaS shut down, the subdomain was deleted), an a or mx mechanism for a hostname that no longer resolves, or a ptr mechanism (ptr lookups are particularly prone to void responses on non-rDNS-configured IPs). The flattener above flags any void lookups it encounters during resolution; review and remove them before publishing.
Will flattening break my DMARC alignment?
+
No — flattening only affects the lookup count, not the alignment math. DMARC alignment depends on whether the envelope sender domain (the MAIL FROM, used for SPF) matches the From header domain. A flattened SPF record authorizes the same IPs as the original; if your mail was passing SPF alignment before, it will pass after.
What can break is DMARC pass overall, not alignment specifically — if a provider's IP changes after you flatten and your record goes stale, that provider's mail starts failing SPF authentication outright. Your aggregate reports will surface the failure within 24 hours.
Can multiple SPF records be combined?
+
No — RFC 7208 explicitly prohibits multiple SPF records on the same domain. If a domain has two or more TXT records starting with v=spf1, receivers treat the configuration as invalid and return permerror, ignoring both records. This is one of the most common SPF mistakes we see: a security tool publishes a new record without removing the existing one, and SPF silently breaks across the entire domain.
The fix is consolidation. Combine the mechanisms from every record into a single TXT record starting with v=spf1, delete the others, wait for DNS to propagate (typically 24 hours), and verify with a fresh lookup.