What it means
SPF is a DNS policy a domain publishes so receivers can check whether a connecting host may use that domain in the envelope. The identity under test is the SMTP MAIL FROM domain, or the HELO or EHLO name when the envelope sender is empty. The receiver compares the client IP address with the published mechanisms. A pass is explicit authorization of that host for that identity. A fail is an explicit denial. A softfail is a weaker statement that the host is probably not authorized. None means no usable record was found.
RFC 7208, April 2014, is the Standards Track specification and obsoletes RFC 4408. Later RFCs update it. Those updates are not restated here. SPF does not examine the visible From header, the display name, or whether a person intended the message. It also does not decide that a message is safe to act on.
See the idea / Email
One domain policy. Two sending hosts.
The receiving mail server compares the connecting IP address with the policy for the MAIL FROM domain.
Illustrative connections: both use MAIL FROM bounce@chronos.orbital. The domain publishes one SPF TXT record: v=spf1 ip4:192.0.2.8 -all.
01 / 04
First host
A connection arrives from 192.0.2.8. Its MAIL FROM address is bounce@chronos.orbital, so the receiver checks chronos.orbital’s SPF policy.
More about this step
The connecting IP is observed by the receiver. MAIL FROM is the SMTP envelope sender, which can differ from the visible From header. This example uses a nonempty MAIL FROM; the null-envelope HELO case is omitted.
Step through at your own pace.
Keep in mindThis simple policy has two outcomes; SPF has other results and mechanisms. An SPF pass does not establish the visible From address, a person’s identity, or message safety. DNS exchange and delivery decisions are omitted.
Read the visual, step by step
- First host. A connection arrives from 192.0.2.8. Its MAIL FROM address is bounce@chronos.orbital, so the receiver checks chronos.orbital’s SPF policy. The connecting IP is observed by the receiver. MAIL FROM is the SMTP envelope sender, which can differ from the visible From header. This example uses a nonempty MAIL FROM; the null-envelope HELO case is omitted.
- Policy. The receiver retrieves chronos.orbital’s published record. Its ip4 rule allows 192.0.2.8; the final -all rule fails every other IP. The domain owner publishes the record in DNS before this connection. The line in the picture links the check’s inputs; it is not a DNS packet. Mechanisms are tested from left to right, stopping at the first match.
- Match. 192.0.2.8 matches the ip4 rule. Evaluation stops there with SPF pass: this host is allowed to send for the checked MAIL FROM domain. The ip4 mechanism has an implicit + qualifier and a default /32 prefix here. The later -all mechanism is never evaluated for this connection. SPF’s result is separate from the receiver’s delivery decision.
- Other host. Now a different connection arrives from 192.0.2.9 with the same MAIL FROM domain. It misses ip4, reaches -all, and gets SPF fail. Only the connecting IP changed. The domain policy and MAIL FROM identity stayed the same. This is a new connection, not a reversal of the earlier pass. The - qualifier on the matching all mechanism produces fail.
This simple policy has two outcomes; SPF has other results and mechanisms. An SPF pass does not establish the visible From address, a person’s identity, or message safety. DNS exchange and delivery decisions are omitted.
Flow references: RFC 7208: SPF evaluation and mechanisms · RFC 5737: documentation addresses
AN ILLUSTRATIVE SCENARIO
Meridian Mail lists its senders
Meridian’s synthetic domain chronos.orbital sends finance notices from one application and payroll mail from a vendor. Vera writes both hosts into the SPF record before she talks about inbox logos. A pass on a payroll message means that vendor’s IP was authorized for the envelope identity. It does not mean the visible From was finance@chronos.orbital, and it does not approve a bank change inside the body.
Put it to work
- List every host and vendor that sends mail using the domain’s envelope identity, including quiet tools such as ticket mail and password resets.
- Publish an SPF TXT record for that domain and decide what unmatched hosts should receive: fail, softfail, or a neutral result you can explain.
- When a message matters, record which identity SPF checked and the result. Do not describe that result as proof of the header a person saw.
How to check your work
For a synthetic domain, name the MAIL FROM or HELO identity, the published record, and whether a test host’s IP is inside it. State one thing the result does not prove about the visible From.
Connect the ideas
- DNS
The lookup system that maps a name people type to an address a computer can contact.
- DKIM
A signature that lets a domain claim responsibility for selected message content, checked with a public key in DNS. A valid signature ties that signing domain to the signed bytes. It does not prove a human wrote the display name.
- DMARC
A DNS policy that checks whether the visible From domain aligns with a domain SPF or DKIM authenticated, and that publishes a handling preference plus reporting. A pass is authorized use of that domain, not a safety verdict.