SPF (Sender Policy Framework) is an email authentication standard in which a domain owner publishes a DNS TXT record listing the servers authorized to send mail for that domain. In email infrastructure, receiving mail servers compare the IP address of the connecting server with that list and use the result to judge whether a message is likely forged. The current specification is RFC 7208.
SPF addresses one specific weakness of SMTP: the protocol itself lets any server claim any sender address. SPF does not stop that claim, but it gives receivers a verifiable policy to check it against, and it forms one of the three pillars of modern sender authentication together with DKIM and DMARC.
How an SPF check works
During an SMTP session the sending server announces an envelope sender with the MAIL FROM command, also called the return path or bounce address. The receiver takes the domain of that envelope sender, looks up its TXT record beginning with v=spf1, and evaluates the mechanisms from left to right against the client IP address. The first mechanism that matches decides the result.
When the envelope sender is empty, as with bounce messages, the receiver checks the domain given in the HELO or EHLO greeting instead. A typical record looks like v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all, which authorizes one address block plus the servers of a provider and rejects everything else.
The evaluation ends with one of several defined results. The table below lists them and the usual receiver reaction.
| Result | Meaning | Typical receiver handling |
|---|---|---|
| Pass | IP is authorized | Positive signal, not proof of legitimacy |
| Fail | IP is explicitly not authorized | Reject or strong spam signal |
| Softfail | IP probably not authorized | Accept but mark as suspicious |
| Neutral | Domain makes no assertion | Treated like no policy |
| None | No SPF record found | No SPF signal available |
| Temperror | Temporary DNS problem | Defer and retry later |
| Permerror | Record cannot be evaluated | Often treated as fail by DMARC |
SPF mechanisms and qualifiers
An SPF record consists of mechanisms that describe sets of addresses and optional qualifiers that say what a match means. The default qualifier is +, meaning pass. The closing all mechanism catches every address not matched earlier and therefore defines the policy for unknown senders.
| Mechanism | What it matches | DNS lookup cost |
|---|---|---|
| ip4 and ip6 | A literal address or CIDR block | None |
| a | Addresses in the domain’s A or AAAA records | One lookup |
| mx | Addresses of the domain’s mail exchangers | One lookup plus per-host lookups |
| include | Result of another domain’s SPF record | One lookup plus nested ones |
| exists | Any IP if a constructed name resolves | One lookup |
| all | Every address | None |
The qualifiers are + pass, - fail, ~ softfail and ? neutral. A record ending in `-all` is a strict policy, while `~all` is a cautious policy often used during rollout. The ptr mechanism is deprecated because it is slow and unreliable and should not be used in new records.
SPF compared with DKIM and DMARC
SPF authenticates the sending path, not the message content and not the address a reader sees. That gap is why it works best alongside DKIM and DMARC, each of which covers a different part of the problem.
| Standard | What it verifies | Identity checked | Survives forwarding |
|---|---|---|---|
| SPF | Sending server is authorized | Envelope sender domain | Usually not |
| DKIM | Message was signed and not altered | Signing domain in d= tag | Usually yes |
| DMARC | Visible From domain aligns with SPF or DKIM | Header From domain | Depends on DKIM |
The visible From address is the critical point. SPF can pass for a bounce domain belonging to a newsletter provider while the From header shows a bank. Only DMARC alignment ties an SPF pass to the domain the recipient actually reads.
Publishing and maintaining an SPF record
Each domain may publish exactly one SPF record; two v=spf1 records produce a permerror. Start by listing every system that sends mail with the domain in the envelope sender: the main mail server, marketing platforms, ticketing systems, invoicing software and cloud services. Domains that never send mail should publish `v=spf1 -all` to make spoofing them less attractive.
| Situation | Recommended record ending | Reason |
|---|---|---|
| Initial rollout with unknown senders | ~all | Limits damage from a missed sender |
| Inventory complete and monitored | -all | Clear signal against forged mail |
| Domain that sends no email | v=spf1 -all | Declares that no server is authorized |
| Many third-party senders | Subdomains per service | Keeps each record within lookup limits |
Limitations and common mistakes
The most frequent technical failure is the limit of 10 DNS lookups per evaluation. Every include, a, mx, exists and redirect counts, including nested ones, and exceeding the limit yields a permerror that receivers may treat as failure. A second limit of two void lookups catches records that point at names that no longer exist.
- Forwarding breaks SPF, because the forwarding server is not in the original domain’s record; SRS rewriting or DKIM must cover this case.
- SPF alone does not protect the From header, so it cannot stop display spoofing without DMARC.
- Overly broad entries such as large provider ranges or
+alleffectively authorize strangers. - Flattening includes into IP lists avoids the lookup limit but goes stale when providers change addresses.
- Forgotten senders such as a new billing tool cause legitimate mail to fail after
-allis enforced.
Understanding it simply
Imagine a company that posts a public list at its front gate naming the only couriers allowed to deliver parcels in its name. Anyone receiving a parcel that claims to come from the company can check whether the courier is on that list.
SPF is that list for email. A domain writes down which mail servers may send for it, and receiving servers check each incoming message against it. It does not prove that a message is honest, and it does not check the sender name a person sees, but it makes simple forgery easier to spot.
Applied in practice
An online shop sends order confirmations from its own server, newsletters through a marketing platform and invoices through an accounting service. Customers report phishing emails that pretend to come from the shop. The administrator publishes one record containing ip4:203.0.113.10 plus an include entry for each of the two services, and ends the record with ~all while monitoring DMARC reports for two weeks.
The reports reveal one forgotten sender, a support desk tool, which is added. The record now needs seven DNS lookups, safely under the limit, so the ending is changed to -all. Combined with DKIM signing and a DMARC policy of quarantine, forged messages using the shop’s domain are now filtered by major mailbox providers, while legitimate mail continues to arrive.