SPF Checker

Two records for example.com and what the checker reports for each.

Static IP ranges only

v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 -all

Result: 0 / 10 DNS lookups, 3 mechanisms, 2 sending sources, policy -all · HardFail, and all seven validation checks pass. ip4, ip6 and all never cost a lookup.

Provider include plus MX

v=spf1 include:_spf.example.net mx ~all

If _spf.example.net publishes v=spf1 ip4:198.51.100.0/24 ~all, the DNS lookup chain looks like this:

example.com  v=spf1
├─ include:_spf.example.net    +1
│  ├─ ip4:198.51.100.0/24       0
│  └─ ~all                      0
├─ mx                          +1
└─ ~all                         0

Total: 2 / 10 lookups. The record is still marked Valid, but the enforcement check asks for review because ~all (SoftFail) only flags unauthorized mail. Provider includes often nest further includes, so one include can cost several lookups.

• Status badges — Valid means no check failed (items to review can still be present); Issues means at least one check failed. The policy badge shows the qualifier of the top-level all term: -all HardFail, ~all SoftFail, ?all Neutral, +all Pass, or none when the record has no all term.
• DNS lookups — the counted total against the limit of 10. The gauge changes to a warning colour at 8 lookups and to an error colour above 10.
• Mechanisms and Sending sources — the number of terms in the top-level record, and how many of them are ip4, ip6 or include terms.
• Validation — seven checks: exactly one SPF record, the v=spf1 version tag, the lookup count, the enforcement qualifier, no +all, no deprecated ptr, and the TXT answer size against the 450-octet guideline of RFC 7208.
• Mechanisms table — every term with its qualifier (Pass, Fail, SoftFail or Neutral), its value, and +1 when it costs a DNS lookup.
• DNS lookup chain — include and redirect targets resolved recursively and nested under their parent, followed by the raw TXT record.

• Before adding a new sender. A new CRM or newsletter platform usually means another include; check the lookup count first so it does not push the record past 10.
• After a provider migration. The mechanisms table and lookup chain make leftover includes for old providers easy to spot.
• Investigating SPF failures. When bounces or DMARC aggregate reports show an SPF permerror or unexpected fails, confirm what is actually published. The DMARC policy checker shows whether a rua address is collecting aggregate reports at all.
• Locking down domains that never send mail. Parked domains can publish v=spf1 -all: zero lookups and no authorized senders.

More than 10 DNS lookups

Too many include, a, mx, exists or redirect terms, often hidden inside nested includes. Remove includes for services you no longer use, and replace a and mx with the ip4 / ip6 ranges they resolve to when those servers are yours. Only flatten a provider include into IP ranges if you can keep the copy current: providers can change their sending ranges, and a flattened list does not update itself.

The "exactly one SPF record" check fails

Two TXT records on the domain start with v=spf1 — usually because a new provider's setup instructions were followed literally. Merge all terms into one record with a single all term at the end. The checker parses the first record it receives, so the rest of the results describe only one of them.

No SPF record found, but you published one

SPF is checked against the envelope sender (Return-Path) domain, so the record must sit on that exact hostname — usually the bare domain, not www or an spf. subdomain — and the value must start with v=spf1 as its first term. A recent change may still be cached until its TTL expires, and DNS errors such as timeouts or SERVFAIL are reported the same way as a missing record. Query the TXT record directly with the DNS lookup tool to see what resolvers return.

The policy badge shows "none"

The top-level record has no all term. If it ends with a redirect= modifier, the effective policy comes from the redirect target, which the badge does not read; check that domain separately. Without either, senders that match nothing get a Neutral result.

TXT answer size warning

A TXT query returns every TXT record at the name, so old site-verification tokens add to the size as much as the SPF record does. Above roughly 450 octets the answer may not fit in a 512-octet UDP response; receivers then have to retry over TCP, and some ignore the record when that fails. Remove TXT records you no longer need and drop includes for retired senders. The length of a single quoted string is not the issue: values over 255 characters are split into several strings in one record, most DNS panels do this automatically, and the check shows how many strings your record uses.

• It does not run a full SPF evaluation for a particular IP address or message. It shows what the record authorizes; whether a given server passes also depends on the connecting IP and the envelope sender.
• The lookup count approximates receiver behaviour: each include or redirect target is expanded once (a repeated target is counted but not expanded again), targets that do not resolve are counted without children, and expansion stops once more than 20 lookups have been counted.
• The RFC 7208 limits on void lookups (queries that return no records) and on the number of addresses an mx or ptr term may resolve are not checked, and macros such as %{i} are not expanded.
• Answers come from the DNS resolver used by the helpers.work server, so a just-published change can still show the cached value. A leading www. is removed from the input; enter other subdomains in full.
• SPF only covers the envelope sender. Check signing keys with the DKIM selector checker and the policy that ties both to the visible From: address with the DMARC record checker. The guide SPF, DKIM and DMARC explained covers how the three records work together.