Reference
SPF flattening and the 10 lookup limit
SPF flattening replaces include mechanisms in an SPF record with the IP addresses they currently resolve to, so the record stays under the 10 DNS lookup limit that produces a permerror. The trade is accuracy: a flattened record freezes sender IPs that vendors change without notice.
| Limit being avoided | 10 DNS lookups per SPF evaluation, defined in RFC 7208 |
|---|---|
| Failure it prevents | permerror, which strict receivers treat as an SPF failure |
| Record size ceiling | 255 characters per string, 512 bytes per DNS response before truncation risk |
| Main risk | Vendor IP changes silently invalidate a flattened record |
| Google's own include | _spf.google.com consumes several of the 10 lookups on its own |
Why the lookup counter runs out
Every include, a, mx, ptr and exists mechanism costs a lookup, and each included record's own includes count too. Three or four marketing and helpdesk tools on top of Google is usually enough to cross ten, at which point conforming receivers stop evaluating and return permerror.
The symptom is intermittent rather than total: some receivers ignore permerror, others treat it as a hard fail, so mail lands for weeks and then a single large recipient domain starts bouncing.
Flatten last, prune first
Removing senders that no longer send is free and permanent. Most records we audit list a former CRM, an old ticketing tool and a payment provider that was replaced two renewals ago, and deleting those three brings the count back under the limit without any ongoing maintenance.
Where flattening is genuinely needed, automate the refresh. A record flattened by hand is a dated snapshot of somebody else's infrastructure, and it will fail quietly on the day that vendor renumbers.
- Delete includes for tools you no longer use
- Route transactional mail through one relay rather than three
- Use subdomains so bulk senders carry their own SPF record
- Flatten only the vendors with stable published ranges
- Re-check the lookup count after every new tool is added
What we see that others don't say
In the SPF records we audit, pruning senders that have not transmitted mail in twelve months resolves the lookup overflow on its own in most cases, without any flattening at all.
What this doesn't cover
- Flattening does not affect DKIM or DMARC alignment; a flattened record can still fail DMARC if the From domain does not align.
- We do not recommend hand-maintained flattened records for domains with more than two third-party senders.
Want this done for you?
Three fields. We come back with whether this is a 20-minute fix or a project, and what it costs.
Prefer to talk? Call +44 20 7183 3436 (Mon–Fri 08:00–18:00 GMT), or message WhatsApp +44 7403 423563.
Questions we get asked
- Is SPF flattening safe?
- It is safe only while the flattened IP addresses remain accurate. Because vendors renumber without notifying customers, a flattened record needs automated refreshing or a scheduled review, otherwise legitimate mail starts failing SPF.
- What counts towards the 10 SPF lookups?
- include, a, mx, ptr and exists mechanisms each cost one lookup, and nested lookups inside an included record count as well. ip4 and ip6 mechanisms cost nothing, which is why flattening reduces the total.
How this page is verified
Reviewed by Workspace Migration Services security desk, Workspace security and compliance reviewers. Last checked .
- Lookup limit and mechanism costs taken from RFC 7208 section 4.6.4 at the review date.
- Pruning outcomes drawn from deliverability reviews we have run on Workspace domains.
Sources you can check
Related pages
SPF returning permerror on your domain?
We inventory every sender on the domain, remove the dead ones, and return a record that evaluates inside the lookup limit with a maintenance plan attached.