Email authentication
SPF flattening explainer
See how many of a domain’s SPF lookups flattening would actually remove, and what it costs to keep one flattened.
Free, no accountLive check
Result
The verdict and the record appear here once you press Break down the lookups.
What this is
SPF flattening means replacing an "include" with the IP ranges it happens to resolve to today, to get a record back under the ten-lookup limit. This page counts how many of a domain’s lookups could be removed that way, how many could not, and what you take on by keeping a flattened record.
RFC 7208 §4.6.4 allows a receiver ten DNS lookups to evaluate one SPF record, counted across the whole chain. Microsoft's SPF documentation lists which terms spend one: "include", "a", "mx", "exists" and the "redirect" modifier. An "ip4", "ip6" or "all" term spends none, which is the whole idea behind flattening - a provider's include is swapped for the addresses it resolves to, trading a lookup for a list.
The trade is not free. The addresses behind an include belong to the provider, who adds and retires them whenever their own capacity changes; the copy in your record does not follow. That is why this page explains the breakdown and stops there, rather than producing a flattened record for you to publish: a generated list would be accurate for an unknowable length of time and silent about when it stopped being.
How to read the result
The two numbers that matter are at the top: how many lookups come from include or redirect, and how many come from a, mx or exists. The first group is what flattening can remove. The second cannot be removed by flattening at all - those terms already name hosts of yours directly, so collapsing them just moves your own addresses into the record with the same upkeep attached.
The table lists each lookup-costing step and how deep in the chain it sits, since a provider three records down is one you have no control over at all. The tree underneath it is the same walk the SPF checker shows, so the counts on both pages always agree.
Flattening is one way back under SPF’s 10-lookup ceiling, not a fix for whatever caused the record to grow. For how SPF, DKIM and DMARC fit together, what order to fix them in, and what to do once one fails, see our guide How SPF, DKIM and DMARC work together, and what to do when one fails.
Common mistakes
What goes wrong most often, and how to tell.
- Flattening a provider whose addresses are documented as changingMicrosoft name "include:spf.protection.outlook.com" specifically as one not to flatten, since their sending infrastructure uses dynamic addresses. A copy of those ranges breaks silently, and the symptom is a few recipients rejecting mail from one of their newer hosts.
- Flattening a record that was never over the limitA record spending six of its ten lookups evaluates perfectly well. Flattening it swaps a working record for one that needs reviewing every quarter, with nothing gained in exchange - the lookups were not the problem.
- Flattening instead of removing a sender nobody usesMost records over the limit got there by accumulating platforms: an old newsletter tool, a helpdesk that was replaced, a trial that ended. Deleting those costs nothing to maintain, where a flattened include costs attention forever.
- Flattening once and treating the record as finishedMicrosoft's own guidance for anyone who does flatten is to review the flattened entries at least quarterly. A flattened record is a snapshot with an expiry date nobody writes down, and the expiry is set by somebody else.
Questions
What people ask about this tool.
- It is rewriting an SPF record so the mechanisms that cost a DNS lookup - mostly "include" - are replaced by the ip4 and ip6 ranges they currently resolve to. The record then needs fewer of the ten lookups RFC 7208 allows, at the cost of hardcoding addresses somebody else controls.
- Only the ones from an "include" or a "redirect", because those are the terms that open another record. An "a", "mx" or "exists" term resolves a host you already name, so flattening it only replaces your own hostname with its address and saves nothing worth the upkeep.
- Because it would be a list of addresses that is correct the moment it is generated and silently wrong at some later date nobody can predict. A record that fails SPF for a sender you authorised is worse than one that costs a lookup too many, so this page explains the trade-off instead of producing one.
- Microsoft's documentation says explicitly not to flatten "include:spf.protection.outlook.com" because their addresses change frequently, and warns off any cloud service with dynamic addresses. Treat a provider the same way unless they publish ranges they commit to keeping.
- Remove senders that no longer send, which is usually at least one; move a bulk platform onto its own subdomain, which gets its own SPF record and its own budget of ten; or replace an include with the fixed ranges a provider commits to publishing, then re-check it quarterly.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 7208 §4.6.4 - DNS Lookup Limits” read 13 October 2026
- Microsoft, “Set up SPF to identify valid email sources for your Microsoft 365 domain” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.