Quick SPF flattening reference
SPF has a hard limit of 10 DNS lookups per evaluation (RFC 7208, section 4.6.4). Exceed it and SPF returns PermError, which is treated as a failure. SPF flattening means replacing include: statements with the raw IP ranges they would have expanded to, removing the lookups. It works mechanically, but it creates maintenance debt because those IP ranges change without notice, breaking your SPF silently.
| The limit | 10 DNS lookups per SPF evaluation, total across the chain |
| What counts as a lookup | include, a, mx, ptr, exists, redirect (not ip4, ip6, all, +/-/~/?) |
| Symptom of exceeding | PermError, treated as spf=permerror or spf=none by most receivers, DMARC alignment fails |
| Flattening | Replace includes with the IP4/IP6 ranges they expand to. Works but creates maintenance debt. |
| Better alternatives | Subdomains per ESP, ESP consolidation, automated SPF services |
The 10 DNS lookup limit
RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups. The limit exists to prevent two things: SPF chains that take so long to evaluate they delay mail delivery, and SPF chains that can be weaponized as DNS amplification attacks. The limit is per evaluation, counted across the entire include: chain, not per record.
Each of these mechanisms triggers a DNS lookup:
include:(the most common)amxptr(deprecated, avoid)exists:redirect=
These do not trigger lookups:
ip4:ip6:all- Qualifiers (
+,-,~,?)
The chain is cumulative. If your record has 5 includes and each of those records has 3 of its own includes, you have already used 5 + 15 = 20 lookups, and you’re way past the limit.
How includes cascade and consume the budget
A common SPF record for a B2B sender looks like this:
v=spf1 include:_spf.google.com include:spf.mandrillapp.com include:servers.mcsv.net include:_spf.salesforce.com include:sendgrid.net include:_spf.intercom.io ~allSix includes. Each is one lookup. But each of those records itself contains more includes:
_spf.google.comincludes_netblocks.google.com,_netblocks2.google.com,_netblocks3.google.com(3 more lookups, total: 4)spf.mandrillapp.comtypically 1-2 nested lookups (total now: 6)servers.mcsv.net1 nested lookup (total: 8)_spf.salesforce.com1-2 nested lookups (total: 10-11)sendgrid.net1 nested lookup (total: 11-12)_spf.intercom.io1 nested lookup (total: 12-13)
You’re over the limit before you’ve even noticed. SPF fails. DMARC alignment fails. Authentication breaks silently.
What SPF flattening means
SPF flattening means replacing each include: with the raw IP ranges that the included record points to. Instead of:
v=spf1 include:_spf.google.com ~allYou publish:
v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~allNo more include: means no more lookups. The IP ranges go in directly, evaluated as ip4: and ip6: which don’t count against the 10 limit.
Why flattening is bad
Flattening works on the day you do it. The problem is what happens later.
1. ESPs change their IP ranges without notice. Google adds new sending IPs when they expand a data center. Mailchimp rotates IPs as they manage pool reputation. Salesforce updates its ranges quarterly. Each of these changes is published in the ESP’s SPF record, so a sender using include: picks them up automatically. A sender who flattened the record will not. Your SPF starts failing for mail from those new IPs, silently.
2. You don’t know when it broke. Failing SPF doesn’t generate an alert by itself. You see it in DMARC reports if you’re reading them, or as a sudden placement drop, or as customers complaining about delivery from your domain. The lag from breakage to detection is usually weeks.
3. The “fix” is to flatten again. You have to re-run the flattening process every time an ESP changes ranges, which is unpredictable. Either you set up automation to monitor ESP records and re-flatten yours when they change (real work), or you live with periodic outages (operationally bad).
4. The record gets huge. DNS TXT records have a 255-character segment limit, and SPF best practice keeps total record size under ~450 characters for compatibility. A heavily flattened record blows past that, requiring multi-segment TXT records that confuse some DNS providers and validation tools.
5. Some receivers detect flattening as a signal. A 4 KB SPF record with no includes and a hundred IP ranges looks unusual. Most receivers don’t care; some treat it as a weak negative signal because it suggests sender complexity that may indicate spam infrastructure.
Better alternatives to flattening
1. Subdomain delegation per ESP
Each ESP gets its own subdomain with its own SPF record. The main domain’s SPF stays small.
example.com. TXT "v=spf1 include:_spf.google.com ~all"
news.example.com. TXT "v=spf1 include:servers.mcsv.net ~all"
support.example.com. TXT "v=spf1 include:_spf.intercom.io ~all"
sales.example.com. TXT "v=spf1 include:_spf.salesforce.com ~all"The marketing ESP sends from marketing@news.example.com; the support tool sends from support@support.example.com; and so on. Each subdomain has its own SPF chain, none of them exceed 10 lookups, and ESPs that update their IP ranges propagate automatically.
Tradeoff: your From addresses now include subdomains, which some marketing teams resist. The right framing is that this is what subdomains are for; the From address is a brand decision separate from envelope routing, and you can keep the visible From at a marketing-friendly value while authenticating at the subdomain level.
2. ESP consolidation
The cheapest fix: send less mail from your domain. Audit which ESPs you actually use and whether some can be retired. Many companies accumulate ESPs over time without removing the old ones; a quarterly cleanup typically removes 2 to 4 unused SPF includes.
3. Authenticate with DKIM, not SPF
DMARC requires SPF OR DKIM to align, not both. If DKIM is reliably aligned for every sender (each ESP signs with d=example.com, as covered in our multi-ESP DKIM guide), SPF can be less comprehensive. SPF still matters for some receivers and some flows (mail without DKIM, simpler antispam stacks), but its role is reduced.
4. SPF management services
Services like AutoSPF, EasyDMARC’s SPF Manager, PowerDMARC’s hosted SPF, and Cloudflare’s SPF service offer “managed SPF” where you publish one include that points to their service, and they keep the underlying ranges current. The service watches each ESP’s SPF and updates the consolidated record automatically. From your perspective it looks like one lookup, but behind the scenes the service is doing the maintenance work.
Tradeoff: dependency on a third party for an authentication mechanism. If their service goes down, your SPF goes down. Reputable providers offer SLAs and operate at high availability, but the dependency is real.
5. SPF macros
RFC 7208 supports macros, which let you compute SPF mechanisms based on the sender’s identity. Macros are powerful but undocumented territory at most ESPs and most DNS providers reject malformed macros. Useful for very specific edge cases, not for general use.
When flattening might still make sense
Despite the maintenance debt, there are scenarios where flattening is the least bad option:
- A small set of static IPs. If your sending sources are 2 to 3 on-premise mail servers with stable IPs that won’t change in years, including them as
ip4:directly is cleaner than wrapping them in a separate include. - An ESP that doesn’t manage its own SPF. Rare, but some smaller niche providers don’t publish a maintained SPF include. If you’re forced to list their IPs anyway, you might as well do it inline.
- A temporary measure. You’re over the 10 lookup limit, mail is failing, and you need 24 hours of relief while you restructure. Flatten now, restructure properly within the week.
The pattern in all three cases is “the IPs won’t change, or I’ll restructure anyway”. If neither applies, don’t flatten.
Tools for diagnosing and restructuring
- SPF lookup counters. dmarcian’s SPF Surveyor, EasyDMARC’s SPF Lookup, MXToolbox’s SPF Record Check. Each shows your current chain and counts lookups.
- Managed SPF services. AutoSPF, EasyDMARC SPF Manager, PowerDMARC, Cloudflare SPF.
- DMARC report aggregators. Postmark DMARC, dmarcian, EasyDMARC, OnDMARC. They show SPF failure rates per source, surfacing breakage that PermError checks miss.
Run a lookup counter against your domain monthly. If you cross 8 lookups, plan a restructuring before you hit 10.
10 common SPF lookup mistakes
- Counting
ip4:andip6:against the limit. They don’t count. Only mechanisms that trigger DNS lookups do. - Adding
+allinstead of~allor-all.+allmeans “anyone can send for this domain”, which defeats SPF. Always use~all(softfail) during testing or-all(fail) in production. - Two SPF records on the same name. RFC 7208 says only one SPF record per name. Two records produce undefined behavior; most receivers treat it as PermError. Consolidate into one.
- Using
ptr. Deprecated, slow, and unreliable. Modern receivers ignoreptrmechanisms or treat them as failure. Remove. - Forgetting subdomains. SPF at
example.comdoes not apply tonews.example.com. Each subdomain that sends mail needs its own SPF record. - Including ESPs you no longer use. Each leftover include burns lookups for no benefit. Audit quarterly.
- Mixing
include:andredirect=incorrectly.redirect=replaces the entire record’s evaluation; it doesn’t add to the chain. Used wrong, it overrides everything else in your record. - Wrapping the SPF record in quotes incorrectly. TXT records use double quotes; some DNS providers expect them, some don’t. Always test the published record with a lookup tool, not just the DNS provider’s “valid” UI.
- Listing IPv6 ranges without
ip6:prefix. The prefix is required. Some tools allowip6without the colon, but standards requireip6:. - Flattening and forgetting. The most common long-term mistake. Calendar a quarterly check to see if the flattened ranges still cover your ESPs’ current IPs.
SPF flattening FAQ
What is the SPF 10 lookup limit exactly?
RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups, counted cumulatively across the entire include chain. The mechanisms include, a, mx, ptr, exists, and redirect each trigger a lookup. ip4, ip6, and all do not. Exceeding the limit causes PermError, which most receivers treat as authentication failure.
Should I flatten my SPF record?
Almost never as a long-term solution. Flattening works mechanically but creates maintenance debt: ESPs change their IP ranges and your flattened record stops covering them silently. Better options: subdomain delegation per ESP, ESP consolidation, or a managed SPF service that handles updates for you. Flatten temporarily only if you need a 24-hour fix while restructuring.
What happens when SPF returns PermError?
Most major receivers treat PermError as authentication failure (some treat it as spf=none, which is similar). DMARC then evaluates whether DKIM aligns; if DKIM is fine, the message can still pass DMARC. If DKIM also fails or isn’t present, the message fails DMARC. Either way, PermError is a signal you have a misconfigured SPF record, and you should fix it.
Does flattening hurt deliverability?
Indirectly. The flattening itself is invisible to most filters. The problem is when the underlying ESP changes IP ranges and your flattened record no longer covers them, so legitimate mail starts failing SPF. That failure can trigger spam folder routing, especially at receivers that weight SPF strongly. So flattening doesn’t hurt deliverability today, but a forgotten flattened record hurts it next quarter.
Can I use a managed SPF service like AutoSPF?
Yes. Services like AutoSPF, EasyDMARC SPF Manager, PowerDMARC’s hosted SPF, and Cloudflare’s SPF service consolidate your includes behind a single managed record. They monitor each ESP’s SPF and update the consolidated view automatically. The tradeoff is dependency on a third party for an authentication mechanism. Reputable services operate at high availability; assess the risk against the maintenance burden of doing it yourself.
If DKIM aligns, do I really need SPF to pass?
For DMARC, no. DMARC requires SPF OR DKIM to align, not both. If DKIM is reliably aligned for every sending source, DMARC passes regardless of SPF. SPF still matters for some independent purposes (simpler antispam stacks, mail without DKIM, the SPF check itself as a deliverability signal at some receivers), so keep it healthy. But for DMARC enforcement specifically, DKIM alignment is sufficient.
Final words
SPF’s 10 lookup limit is an old constraint applied to a modern environment that uses more sending services than the spec authors anticipated. Flattening is the quick fix that creates the next problem. Restructuring (subdomains, ESP consolidation, DKIM-first authentication) is the better answer for almost every domain over a couple of senders.
The right cadence is a quarterly audit: run your SPF through a lookup counter, prune unused includes, and watch for senders that grew their own SPF includes since you last looked. SPF should be a 30-minute job four times a year, not a midnight emergency when authentication breaks.
For broader context, see our guides on SPF setup, DKIM, DMARC, DKIM with multiple ESPs, and the Deliverability hub.
Clean your list before you send.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
