What SPF flattening is (and isn't)
SPF flattening replaces the mechanisms that cost a DNS lookup, namely include:, a, mx, redirect= and exists, with the literal ip4: and ip6: addresses they currently resolve to. Because ip4, ip6 and all cost zero lookups, this is why flattening "works" on paper: it collapses your lookup count.
The catch is immediate: flattening freezes a live delegation into a static snapshot. When you publish include:_spf.google.com, you trust Google to keep that include current. When you flatten it, you copy today's IPs into your own record and take on the job of keeping them current yourself.
A static flatten is not the same thing as a dynamic approach. SPF macros and hosted, auto-updating records also reduce your lookup footprint, but they refresh themselves; a static flatten does not. Do not conflate the two.
Before flattening:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
After flattening (a frozen snapshot taken on the day you flattened):
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ip4:198.2.128.0/18 ip4:205.201.128.0/20 ~all
The "after" record costs zero lookups, but it is a snapshot that decays the moment any of those providers changes an IP range. See SPF flattening vs macros for the static-versus-dynamic distinction.
The 10 DNS lookup limit and PermError
RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups. Each lookup-costing mechanism counts; the literal IP mechanisms do not:
| Mechanism | Lookup cost |
|---|---|
include: | 1 (plus the lookups inside the included record) |
a / mx | 1 each |
ptr | 1 (and RFC-discouraged) |
exists | 1 |
redirect= | 1 |
ip4: / ip6: / all | 0 |
When you exceed 10, evaluation returns a permerror, and that is a double failure. Legitimate mail can be rejected or spam-foldered, spoofers are no longer reliably blocked, and DMARC alignment breaks for every flow, because SPF no longer produces a pass to align against.
There is a second, often forgotten cap: more than two void lookups also triggers a permerror. A void lookup is one that returns no record (NXDOMAIN or an empty answer). Most checkers miss this; this tool surfaces it as a separate void_lookups count.
Finally, distinguish a lookup permerror from a syntax permerror. Flattening fixes neither bad syntax nor a domain with multiple SPF records; the tool's error verdict catches those cases and tells you to fix them first. For a deeper walkthrough, see the SPF permerror guide and how to fix SPF too many DNS lookups. You can confirm a fix at any point with the SPF Checker or the SPF syntax check.
Why flattening is risky (IP churn)
Once you flatten statically, you own the IPs. That creates three problems:
- False negatives. A provider adds a new legitimate sending IP. It is not in your frozen record, so that mail fails SPF.
- Spoofing surface. A provider decommissions an IP and reassigns it. Your record still authorizes it, so it now vouches for someone else.
- Intermittent, hard-to-diagnose failures. Some messages pass and some fail depending on which IP sent them, which is painful to debug.
How real is this? Two figures are worth citing, both sourced. In a case documented by Mailhardener, after a customer flattened, an ESP added a load-balancer IP and roughly 1 message in 20 began to fail SPF. According to AutoSPF telemetry, a third-party include changes on median about every 11.5 days, and IPv6 targets change roughly 2.1 times more often than IPv4. Treat these as indicative, real-world signals, not guarantees.
There is also a size trap. Flattening solves the lookup limit but worsens the separate 255-character TXT string and 512-byte limits, because the record balloons into dozens of ip4 and ip6 blocks. You can trade a lookup problem for a size problem.
Microsoft 365 (Exchange Online) and Google Workspace both publish large IP ranges that change over time, which is exactly what makes a static flatten of those includes fragile. The tool shows per-provider churn badges (low, medium, high); read them as an editorial classification of how volatile a provider's ranges tend to be, not a fabricated update cadence. If you want to gauge the broader impact on inbox placement, the email deliverability score guide puts SPF in context.
Alternatives to try before flattening
The tool's recommendations are ordered by increasing risk. Work down the list and stop at the first option that gets you under the limit.
1. Prune first. Remove include: entries for senders you no longer use or that never produce a pass, drop ptr (RFC-discouraged), kill redundant a and mx, and dedupe overlapping mechanisms. This often gets you back under 10 with zero frozen IPs. Cross-check against your DMARC aggregate data to confirm which senders are actually live; the DMARC checker helps here.
2. Subdomain delegation. Give each sending stream a dedicated subdomain, each with its own fresh 10-lookup budget. The common fear, "won't this break DMARC?", is unfounded: with relaxed DMARC alignment (aspf=r), a subdomain stays aligned with the organizational domain. DMARC is not broken.
3. SPF macros (RFC 7208 section 7). A dynamic record that has no staleness debt, because it resolves at evaluation time. This is advanced and harder to maintain, so reach for it deliberately.
4. Hosted or auto-updating CNAME. A managed record that stays current as providers change. Honestly, this introduces vendor lock-in and means you no longer control that part of your DNS directly.
5. Shift trust to DKIM and DMARC (plus ARC and SRS). This is the conceptual key. Flattening never fixes forwarding or mailing-list failures, because SPF tests the connecting IP and that IP changes on a forward. Robustness comes from DKIM, which survives relaying, with DMARC aligned via DKIM, plus ARC and SRS for forwarded mail. Confirm your signature with the DKIM checker and your policy with the DMARC generator. See the DKIM guide for why DKIM is the more durable signal.
When flattening is actually justified
Flattening is a narrow last resort. It is justified when you have already pruned, you genuinely cannot delegate to subdomains or move to a hosted record, every remaining sender is essential, and you are still over 10 lookups.
If you reach that point, prefer a dynamic approach (macros or hosted) over a static flatten. A static one-shot flatten is a debt, not a fix: you take on the maintenance of keeping those IPs current. If you do flatten statically, commit to re-syncing it, monitor continuously with the SPF Checker, and accept the churn risk described above. Validate the end-to-end result with Mail-tester before you rely on it.
How to read the tool's verdict
The verdict translates your record into one of five states:
- ok: you are within budget; you do not need to flatten. Leave the record alone.
- at risk: you are near the limit. Monitor it, and prune before you add more senders.
- over limit: you are returning a permerror. Fix this as a priority, starting with pruning.
- error: the record cannot be evaluated (syntax error or multiple SPF records). Flattening will not help; fix the underlying record first.
- missing: no SPF record is published. Build one first with the SPF generator.
The budget gauge shows your lookups as X / 10 and your void lookups as V / 2. The takeaway is simple: a green verdict means leave it alone.
FAQ: frequently asked questions
Q: What is SPF flattening, and do I actually need it?
A: Flattening replaces lookup-costing mechanisms (include, a, mx, redirect, exists) with literal ip4/ip6 addresses. Most records that stay under 10 lookups never need it. A green verdict from this tool means you should leave your record as it is.
Q: How does the 10 DNS lookup limit work? (RFC 7208)
A: RFC 7208 section 4.6.4 caps evaluation at 10 lookups. Each include, a, mx, ptr, exists and redirect costs at least one; ip4, ip6 and all cost zero. Over 10 returns a permerror. A separate cap applies too: more than two void lookups also triggers a permerror.
Q: How do I fix the "too many DNS lookups" error or permerror?
A: Do not reflexively flatten. Prune unused includes first, remove ptr, and dedupe; that usually gets you back under 10 with no frozen IPs. Then consider subdomain delegation. Flatten last. See how to fix SPF too many DNS lookups.
Q: Is SPF flattening safe?
A: It carries real risk: a static flatten freezes provider IPs. In a case documented by Mailhardener, an added load-balancer IP made roughly 1 message in 20 fail SPF. Per AutoSPF telemetry, third-party includes change on median about every 11.5 days. Prefer dynamic options where you can.
Q: What are the alternatives to flattening?
A: Ordered by increasing risk: prune unused mechanisms, then subdomain delegation (with relaxed DMARC alignment aspf=r), then SPF macros, then hosted/CNAME, and finally shifting trust to DKIM and DMARC. Use the safest one that gets you under the limit.
Q: Will flattening break DMARC, or fix forwarding failures?
A: Flattening does not fix forwarding or mailing-list failures, because SPF tests the connecting IP, which changes on a forward. DMARC robustness comes from DKIM alignment. Subdomain delegation with relaxed alignment (aspf=r) keeps DMARC alignment intact.
Q: Static flattening vs hosted or dynamic SPF: what's the difference?
A: A static flatten is a frozen IP snapshot that decays; a dynamic option (macros or a hosted, auto-updating record) keeps itself current. They are not the same thing. See SPF flattening vs macros.
Q: Flattening fixed my lookups but my record is now too long. Why?
A: The 255-character / 512-byte size limit is separate from the lookup cap. Flattening trades a lookup problem for a size problem. Split the record across subdomains rather than packing one oversized TXT.
Q: SPF Flattener vs SPF Generator vs SPF Checker: which do I use?
A: The SPF Checker diagnoses a published record. The SPF Generator builds a fresh one. The SPF Flattener is the advisory, last-resort optimizer that tells you whether you even need to flatten.
Complementary tools
| Tool | Purpose |
|---|---|
| SPF Record Check | Diagnose your published SPF and confirm any fix |
| SPF Syntax Check | Validate SPF syntax before publishing |
| SPF Generator | Build a fresh SPF record from your providers |
| DMARC Record Check | Check DMARC alignment and policy |
| DMARC Generator | Configure DMARC to complete your authentication |
| DKIM Record Check | Verify the DKIM signature you should rely on |
| Mail-tester | Validate the full sending pipeline end to end |
| Mail Domain Check | Full email-authentication audit for your domain |
| IP Blacklist Check | Check sender IP reputation |
| Domain Blacklist Check | Check domain reputation |
Useful resources
- RFC 7208 (Sender Policy Framework): the source for the 10-lookup cap, the void-lookup cap, and SPF macros
- RFC 4408 (SPF, legacy version): the previous version of the SPF specification
- dmarcian, SPF best practices: authority guidance on keeping SPF within the lookup limit without static flattening
- Mailhardener, Do not flatten your SPF record: the documented load-balancer case behind the "1 message in 20" figure
- Google Workspace, configure and troubleshoot SPF: Google's guide to setting up and fixing SPF
- Microsoft 365, set up and troubleshoot SPF: Microsoft's guide to configuring SPF