Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — SPF Checker

See every lookup a receiver counts.

Expand any domain's SPF into a recursive include tree, count your DNS lookups against the 10-lookup limit, catch void lookups and syntax traps, and preview a flattened record. Evaluated the way a mailbox server does — in your browser, nothing sent.

Request infrastructure review The 10-lookup limit

Expands includes recursively over DNS-over-HTTPS, counts lookups and void lookups, and previews a flattened record. Nothing is sent or stored.

/ What this does

An SPF record lists who may send mail as your domain, and it silently fails when evaluating it takes more than ten DNS lookups. This checker expands every include and redirect into a recursive tree the way a receiving server does, counts each DNS-querying mechanism against that ten-lookup limit, flags void lookups against their separate limit of two, checks the syntax and the all qualifier, and previews a flattened version — so a record that looks fine in your DNS panel but breaks in the real world shows its true cost here.

The tree shows where each lookup is spent, so you can see which include is inflating the count instead of guessing. The verdict tells you whether the record passes, is close to the edge, or already exceeds the limit and returns a PermError. And the flattened preview shows the shortcut and its cost — fewer lookups, more maintenance — so you can decide with the trade-off in front of you.

  • Include tree

    Every include and redirect expanded recursively, with the lookup cost of each branch, so you see where the 10-lookup budget goes.

  • Void lookups

    Detects includes that resolve to nothing, against the separate two-void-lookup limit most checkers never surface.

  • Flatten preview

    Resolves your includes to plain IPs and shows the flattened record — with the maintenance catch stated plainly, not hidden.

  • Browser-only

    Every lookup is a read-only DNS-over-HTTPS query. Nothing is sent to us, no email is dispatched, your domain isn't logged.

/ The 10-lookup limit

Why does a valid SPF record still fail?

SPF caps evaluation at ten DNS-querying mechanisms, and the limit is cumulative across the entire tree, not per record. You get ten lookups for the whole evaluation, and every include, a, mx, ptr, exists, and redirect spends one — while ip4, ip6, and all cost nothing. The reason a record looks fine and still fails is that the cost is hidden inside the includes: one include:_spf.google.com can pull in several nested lookups of its own.

This is why the failure appears in the real world but not in your DNS panel. A record with four includes looks short, but if those includes reference other includes, a receiver expanding the full chain can cross ten and return a PermError — the permanent failure that makes SPF stop authenticating your mail. It usually happens gradually: a team adds Google Workspace, then Microsoft 365, then a marketing platform, then a CRM, each one saying just add our include, until the record is technically valid but operationally dead.

There's a second, separate ceiling most tools ignore: void lookups. A mechanism that resolves to nothing — an include pointing at a domain that dropped its SPF — counts against a limit of two, and going over fails the record just as surely. Stale includes for services you no longer use are the quiet culprit. The fix for both limits is the same first move: expand the tree, see where the lookups go, and remove what you don't need before reaching for anything more drastic.

/ Flattening

Should you flatten, and what does it cost you?

Flattening replaces your includes with the raw IP addresses they resolve to. Since ip4 and ip6 mechanisms cost no lookups, a fully flattened record can hold dozens of senders and still evaluate in zero lookups. The preview in the tool shows exactly this: your includes resolved down to a single list of IPs, ready to publish. It's the one technique that reliably gets a bloated record under the limit.

The catch is maintenance, and it's not small. Providers change their sending IPs regularly, and the moment they do, your flattened record is stale — it still lists the old IPs, so legitimate mail from that provider starts failing SPF with no error in your DNS at all. A flattened record is a snapshot of infrastructure that keeps moving. You've traded a lookup problem you could see for a drift problem you can't, and the only safe way to run it is to re-resolve and republish every time a provider's IPs shift.

So flatten last, not first. Clear out dead includes, drop ptr, replace mx with explicit IPs where hosts are stable, and move noisy senders onto subdomains with their own SPF budget — those fixes reduce lookups without adding fragility. Reach for flattening only when the cleaner moves run out, and only if you have a way to keep the IPs fresh. Keeping a flattened record accurate as providers rotate IPs is continuous work, and it's the kind of thing a managed sending setup handles so your SPF doesn't quietly rot.

/ SPF FAQ

What does the SPF checker actually do?
It fetches the SPF record at your domain apex, then evaluates it the way a receiving mail server does: it expands every include, redirect, a, and mx recursively into a tree, and counts each DNS-querying mechanism against the ten-lookup limit set by RFC 7208. It shows the running total, flags void lookups (includes that resolve to nothing), checks the syntax and the all qualifier, and previews what your record looks like flattened to plain IPs. You see whether the record exists and, the part that actually matters, whether it will evaluate without a PermError.
What is the 10-lookup limit and why does it break SPF?
RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms — include, a, mx, ptr, exists, and redirect all count, while ip4, ip6, and all do not. The limit is cumulative across the whole tree: you don't get ten lookups per include, you get ten for the entire evaluation. When a record goes over, receivers return a PermError and treat your mail as unauthenticated, which breaks SPF alignment and drags down DMARC. The trap is that the record still looks fine in your DNS panel — the failure only appears once a receiver expands every nested include. This checker expands them for you and shows the real total.
What is a void lookup?
A void lookup is a DNS query in your SPF evaluation that returns nothing — NXDOMAIN or an empty answer, usually from an include pointing at a domain that no longer publishes SPF. RFC 7208 caps void lookups at two, separately from the ten-lookup limit, to prevent abusive DNS behavior. Stale includes for services you stopped using are the usual cause, and most checkers don't surface them, so they silently eat your void budget until SPF fails. This checker flags every void lookup it finds in the tree.
Should I flatten my SPF record?
Flattening replaces include mechanisms with the actual IP addresses they resolve to, which removes their DNS lookups and gets you under the limit. It works, and the preview here shows you the flattened record — but it comes with a real catch: when a provider changes its sending IPs, your flattened record is instantly out of date, and mail from that provider starts failing SPF until you update it by hand. Flattening trades a lookup problem for a maintenance problem. It's the right tool when you've exhausted the cleaner fixes — removing dead includes, dropping ptr, moving noisy senders to subdomains — and only if you can keep the flattened IPs fresh. Doing that automatically is what a managed setup handles for you.
What's the difference between ~all and -all?
The all mechanism at the end sets the default for anything not matched. -all is a hardfail: receivers are told mail from any other source is not authorized, which is the enforced end state you want. ~all is a softfail: it suggests the mail is unauthorized but leaves the decision to the receiver, useful while you're still confirming every legitimate source is listed. +all authorizes the entire internet and should never be used — it makes the record worse than having none. Move to -all once your reports confirm all real senders are covered.
Does the checker send or store anything?
No. Every lookup runs in your browser as read-only DNS-over-HTTPS queries — the same resolution a receiver performs when it evaluates your SPF. Nothing is sent to our servers, no email is dispatched, and your domain isn't logged. The flattening preview is computed locally from the IPs your includes resolve to.

Getting under ten lookups is a project. Staying there is the work.

SPF drifts every time you add a sender or a provider rotates its IPs. Keeping the record lean, aligned, and under the limit as your sending grows is continuous — and it's exactly what we operate. Check your record, then bring us the ramp.

Book infrastructure review

Related capabilities