Free tool
Type a domain and see how many machines its SPF record really authorises to send email as it — with the arithmetic, the blocks the total comes from, and the include: tree each number was read out of.
The answer
Record as published
In the record itself
IPv4 addresses
IPv4 blocks
IPv6 blocks
IPv4 blocks
IPv6 blocks
Mechanisms that cannot be counted
Our lookup got no answer for these parts of the tree. That is a limit of the lookup and not a statement about those domains — and it is why the count above is a floor rather than a total.
Reading the result
Every address inside the record is a machine that could send email as your domain and pass SPF. Most of them belong to platforms doing exactly what you asked them to. The figure is not a score and there is no threshold to stay under: it is the size of the set you are vouching for, which is worth knowing before it is worth judging.
A mechanism like exists: or a: is resolved fresh for every message, so there is no list to read — the authorised set can change without the record changing a character. Where that happens the count is left blank rather than filled with a zero. Those records authorise more than a fixed list, not nothing.
A single IPv6 /32 holds 2^96 addresses. Printing that beside an IPv4 count would drown it and mean nothing, so IPv6 is only ever reported as a number of blocks. Nothing on this page turns those blocks into an address count.
Every include:, a, mx, ptr, exists and redirect= costs one DNS lookup, and the ones inside an included record count towards the same total. Past ten, receiving providers stop evaluating and the check fails — however correct the rest of the record is.
Each branch shows what it contributes on its own, including everything it includes in turn. The branches deliberately do not add up to the total: a range two providers both declare is counted once at the top. Reading down the tree is how you find out which supplier a surprising width actually belongs to.
SPF says who may send. It does not say whether a message aligned with the From address your reader sees, whether DKIM signed it, or whether it arrived at all. A record can be immaculate and the mail can still fail DMARC — that part lives in the reports.
Questions
There is no threshold, and anybody selling you one is guessing. A single email platform legitimately authorises tens of thousands of addresses. What is worth acting on is a branch you cannot account for — a supplier you stopped using, an include: nobody remembers adding — which is what the tree is there to surface.
Because part of the record could not be reduced to a list: either a branch our lookup could not read, or a mechanism that resolves per message and has no list to read at any time. Rather than present a partial count as a total, the tool says which of the two happened and leaves the number as a floor.
Not yet — ten is allowed, eleven is not. But it leaves no room at all: the next supplier you add, or an include: that grows on the provider's side without telling you, puts the record over the limit while you never touched it. That is the usual way SPF breaks.
No. No sign-up and no email address to leave. The tool allows a few measurements a minute rather than more, because a single request here can cost ten DNS queries.
No. It goes from your browser to the lookup API, which reads public DNS and answers without writing the domain to a database, a file or a log. The page keeps nothing either: no history, no browser storage, nothing handed to analytics.
Because SPF is published per name and is not inherited. mail.example.com has its own record or none at all — it does not fall back to the one on example.com. Look up the exact name your mail is sent from.
SPF says who may send as you. The DMARC reports say who did — every source named, with what authenticated and what did not. Publish one DNS record and Sentinely reads them for you, every day.