Is my SPF record over the 10-lookup limit?
Walk your whole SPF tree live and see exactly how many of the 10 permitted DNS lookups it spends, which mechanisms spend them, and what actually fixes it if you are over.
Flattening replaces live provider references with a snapshot that goes stale silently. We work out whether flattening is even appropriate before suggesting it, and we only hand over a record after checking it gives the same answer as your live policy at every range edge. When we cannot prove that, you get no record rather than a record with a warning on it.
SPF is evaluated by the receiving mail server, and the standard allows it at most 10 DNS lookups while doing so. Every include:, a, mx and redirect= costs one, and the providers you include can add lookups of their own without telling you. Cross the limit and SPF returns permerror — which counts as a failure for every message you send, from every server, until it's fixed. This walks your whole tree live and counts what it really costs you against that limit — counting mechanisms, the way a receiver does, not the number of DNS queries we happen to make while looking.
SPF lookup limit FAQ
What is the SPF 10-lookup limit?
RFC 7208 caps SPF evaluation at 10 DNS lookups. Each include:, a, mx, ptr, exists: and redirect= mechanism costs one, and lookups inside the records you include count too. Past 10, receivers stop evaluating and return permerror, which DMARC treats as an SPF failure for every message you send.
What is SPF flattening?
Replacing include: and a/mx mechanisms with the literal ip4: and ip6: ranges they currently resolve to. Because IP ranges cost no DNS lookups, this brings a record back under the limit. It is a copy of what those providers publish today, not a live reference to it — so it is correct on the day you publish it and silently wrong afterwards.
Is SPF flattening safe?
Only if something re-checks it. Providers renumber their sending infrastructure without announcing it. A flattened record keeps authorising the old addresses and silently stops authorising the new ones, so SPF starts failing for real mail with no bounce and no error naming the cause. Flattening solves a lookup problem by creating a maintenance problem — that trade is worth making only when the record is re-verified automatically.
What should I try before flattening?
Remove include: entries for services you no longer send through — on most over-limit records this alone gets you back under 10. Then check whether a provider publishes a narrower include for your use case. Flattening is the last resort, not the first move.
Why can't some mechanisms be flattened?
exists:, ptr and any mechanism containing a macro are evaluated per message against the sending IP or identity, so there is no fixed set of addresses to substitute for them. A flattened record just drops them, which narrows who is allowed to send as you. This tool reports each one and refuses to call the result safe to publish.
My SPF record uses a macro. Is that a problem?
No. A macro (you will see %{ } in the record) means the policy is worked out per message rather than from a fixed list, which is the normal arrangement for large senders — roughly half the Fortune 50 publish one, mostly via Proofpoint, Valimail, Cisco or Agari. It costs one DNS lookup no matter how many servers you send from, and no tool can flatten it, ours included. It does not mean your record is correct either: a dynamic policy can still be misconfigured. It only means a static replacement is the wrong instrument.
Why would you not show me a flattened record?
Because we could not prove it means the same thing. Every record we generate is evaluated against your live policy at a set of probe addresses — each end of every range, the addresses just outside them, and addresses outside all of them — and it is only shown if a receiving mail server would reach the same verdict on both. If any address disagrees, that is a change in who may send as you, so we withhold the record and tell you which address disagreed. This check exists because our own generator was once turning a record ending in ?all, +all, or nothing at all into one ending -all, which rejects mail the original permits.
Do you store my domain or my record?
We do not store the domain you check or the record we read — the lookups run live over public DNS and the result is not written down anywhere. For abuse control we do keep a short-lived counter of how many checks an IP address has run in the current hour; it expires about an hour later and is used for nothing else. If you want the record re-checked on a schedule instead of by hand, you can enroll a domain for free monitoring — that is the only path that stores anything lasting.