ConfiguRadar

SPF checker

Parses your SPF record, resolves the full include chain, and shows exactly how many of the ten permitted DNS lookups you use and where they go.

The lookup limit is the thing that breaks

RFC 7208 §4.6.4 limits SPF evaluation to ten DNS-querying terms. The terms that count are include, a, mx, ptr, exists and the redirect modifier. all, ip4 and ip6 are free.

The part that catches people out: the limit applies to terms evaluated across the entire chain your record expands into, not the terms you can see in your own record. An include of a provider that itself includes two more costs you three, not one. A record with six visible includes can be over the limit.

Exceeding it is not a warning. Evaluation returns permerror and no sender obtains an SPF pass. This checker resolves the whole chain and prints it, so you can see which provider is consuming the budget rather than guessing.

Other things that silently break SPF

  • Two records. More than one SPF record at the same name produces permerror. This usually happens when a new service is onboarded and adds its own record rather than editing the existing one. It is worse than having no SPF, because you believe you have one.
  • Void lookups. More than two lookups returning nothing also produces permerror. Usually leftover includes for services that were removed.
  • No terminal mechanism. Without all, evaluation ends in neutral, which asserts nothing.
  • +all. Authorises the entire internet. Almost always a placeholder that escaped.

Reducing lookups

  • Remove services that no longer send. This is usually the biggest win and costs nothing.
  • Replace a broad include with the specific ip4/ip6 ranges it resolves to, at the cost of having to maintain them when the provider changes.
  • Move a bulk sender to its own subdomain with its own SPF record and its own budget.

Related