SPF check: is your SPF record valid and under the 10-lookup limit?

This tool parses your domain’s SPF (Sender Policy Framework) TXT record with AdminKit’s own code — no third-party mail-auth library — following every include, a, mx, ptr, exists and redirect term it finds, including through nested includes, to count how many DNS lookups evaluating the record actually costs.

If your domain has no SPF record yet, or you want to draft one before publishing, AdminKit’s SPF record generator assembles the TXT record string in your browser.

Why the lookup count matters

RFC 7208 caps SPF evaluation at 10 DNS lookups (§4.6.4, “DNS Lookup Limits”) specifically to bound the cost of checking a single record. A record that exceeds the limit is treated by receivers as a permanent error (“permerror”) — mail authentication effectively stops working for the whole domain, often silently, until someone notices deliverability dropping. Common causes are stacking too many third-party mail-sending services (include:) without consolidating them.

Reading the “all” mechanism

The trailing all term decides what happens to mail that matches nothing else in the record:

• -all — fail: reject mail that doesn’t match.
• ~all — softfail: flag it as suspicious, but don’t reject outright.
• ?all — neutral: no real effect.
• +all — pass: anyone can send as this domain, almost always a mistake.

No all term at all behaves like ?all.

-all, ~all, ?all and +all only describe the trailing mechanism, not the full set of outcomes a check can return — see what an SPF check result actually means for all seven possible results, including PermError and TempError.

Limits

• This checks syntax and lookup count, not whether a specific sending IP would pass or fail — that depends on the full mechanism list and is better observed from real delivery reports (DMARC rua, defined in RFC 9990).
• No query is logged; see /legal/privacy/.
• This resolves your domain’s live record over DNS. To check a record’s syntax and lookup-causing term count from text alone — before it’s published, or one copied from a vendor’s setup docs — use the offline SPF validator instead; it never performs a DNS lookup.

SPF is only one of three records that work together for mail authentication — see SPF, DKIM and DMARC explained for how it combines with DKIM and DMARC.

If a specific message already failed and you want to see what the receiving server itself reported, rather than re-checking your live DNS record, AdminKit’s email header analyzer reads that message’s raw Received chain and Authentication-Results header directly, entirely in your browser.

If this check comes back with a permerror for too many DNS lookups, see fixing SPF “too many DNS lookups” (PermError) for what triggers the RFC 7208 10-lookup limit and how to flatten it. RFC 7208 also caps a related but separate count — void lookups, DNS queries that come back empty or NXDOMAIN — at 2, tracked apart from the 10-lookup total. See also the glossary entry for SPF, and how AdminKit’s free checker compares to other options in the free SPF/DMARC checker roundup.