SPF email authentication

What it means

SPF permits a domain owner to specify which sending hosts are authorized for the SMTP envelope identity checked by SPF. It does not authenticate a message merely because the visible From header resembles the same domain, and a passing SPF result alone does not guarantee DMARC alignment or mail delivery. SPF standard DMARC

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.

A sending IP inside and outside an SPF rule

For the synthetic MAIL FROM domain bounce.example.com, consider:

v=spf1 ip4:192.0.2.0/24 -all

The sender 192.0.2.7 belongs to the authorized /24, so the supported ip4 mechanism returns pass. The sender 198.51.100.7 does not match and reaches -all, returning fail. Replacing -all with ~all would produce softfail for the second sender; removing the discovered SPF record gives none, not neutral.

This widget supports a deliberately narrow SPF subset, so unsupported mechanisms produce its documented permerror rather than secretly querying DNS. A pass applies to the evaluated SMTP identity; inspect DMARC separately for the visible From address.

Authorized envelope, unrelated From address

A synthetic message uses an authorized sending IP for bounce.example.test, so SPF may pass for that envelope domain. Its visible From address is billing.other.test. SPF success for the bounce domain does not automatically align with the From domain; DMARC applies its alignment logic separately. Conversely, a message can have an aligned valid DKIM signature even if the selected SPF path fails. SPF lookups and limits are defined by the policy mechanism and do not imply that a receiver must deliver or accept the mail. SPF identity DMARC alignment

In practice

For a domain you administer, inventory legitimate senders, envelope domains, current SPF policy and dependent services. Test candidate policy changes against realistic authorized sender cases and lookup behavior before publishing. Do not add unknown IP ranges just to force pass; preserve the old TXT RRset and verify both DNS presentation and actual mail authentication reports after an approved change.

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

Read SPF as one scoped authorization signal for the evaluated SMTP identity. For visible From protection, examine DMARC alignment and DKIM as separate evidence; do not equate one green result with trusted mail.