SPF Record Checker

SPF is a list, published in DNS, of the servers allowed to send mail for a domain. It looks harmless until a company adds its tenth email service and mail starts failing for no visible reason. The cause is a limit in the specification: evaluating a record may trigger at most ten DNS queries. The page evaluates your record the way a receiver does and tells you how close you are.

How a receiver evaluates SPF

The receiving server takes the domain from the envelope sender, looks up its TXT record starting with v=spf1, and checks the connecting IP address against the terms from left to right. The first term that matches decides the result through its qualifier: + pass (the default), - fail, ~ soft fail, ? neutral. Terms such as include: start a nested evaluation of another domain’s record, and redirect= replaces the whole record with another. RFC 7208 allows at most ten terms that require a DNS lookup per evaluation (include, a, mx, ptr, exists, redirect), counting those in nested records, and at most two lookups that return nothing (void lookups). Exceeding either gives a permanent error, and receivers may treat the mail as failing.

Reading the result

The summary shows the number of SPF records found (it must be exactly one), the DNS lookups used out of 10, the void lookups out of 2, the number of IPv4 and IPv6 ranges, and how the record ends. Findings list problems: more than one record, +all (anyone may send), a loop where a record includes itself, ptr, which is slow and discouraged, and ending in ~all or -all or neither. The table “Record and includes” is the tree: each included domain with the number of lookups it adds and its record text. Macros such as %{i} are listed, not expanded.

Fixing a record that is over the limit

First remove includes for services you no longer use; each costs at least one lookup, and some providers’ records add several more behind the scenes. Second, replace a and mx mechanisms with explicit ip4: and ip6: ranges where the addresses are stable. Third, consider flattening: substituting each include with the addresses it expands to, which the page prints as a ready version. Flattened records use no lookups, but they go stale when a provider changes its ranges, so automate regeneration or choose a service that keeps it updated. Splitting senders across subdomains is a further option.

A worked example

Press Sample to check github.com. When this guide was reviewed the page found 1 SPF record, 10 of 10 DNS lookups used and 0 of 2 void lookups, with 48 IPv4 and 11 IPv6 ranges. The record ends in ~all, shown as a warning because all ten lookups are used: “adding another service may break SPF”. The tree shows the includes, such as one for Microsoft 365, two for Google netblocks, and others for support, marketing and bulk mail providers, with the lookups each adds. A result of 10 of 10 is legal but leaves no room.

Limits

The checker evaluates the record, not a specific message: it cannot say whether a particular IP address passes. It does not expand macros or check that the sender’s own envelope domain matches the visible From address, which DMARC cares about. DNS answers come from a public resolver and might be cached. Use the DMARC Checker for the policy that uses SPF’s result.

Related tools

• DMARC Checker reads the policy that depends on SPF and DKIM.
• DKIM Record Checker inspects the signing key.
• TXT Record Lookup shows the raw SPF text.
• Email Spoofing Test scores SPF with the rest of the setup.