Why a tree, and not just a number
The home page tells you what a record costs in total. That is the number
that decides whether you get permerror, but it does not tell you
what to change. A record at fourteen lookups could be fourteen cheap includes
or three cheap ones and a single vendor costing eleven, and the fix is
completely different in each case.
This page expands the record, walks every nested include, and shows what each branch costs including everything underneath it. That is how the ten lookup limit is actually applied, and it points straight at the branch worth attacking.
What counts as a lookup
RFC 7208 allows at most ten DNS-resolving terms per evaluation.
include, a, mx, ptr,
exists and redirect= each cost one, and the count
carries down into every record they pull in. ip4, ip6
and all cost nothing at all, which is why a long record is not
necessarily an expensive one.
The count is cumulative across the whole evaluation, not per record. An include that costs six means six of your ten are gone before your own mechanisms are considered.
Reading the output
- Each block is one domain and the SPF record it publishes.
- A badge on a term is that branch's total, itself plus everything nested beneath it. Branches over three are highlighted.
- Terms with no badge are free.
- A domain marked no SPF record published is a void lookup. More
than two of those is a
permerroron its own, separately from the ten lookup limit, and they are usually leftovers from a service you stopped using.
What to do with what you find
In rough order of preference. Delete includes for platforms you no longer send from, which is more often the answer than people expect. Move an expensive vendor to its own subdomain, so its lookups come out of that subdomain's budget instead of your root domain's. If a single vendor dominates and insists on your root domain, offload that one vendor. If several are expensive, hand over the whole record.
A record already using SPF Guru
If the domain publishes the guru includes, the tree still shows the full graph, because that is what SPF Guru walks on your behalf. A receiving server performs one lookup and never sees any of it, so the total shown here is not the number that affects your delivery. The page says so when it detects this.
Notes on accuracy
Records are read from public DNS at the moment you ask, with a short shared cache, so a change made in the last minute may not appear yet. Evaluation runs in audit mode, which means it keeps counting past ten rather than stopping at the limit the way a receiver would. That is deliberate: knowing you are at seventeen is more useful than knowing you are over.
To test whether a specific server passes, use the SPF checker.