SPF flattening is the practice of resolving the include, a, and mx mechanisms in your SPF record down to the raw IP addresses they point to, then writing those ip4 and ip6 values directly into the record. The goal is to stay under the SPF 10 DNS-lookup limit so your record does not fail with a PermError. It works, but it trades a self-maintaining record for a static list that you now own and must keep current, which is why it should rarely be your first move.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The 10-lookup limit that forces the question
SPF is evaluated by the receiving mail server, and RFC 7208 caps that evaluation at 10 DNS lookups. Every include, a, mx, ptr, and exists mechanism, plus the redirect modifier, counts against that budget. Nested includes count too: if include:_spf.google.com itself pulls in more includes, those all draw from the same pool of 10. The ip4, ip6, and all mechanisms cost zero lookups because they carry the answer inline. RFC 7208 adds a second, less-known cap: more than two void lookups (mechanisms that resolve to nothing, such as an NXDOMAIN or an empty answer) also produces a PermError, even when the total stays under 10.
The limit exists to protect receivers from denial-of-service amplification, where a single message could otherwise trigger dozens of DNS queries. When your record exceeds 10 lookups, a compliant receiver stops evaluating and returns a permanent error. That result is a PermError, and most receivers treat it as an SPF failure. The practical effect is that DMARC can no longer authenticate on the SPF side, so you lean entirely on DKIM alignment or, worse, fall to a DMARC failure and possible rejection.
If you are staring at that error right now, start with the companion walkthrough on how to fix SPF too many DNS lookups, and read SPF PermError vs TempError so you can tell a permanent structural problem apart from a transient DNS timeout. A TempError is not a lookup-count problem, and flattening will not fix it.
What flattening actually does
Take a record that looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org a mx ~all
Each of those mechanisms costs at least one lookup, and the nested includes push the real total well past 10. Flattening resolves every one of them at a point in time and substitutes the results (abbreviated here):
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:167.89.0.0/17 ip4:161.38.192.0/20 -all
The record now costs zero DNS lookups during evaluation because every authorized network is stated explicitly. You have converted a set of pointers into a snapshot. The security posture is unchanged in the moment: the same IPs are authorized. What changed is who is responsible for keeping the list accurate.
| Property | Include-based record | Flattened record |
|---|---|---|
| DNS lookups at evaluation | Up to 10, easy to exceed | Zero |
| IP maintenance | Provider updates their own include | You update your record |
| Record length | Short, readable | Long, near the size limits |
| Failure mode | PermError if over 10 | Silent SPF fails when a provider adds an IP |
Note the last row. That is the whole tradeoff in one line.
The tradeoff: flattening freezes IPs that were never yours
The entire point of an include mechanism is delegation. When you publish include:_spf.google.com, you are telling receivers to trust whatever IPs Google currently advertises, and Google gets to rotate, add, and retire those IPs without ever asking you to touch your DNS. Flattening breaks that delegation on purpose. You copy today's IPs and take on the job of tracking every future change across every provider in your record.
Large senders change their published ranges more often than most people assume. Google has rotated its _netblocks ranges more than once within a single year, and Microsoft 365 and the major email service providers do the same as they add sending infrastructure. When a provider brings up a new sending host that is not in your frozen list, mail from that host starts failing SPF. Depending on how much of your volume routes through the new host, a meaningful share of legitimate mail can be affected. Nothing errors loudly. The record is still valid, still under the limit, still returns a clean result. It just quietly stops authorizing senders that are genuinely yours, and you find out from a spike in dmarc=fail lines in your aggregate reports or from a support ticket about mail landing in spam.
A static flatten is therefore not a fix you apply once. It is a maintenance obligation. If you flatten, you need automated re-resolution that re-queries every source on a schedule and updates the published record when anything moves. That is what commercial hosted-SPF and automated-flattening services sell: not the flattening itself, which is trivial, but the ongoing refresh that keeps the snapshot from going stale.
Safer alternatives to reach for first
Before you flatten, work through the cheaper fixes. Most domains that trip the limit are carrying dead weight, and removing it gets you back under 10 with no frozen IPs and no new maintenance.
1. Remove dead includes
Audit every mechanism and ask whether it still sends mail for you. Records accumulate include entries for trial services, former ESPs, and one-off campaigns that nobody removed. Each dead include may cost several lookups through its own nesting. Drop any ptr mechanism entirely; it is slow, strongly discouraged by RFC 7208, and counts against your budget. Remove a redundant a or mx if those hosts do not actually originate mail, and dedupe providers that overlap. Pruning alone frequently solves the problem. Your SPF setup guide covers what each mechanism means so you can judge what is safe to cut.
2. Delegate sending streams to subdomains
Every domain and subdomain gets its own independent 10-lookup budget. If you send marketing mail through one platform and transactional mail through another, move each stream onto its own subdomain (for example mail.example.com and news.example.com), each with a short SPF record naming only that provider. Your bounce domain or Return-Path determines which record receivers check, so aligning the envelope sender to the subdomain is the key step. With relaxed DMARC alignment, a subdomain still aligns with the organizational domain, so DMARC continues to pass. See SPF records for subdomains, relaxed vs strict alignment, and the broader question of whether you should send from a subdomain for the full pattern.
3. Use hosted or managed SPF
If you genuinely need many providers under one domain and cannot split streams, a hosted-SPF service gives you flattening plus automatic refresh. You publish a single include or redirect pointing at a record the vendor maintains, and they re-resolve the underlying sources continuously. This keeps you under the limit while preserving the delegation benefit, because the vendor tracks IP changes instead of you. It is flattening done safely, at the cost of a dependency and usually a subscription.
When flattening is actually the right call
Manual flattening earns its place in a narrow set of cases: a provider whose IP ranges are documented as stable and rarely change, a legacy on-premise host you control directly, or a temporary stopgap while you migrate to subdomain delegation. In those situations you are flattening something you own or something that genuinely does not move, so the frozen-snapshot risk is low.
One more constraint: keep an eye on record size. Each string inside a TXT record is limited to 255 characters, and the full SPF response should stay within a 512-byte DNS answer to avoid truncation and TCP fallback. A heavily flattened record can bump into both. Splitting the value into multiple strings inside one TXT record is allowed and resolvers concatenate them, but publishing two separate v=spf1 records for the same host is not; that itself produces a PermError.
Above all, avoid the temptation to paper over the problem by widening your policy. Loosening -all to +all to make failures disappear does not fix anything and authorizes the entire internet to send as you. The reasons are covered in why +all is dangerous.
Frequently asked questions
Does SPF flattening make my domain less secure?
Not at the moment you flatten, because the same IPs are authorized. The risk is over time: a frozen list silently stops authorizing new legitimate sending IPs when a provider changes theirs, which causes real mail to fail SPF. It does not authorize new attackers, so the failure mode is deliverability loss rather than a spoofing hole.
How often do provider IP ranges actually change?
Often enough to matter. Major senders like Google and Microsoft have rotated their published ranges more than once within a single year, and email service providers add hosts as they scale. Any flattened record that is not re-resolved automatically will eventually go stale and start failing legitimate mail.
Will flattening fix an SPF TempError?
No. A TempError is a transient DNS resolution failure such as a timeout or SERVFAIL, not a problem with your lookup count. Flattening only addresses the permanent 10-lookup PermError. See the guide on SPF PermError vs TempError to identify which one you have before acting.
Can I flatten just some mechanisms and keep others as includes?
Yes, and this is often the sane middle path. Flatten only the stable sources you control while leaving fast-moving providers like Google or Microsoft as live include mechanisms so their delegation keeps working. Just confirm the resulting total stays under 10 lookups.
Not sure whether your record is over the limit or already failing silently? Run a free SPFWise scan to see your live SPF record, the exact lookup count, and whether flattening is even necessary before you change a thing.