SPF is a DNS TXT record that answers one question: is this server allowed to send mail claiming to be you? It is not inbox placement. It is not DKIM. It is the allow-list. If it is missing or broken, the rest of authentication is standing on a missing floorboard.
The checker queries live DNS for the domain you type, finds TXT records that start with v=spf1, and then reads the terms. One record is required. Two records is a permerror, which receivers treat as a fail. Fun.
The terms that matter
include: pulls in another domain’s SPF, which is how Google, Microsoft, Klaviyo, and most ESPs get authorised. ip4: and ip6: list addresses directly and do not count toward the lookup cap. a and mx authorise whatever is in those records, and they do count. The trailing all is the policy for everyone else.
The 10 lookup cap
RFC 7208 stops evaluating after ten DNS-querying mechanisms. Go over that and SPF returns permerror even if every sender is legitimate. This tool counts the top-level lookups. It does not yet flatten nested includes, so a record that looks fine here can still blow the cap once Google’s own includes are followed. If you are stacking four ESPs, assume you are closer to the edge than the number suggests.
Common ways people break it
Publishing two SPF records instead of merging them. Leaving +all in place because a random generator used it. Forgetting the ESP include after a platform migration. Using ptr, which is deprecated and slow. Copying a record from a different domain and wondering why Klaviyo mail starts failing.
If you want the full walkthrough of how SPF sits next to DKIM and DMARC, we already wrote it: SPF, DKIM, and DMARC. This page is the live lookup. That post is the why.