What costs a lookup
include, a, mx, ptr, exists and redirect. Note that bare a and mx, with no colon, cost one each — they are the terms a naive checker misses.
RFC 7208 allows ten DNS lookups while evaluating an SPF record. The limit applies to the whole evaluation, which means everything inside every include — so the number cannot be read off your own record, and a checker that only looks at your record will tell you a broken configuration is fine.
include, a, mx, ptr, exists and redirect. Note that bare a and mx, with no colon, cost one each — they are the terms a naive checker misses.
ip4, ip6 and all need no query at all, which is why replacing an include with the ranges it publishes is the usual way to get back under the limit.
Receivers return permerror, and most treat permerror as no SPF at all. The record stops protecting the domain, and nothing about your own sending changes to tell you.
Every provider's include contains their own includes, and they change them without telling you. A record at nine lookups can break because a vendor added one at their end.
It resolves your record, then every include and redirect inside it, recursively, and counts each DNS-querying term as it goes — which is what a receiving mail server does. The tree is shown below the findings with the cost of each node, so you can see where the lookups are rather than taking a total on trust.
A few details that change the number. redirect= is ignored entirely when an all mechanism is present, per §6.1, so it costs nothing in that case — several checkers charge for it anyway. Terms containing macros such as exists:%{i}... are counted but not followed, because their target depends on the message being evaluated and there is no name to query.
Two SPF records on one domain is reported before anything else, because it is a permanent error on its own: receivers do not pick one, they fail the check. It happens whenever a second mail provider is added and appends its own record instead of merging into the existing one — and it leaves the domain worse off than publishing no SPF at all.
Usually because the other one counted only the terms visible in your record. The limit applies to lookups performed during evaluation, so everything inside every include counts too. The other common difference is bare a and mx mechanisms — they cost a lookup each, and a checker matching on "a:" and "mx:" finds neither. The tree below the results shows exactly where our figure comes from.
Remove senders that are no longer used — that usually finds one or two. Then replace an include with the ip4 and ip6 ranges it publishes, which costs nothing to evaluate; the trade-off is that you must update it when the provider changes their ranges. Consolidating multiple providers onto one is the durable fix.
-all is stronger: unlisted senders fail outright. ~all soft-fails, and most receivers accept the mail and mark it. If DMARC is published at p=reject, ~all is a perfectly normal choice because DMARC is doing the enforcing. What is never right is +all, which authorises every host on the internet and is worse than no record.
No, on its own. SPF authorises the envelope sender used in the SMTP conversation, which nobody sees. The From address shown in a mail client is in the message header and SPF never looks at it. DMARC is the part that requires those to align and tells receivers what to do when they do not.
A lookup that returns no record — a typo in an include, or a provider's hostname that no longer exists. RFC 7208 allows two before the record becomes a permanent error, separately from the ten-lookup limit. This checker reports includes that do not resolve to a usable record individually, because each one is a fault worth fixing regardless of the count.
Getting to an enforced DMARC policy means finding every system that sends as you — the CRM, the invoicing platform, the scanner in the corner — and authorising them before you tell the world to reject the rest. We do that migration, and then the inbound side that display-name spoofing walks straight past.