Flattening replaces include mechanisms with the IP addresses they resolve to, which cuts DNS lookups. It works, but the list goes stale when a vendor changes addresses, and your mail then fails SPF. Try removing unused senders and splitting streams across subdomains first. Flatten last, and with automation that refreshes the list.
The limit that causes this
The SPF specification, RFC 7208, caps evaluation at 10 mechanisms and modifiers that cause DNS lookups. The include, a, mx, ptr and exists mechanisms and the redirect modifier count. Ip4 and ip6 do not. Go past the limit and the result is a permanent error, so receivers may treat your SPF as broken. The same document also advises limiting void lookups, queries that return nothing, to two. Our post on the 10 lookup limit explains the error in detail.
What flattening does
A flattened record expands each include into the address ranges behind it:
v=spf1 include:mailer.example.net -all
becomes something like:
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/25 -all
The addresses above are documentation examples. The new record uses no lookups for those senders.
The catch
The include is a live pointer. When the vendor adds or retires servers, your record follows automatically. A flattened copy does not. If the vendor starts sending from a new range, your mail fails SPF until someone updates the record. If they drop a range, you keep authorising addresses that someone else may later receive. Failures are silent and arrive at the worst time.
DNS text records also have size constraints, so a long flattened record may need splitting across multiple strings.
Options compared
| Approach | Effect on lookups | Upkeep | Risk |
|---|---|---|---|
| Remove senders you no longer use | Lower | Low | Low, if you verify first |
| Split streams across subdomains | Each record has its own budget | Medium | Low |
| Rely on DKIM for third parties | SPF can stay small | Medium | Low if DKIM aligns |
| Manual flattening | Lowest | High | Stale lists |
| Automated flattening that refreshes | Lowest | Low, but you depend on a service | Service outage or error |
Decision steps
- Count. Check your lookups with an SPF checker, and include nested ones.
- Prune. Remove vendors you stopped using. Verify with aggregate reports before deleting.
- Split. Move marketing, support and product mail to subdomains, see separate sending subdomains.
- Lean on DKIM. DMARC needs one aligned pass, and DKIM covers many third parties.
- Flatten last. If you do, automate refresh, alert on change, and keep the original includes documented.
A note on ptr and macros
The RFC discourages the ptr mechanism. Avoid it. It is slow and counts against the limit.
Safeguard is a software supply chain platform and does not manage SPF, but you can run the free scan at gold.safeguard.sh/scan on your repositories while you tidy your mail setup.
Quick check
Does ip4 count toward the 10 lookup limit?
No. The ip4 and ip6 mechanisms need no DNS query, so they do not count.
Is exceeding the limit a warning or a failure?
It produces a permanent error result, which receivers may handle as a failure. Treat it as a real fault.
Sources
Last reviewed: 19 October 2026.
