SPF email authentication

What it means

SPF (Sender Policy Framework) lets a receiving mail system evaluate whether an observed SMTP sending IP is authorized for a specific SMTP identity, commonly MAIL FROM or HELO. It reads a published policy, typically in DNS TXT, and returns a result such as pass, fail, softfail, none, temperror or permerror. A discovered but nonmatching policy yields neutral; no discovered policy yields none. SPF does not directly authenticate the visible email From address; DMARC adds an alignment requirement for that different identity.

Try it

Simulation — evaluate a bounded SPF rule. Use v=spf1 ip4:192.0.2.0/24 -all with 192.0.2.7: the ip4 rule passes. Change the IP to 198.51.100.7: -all fails. Replace -all with ~all for a softfail. Select duplicate SPF records, no record or temporary DNS error to see three distinct results. Invalid IP/prefix and unsupported mechanisms are rejected. Reset returns to the first synthetic sender.

How the mechanism works

Evaluation follows the RFC-defined mechanism order and modifiers rather than a textual search for an IP. An ip4 mechanism can authorize a matching source address; all matches anything and its qualifier sets the result (- fail, ~ softfail, + pass, ? neutral). The model covers only ip4 and all; actual SPF also has domain-based mechanisms such as include, a and mx that can trigger DNS lookups. The real protocol limits the number of DNS-query-causing terms; this is not a limit on the count of TXT records in a zone.

For the selected identity, multiple distinct records beginning v=spf1 produce a policy error rather than a valid concatenation. An absent record is none, a valid record with no matching mechanism is neutral, and a temporary lookup failure is temperror. Forwarding can change the apparent sending IP and cause SPF checks to fail despite legitimate original submission; DKIM and DMARC use different evidence and should be assessed separately.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

For a real mail-domain change, first identify the exact MAIL FROM domain used by your sending system and its legitimate outbound IPs. Inspect the existing SPF policy read-only and the official sender documentation; never add every vendor blindly. Record the previous TXT RRset and preserve unrelated verification records. Validate the proposed policy with authorized test traffic and the receiver's authentication results before wider rollout. Stop if the true sending topology or DNS-query budget is unknown; a broad +all is not a safe debugging remedy.

Limits and common mistakes

This toy evaluator does not perform DNS recursion, HELO selection, all SPF mechanisms, modifiers or full protocol processing. Domain input and IPv4 are bounded. A passing SPF check neither proves that a visible author is legitimate nor guarantees inbox placement.

Key takeaways

SPF checks an SMTP envelope identity against the connecting sender IP; it does not authenticate the visible From: header by itself. pass, fail, softfail, neutral, none, temperror and permerror carry different meanings. Never merge separate SPF TXT records or treat an unsupported mechanism as permission.