SPF checker

SPF is a TXT record on your domain that lists the servers allowed to send mail using it in the envelope. A receiving server takes the connecting IP address and walks your record: ip4 and ip6 blocks name addresses directly, include pulls in another domain's list (this is how you authorize a provider), and the all at the end says what to do with everything unmatched.

SPF checks the envelope sender, the address used in the SMTP conversation, not the From address a person sees. That distinction is why SPF alone does not stop forgery of your visible From, and why DMARC exists to tie the two together.

A domain must publish exactly one record starting v=spf1. Two or more is a permanent error under RFC 7208: receivers do not pick one or merge them, they fail SPF for every message, including mail from servers each record individually allows. It is the most damaging SPF mistake, and the easiest to make: a setup guide says "add this TXT record", and the panel happily adds a second one next to the first.

The fix is a merge, not a choice. Keep one v=spf1 prefix, put every mechanism from both records into the one list, and keep a single all at the end. This checker fails multiple records loudly and shows both, because half the people searching this phrase are discovering the problem for the first time.

Evaluating an SPF record is allowed to cost at most 10 DNS lookups (RFC 7208 section 4.6.4). include, a, mx, ptr, exists and the redirect modifier each cost one, and the count is recursive: an include's own includes count too. Past 10, receivers stop and return a permanent error, so a record can fail purely by being too popular with providers. ip4 and ip6 mechanisms are free.

This is the failure that creeps up on you. Each provider's setup guide adds one include, each include costs at least one lookup, and the day you add the sixth tool nothing visibly breaks except your mail. The tree this checker renders shows where the lookups go, which is the information you need to prune: drop includes for providers you no longer use, and prefer ip blocks where a provider publishes stable ranges.

The all mechanism at the end sets the default for unmatched senders, and its qualifier is the whole difference. -all is a hard fail: unlisted servers fail SPF outright. ~all is a soft fail: receivers treat unlisted mail with suspicion but do not refuse it on SPF alone. Both are legitimate; for DMARC purposes fail and softfail count the same, so ~all costs you nothing there.

The two endings worth fixing on sight are ?all, which makes the whole record meaningless because unmatched senders get the same neutral result as having no SPF, and +all, which authorizes every server on the internet to send as you. +all is worse than no record: forged mail passes SPF with your blessing.

One TXT record, starting exactly v=spf1, mechanisms separated by single spaces, all at the end. The valid mechanisms are all, include, a, mx, ptr (deprecated), ip4, ip6 and exists, each optionally prefixed with a qualifier (+, -, ~, ?). Anything the parser does not recognize is not ignored: an unknown mechanism is a permanent error for the whole record, which is why a stray typo can take SPF down entirely.