What an SPF record is for
Sender Policy Framework is the answer to a narrow question: is this host allowed to send mail claiming to be this domain? The record lists the hosts, the receiver evaluates it against the connecting address, and the outcome is one of four results that the receiver then weighs against other signals.
The record is published as a TXT record at the domain used in the envelope sender, which is usually the apex domain but not always. That distinction causes a large share of confusing results: a record published at mail.example.com does nothing for mail whose envelope sender is example.com, and the checker will report no record found even though a record plainly exists somewhere.
Reading the mechanisms in order
Evaluation is sequential. The receiver walks the record from left to right and stops at the first mechanism that matches. Everything after that point is not evaluated, which is why the position of all matters more than its presence: anything placed to its right is dead text.
Each mechanism carries a qualifier that decides what a match means. A + is a pass and is the default when no qualifier is written. A - is a fail, which the receiver should treat as not authorised. A ~ is a softfail, a deliberately weaker statement used during a transition. A ? is neutral, which means the domain declines to say anything at all.
The mechanisms divide into two groups by cost. Address mechanisms — ip4, ip6, a and mx — are cheap, because the address is already known and the comparison is local. Redirecting mechanisms — include, exists, ptr and redirect — cost a DNS lookup. Allocating lookups is the constraint that shapes real records, and it is the reason long chains of includes eventually stop working.
The ten-lookup limit, and why it is a cliff
RFC 7208 allows ten DNS-querying mechanisms before a receiver must stop. Note how that limit behaves: exceeding it does not produce a fail. It produces a permanent error, so the receiver cannot evaluate the record at all and treats it as broken rather than as a rejection.
That distinction explains a failure mode that confuses people. A record can be under the limit at the top level and still overflow in practice, because an include pulls in the included domain’s record and that record’s lookups count against the same budget. A common pattern is a record sitting at nine or ten because of accumulated marketing and helpdesk platforms. Adding one more silently breaks authentication for every sender.
The report above counts the lookups visible at the top level and names the mechanisms that require them, which is the part you can control directly. Counting the included records as well requires recursion, and the honest statement is that the top-level count is a floor rather than the total.
Softfail, and the transition records people forget to finish
A record ending in ~all is extremely common and is often left in place far longer than intended. A softfail tells the receiver to accept the message but mark it as suspicious. On its own that is a reasonable way to introduce SPF without risking legitimate mail that has not been accounted for yet. Left in place for years, it means every unauthorised sender is still being delivered.
The report does not score the record, because a score would hide this. It states the default result and what it means, and leaves the judgement where it belongs.
How it relates to DMARC and DKIM
SPF is one of two authentication checks DMARC can use, and it alone cannot protect a domain. The reason is the envelope sender: SPF validates the address in the transport envelope, while the message the recipient sees carries the From header. A forwarded message commonly fails SPF for that structural reason, which is why DKIM matters as well, and why DMARC exists to require at least one of them to pass.
The relationship in one line: SPF and DKIM are the evidence, and DMARC is the policy that says what to do when neither holds. The DMARC checker reads that policy, the DKIM checker probes the published keys, and the email deliverability test runs all of them together and orders the fixes.
What this page does not tell you
It does not test whether mail is actually delivered. SPF describes an authorisation claim; delivery depends on the receiver’s reputation model, reputation of the sending addresses, complaint rates and content, none of which is visible in DNS.
It does not tell you whether an address is on a blocklist. That requires querying lists that are deliberately not part of the public DNS, and it is covered by the IP blacklist check.
It does not verify that the hosts named in the record can actually send mail. A record can list a provider you stopped paying for months ago. And it does not check the reverse DNS of the sending hosts, which many receivers look at independently — the reverse DNS lookup answers that question, and the MX record check reads the reverse record of the mail route itself.