SPF record checker

What is the SPF lookup limit?

An SPF record is a line of DNS text listing who may send mail as your domain. Receiving servers evaluate it, and some of its terms require them to go and ask DNS something else: include, a, mx, ptr and exists, plus the redirect modifier. RFC 7208 puts a hard ceiling on that — implementations must limit those terms to ten during evaluation, and if the limit is exceeded they must return permerror.

Permerror is not a bounce. It means SPF did not evaluate, so your mail arrives with no SPF pass behind it, which in turn weakens DMARC and makes delivery worse in ways nobody reports back to you. Nothing errors, nothing logs, and the record still looks perfectly reasonable when you read it.

The other terms are free. all, ip4, ip6 and the exp modifier are named in the same paragraph as not causing lookups, so a record listing three hundred IP ranges costs nothing at all, while a record with eleven includes is already broken. That asymmetry is the whole game, and this page shows which of your terms spend from the budget.

How to use it

1. Paste the record. The TXT value itself, starting with v=spf1. The examples cover a simple record, a heavy one, a record broken on its own terms, and a real four-term record that is broken anyway.
2. Read the budget. Three numbers: what this record spends, the limit of ten, and how many of its terms are includes whose own cost is unknown here.
3. Read the structural checks. The things that can be settled from the text alone — a missing all, terms after all that can never be reached, +all, a dead redirect, ptr.

Why this tool cannot tell you your record is fine

Everything on this site runs in your browser, and a browser cannot make DNS queries. So this page can count the lookup-causing terms in the record in front of it and nothing more. Every include costs one lookup plus whatever its own record costs, and that second part needs DNS.

We wanted to know how much that matters, so we resolved the SPF records of the 250 busiest domains on the web and followed every include to the bottom. 198 of them publish a record. Not one exceeded ten lookups on the shallow count — and four of them exceed it once the includes are followed, so their SPF is in permerror today. A count taken without DNS found none of the four.

One of those four reads v=spf1 a mx include:iiko.ru include:amazonses.com -all. Four terms. It is the second example button on this page, and the tool reports it as spending four of ten with nothing structurally wrong, because that is all the information available without asking DNS. In reality it costs fifteen and does not evaluate.

That is why the number above is presented as a floor and never as a verdict. Across the whole survey, 86 of the 198 records hid extra lookups behind their includes — a median of two more, and up to fifteen more in the worst case. Any tool that shows you a shallow count without saying this is telling you a record at nine is safe when it may be at twenty-three.

What is worth checking here, and what needs a resolver

Plenty is decidable from the text alone, and those checks are the reason this page is worth opening. Whether the record starts with v=spf1 at all, since without it the record is simply not SPF and gets ignored. Whether it ends with an all, and which qualifier — +all authorises the entire internet to send as your domain and is almost never intended. Whether anything sits after the all, where it can never be reached, because evaluation stops at the first match and all always matches.

Also whether a redirect appears alongside an all, which makes the redirect dead: a redirect is only consulted when nothing matched. Whether ptr appears at all, which the specification advises against. And whether the record already exceeds ten lookups before any include is followed, which does happen and is unambiguous when it does.

What genuinely needs a resolver: the true lookup total, whether each include actually resolves to a record, and the void-lookup limit — the specification also says implementations should cap lookups that return nothing at two, which you cannot count without making the queries. For those, use a checker that resolves, and treat the number here as the floor it is.

One more thing this does not do: it says nothing about whether the addresses listed are the right ones. SPF is a list of who may send; no tool can tell you that the list matches your actual senders.

Why is it free?

It is string parsing and counting, running in your browser. There is no resolver to pay for and no account to create — and the absence of that resolver is stated plainly above rather than hidden.

Nothing you paste is uploaded, stored or logged. An SPF record is public DNS, so it is not secret; it is simply nobody else's business which domain you are looking at.