Free tool · Resolves the whole tree
Your SPF record has a
budget of 10
SPF silently dies at 11 DNS lookups — and every include hides more includes. See your full tree, your true count, and exactly what to remove.
How SPF breaks without telling you
The limit counts the whole tree
include:_spf.google.com looks like one lookup. It's four — Google's record pulls in three netblock includes of its own. Most over-limit records got there one innocent include at a time.
permerror means 'no SPF at all'
Receivers don't partially evaluate an over-limit record. They throw it away entirely — and with DMARC published, mail that would have passed starts failing authentication.
Old vendors haunt your record
That marketing platform you left in 2024 is probably still in your SPF. Every dead include wastes lookups and is one more party allowed to send as you.
One record, ever
Two TXT records starting with v=spf1 is itself a permerror. Merge mechanisms into one record — never publish a second.
Questions, answered honestly
What is the SPF 10-lookup limit?
RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include:, a, mx, ptr, exists and redirect= in your record — and inside every record those includes pull in — costs one. Past 10, receivers stop evaluating and return permerror, which means your SPF effectively doesn't exist. It's the most common invisible SPF failure, because the record still looks fine to the eye.
Why does my lookup count keep growing when I only added one include?
Because includes nest. include:_spf.google.com costs 1 lookup itself, then Google's record contains three more includes — so 'adding Google' really costs 4. This checker resolves the entire tree so you see the true total, not just the top level.
How do I get under the limit?
Three honest options: remove includes for services you no longer use (the most common win), use dedicated subdomains for different mail streams (marketing.yourdomain.com gets its own SPF), or use a flattening service that replaces includes with raw IPs — with the caveat that flattened records go stale when providers change IPs.
What's a void lookup?
An include or exists that points at a name with no SPF record at all. RFC 7208 allows at most two; more than that is a permerror. Void lookups usually mean a provider you removed years ago whose include is still in your record.
Should my record end in ~all or -all?
Either is fine for deliverability today, because DMARC made the difference mostly academic — receivers care that SPF passes and aligns. ~all (softfail) is the safer choice while you're still mapping who sends for you; -all once you're certain. What's never fine: +all (allows everyone — some registrars' default!) and ?all (says nothing).
Keep going
More free tools
Records drift. We watch them for you.
Norbelys verifies SPF, DKIM and DMARC on every domain you connect and keeps watching after — when a record drifts past the limit, you hear it from us, not from your bounce rate.
Start sendingFrom $29/mo · Cancel anytime