SPF Monitor
SPF lets you publish the list of servers authorized to send mail from your domain. Two things commonly break it: a record that ends in +all (which permits anyone), and a record whose include chain triggers more than the RFC 7208 limit of 10 DNS lookups. Both leave the domain effectively unprotected.
What we check
A live TXT lookup at the zone apex, filtered to records starting with v=spf1. RFC 7208 allows only one SPF record per domain, so multiple matches are themselves a failure.
For the matched record we extract the all qualifier (+all, -all, ~all, ?all) and recursively count the DNS lookups triggered by a, mx, ptr, exists, include, and redirect mechanisms. The recursion expands include: targets transitively, since they contribute to the same 10-lookup budget.
Why it matters
A record with +all is worse than no record — it actively claims that any server is authorized to send for your domain. The lookup limit is more subtle: when the budget is exceeded, receivers treat the SPF result as permerror, which under DMARC alignment is treated as a failure. The chain typically grows over time as you add SaaS tools (each include: directive can pull in two or three transitive lookups of its own).
Status outcomes
A single SPF record exists, it ends in a non-permissive all qualifier (-all or ~all), and the lookup count is under 10.
Lookup count is at 9 or 10 (one more include will break the record), the record uses ?all (offers no protection), or the record is missing its terminal all mechanism.
No SPF record exists, multiple SPF records are published, the record uses +all (permits any sender), or the lookup count exceeds 10.
How to fix
Replace +all with -all (hard fail) or ~all (soft fail) — the latter is a softer landing while you're still tuning. For exceeded lookup limits, the typical answers are SPF flattening (resolving include directives down to bare IPs once and refreshing periodically), consolidating senders behind a single relay, or removing unused includes left over from old SaaS tools.