SPF Checker

Sender Policy Framework (RFC 7208) is a DNS TXT record that lists which mail servers are allowed to send email claiming to be from a domain. When a receiving mail server gets a message, it checks the envelope sender's domain, fetches its SPF record, and evaluates the connecting IP address against the mechanisms in that record.

SPF alone does not stop spoofing - it only tells a receiver whether the sending server was authorized. It becomes effective as an anti-spoofing control when combined with DMARC, which decides what happens to mail that fails the check.

• A domain publishes exactly one SPF record, always a TXT record starting with v=spf1
• Mechanisms are evaluated left to right; the first match decides the outcome
• The record has no bearing on inbound mail - it only authorizes outbound senders for the domain

A typical record looks like this: v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all

Each token after v=spf1 is a mechanism. Common ones: ip4 and ip6 authorize specific addresses or ranges directly, a and mx authorize the domain's own A/MX-resolved hosts, include pulls in another domain's SPF record (typically a mail provider's), and all is the catch-all that matches everything not already matched.

A qualifier can prefix any mechanism: + (pass, default if omitted), - (fail), ~ (softfail), ? (neutral). The qualifier on the all mechanism is what most guides mean when they talk about "SPF strictness."

-all (hardfail) tells receivers to reject mail from any server not explicitly listed. ~all (softfail) tells them to accept it but mark it as suspicious, typically by adjusting a spam score rather than rejecting outright.

Most SPF rollouts start with ~all while the sending infrastructure is being mapped, then move to -all once every legitimate source - including CRM tools, invoicing platforms, and internal scripts - is confirmed to be in the record. A record with no all mechanism at all, or one using +all, provides no real control: +all authorizes every server on the internet to send as the domain, which SPF exists specifically to prevent.

RFC 7208 caps SPF evaluation at 10 DNS lookups per check. The mechanisms that count toward this limit are include, a, mx, ptr, and exists - each one triggers at least one additional DNS query when the record is evaluated. ip4 and ip6 do not count, since they need no lookup.

Nesting is the usual cause of an overrun: an include: pointing to a provider's SPF record inherits that provider's own lookups, and a chain of three or four providers (email marketing, helpdesk, CRM, transactional mail) each contributing their own includes and a/mx mechanisms adds up fast. Once the count exceeds 10, RFC 7208 requires evaluators to return a permerror, and most receiving servers then treat the record as if it failed - the opposite of what the domain owner intended.

Flattening the chain - replacing includes with the literal ip4/ip6 ranges they resolve to - removes the lookup cost but requires re-flattening whenever the provider rotates its sending IPs, so it trades a compliance problem for a maintenance one.

The checker groups its findings under an SPF category alongside DMARC, DKIM, MX, and blacklist results. "SPF Record Found" confirms a v=spf1 TXT record exists and shows the raw string. "SPF Syntax" passes when the record starts correctly with v=spf1. "SPF All Mechanism" reports which qualifier the all mechanism uses and reflects that back as pass, warning, or fail depending on whether it is -all, ~all, or +all/missing. "SPF Mechanisms" flags whether the record actually authorizes any sending servers at all. "SPF DNS Lookups" counts the lookup-consuming mechanisms and turns to a warning past 7 and a fail past the 10 limit.

If no v=spf1 record is found, or if the domain publishes more than one, the checker reports it as a single failing result rather than walking through every sub-check - a domain cannot have a valid SPF posture with zero or duplicate records, so the rest of the analysis would be moot.