What this SPF check tests
The tool reads your domain's SPF TXT record straight from DNS and evaluates it against RFC 7208. It checks not merely whether a record exists, but whether it actually holds up:
- Record syntax — does it start with
v=spf1, are all mechanisms valid, are there terms afterallthat will never be evaluated? - DNS lookup limit — SPF permits at most 10 DNS-querying mechanisms. The tool follows every
includeandredirectrecursively and counts the real total, not just the terms in your top-level record. - Void lookups — queries that resolve to nothing (NXDOMAIN or an empty answer). More than two are a
permerrorunder the RFC, and a permerror behaves like having no SPF at all. - all qualifier —
-all,~all,?allor none: this decides what a receiving server does with unauthorized senders. - Sub-limits — the
mxandptrmechanisms may each return at most 10 records.
The lookup limit is the most common failure
The 10 DNS lookups are a recursive budget. A single include: in your own record can trigger five more includes at the provider — none of which is visible in your own DNS entry. That is exactly why this tool counts the whole chain and shows you which term came from which record.
Exceed the limit and conforming receivers return permerror. The outcome is not "SPF partially applies" but: SPF counts as unevaluated — including the knock-on effect for DMARC, which can then only pass via DKIM.
What this check cannot see
A DNS check knows your domain, not your email. Whether SPF actually returns pass for a given message depends on the sending IP and the envelope-from address — both of which only exist in the message itself. The same goes for the DKIM signature, DMARC alignment, the sending IP's blacklist standing and the TLS path.
For that you need a real message: send any email to hello@analyzemy.email and you get a report covering all 22 checks back within seconds — including the SPF evaluation for the exact IP you send from.