SPF (Sender Policy Framework) explained
SPF is a DNS-based email authentication standard that lists which servers may send mail for a domain. How it works, what it protects, and where it falls short.
SPF (Sender Policy Framework) is an email authentication standard that allows a domain owner to publish, in DNS, the list of servers authorized to send email on the domain's behalf. Receiving mail servers check the connecting server's IP address against that list and use the result to help decide whether a message is legitimate. SPF is defined in RFC 7208 and is one of the three core email authentication mechanisms alongside DKIM and DMARC.
What problem SPF solves
SMTP, the protocol that moves email, performs no sender verification of its own: any server can claim to send mail from any domain. SPF closes part of that gap. By publishing an SPF record, a domain owner gives every receiver in the world a way to distinguish mail from authorized infrastructure from mail sent by an impostor using the domain in the envelope sender.
The protection is scoped, and the scope matters. SPF validates the envelope sender (also called MAIL FROM, Return-Path, or bounce address), not the From address a human reads in their mail client. A message can pass SPF while displaying any From header whatsoever. Tying authentication to the visible From address is DMARC's job, which uses SPF as one of its two inputs through a rule called alignment.
How an SPF check works
The evaluation, step by step
- 1
A server connects and states its envelope sender
The sending server issues MAIL FROM:<bounce@example.com>. The receiver notes the connecting IP address and the domain in that envelope address.
- 2
The receiver fetches the SPF record
It queries DNS for TXT records at example.com and selects the one starting with v=spf1.
- 3
Mechanisms are evaluated left to right
Each mechanism in the record (ip4, include, mx, and so on) is tested against the connecting IP until one matches.
- 4
The matching mechanism's qualifier decides the result
A match on a mechanism with - produces fail, ~ produces softfail, + (the default) produces pass. If nothing matches, the all mechanism at the end catches the evaluation.
- 5
The receiver acts on the result
The result feeds spam filtering and DMARC evaluation. Few receivers reject mail on SPF fail alone; most weigh it as one signal among many.
An SPF evaluation returns one of seven results: pass, fail, softfail, neutral, none, temperror, or permerror. The full result vocabulary and what to do about each is covered in the testing and troubleshooting entry.
The parts of an SPF record
An SPF record is a single TXT record composed of a version tag and a sequence of mechanisms, each optionally prefixed with a qualifier. The record syntax entry covers the overall structure and rules, the mechanisms entry details every matching directive, and the qualifiers entry explains the policy suffixes -all, ~all, and ?all that decide what happens to unauthorized mail.
SPF's known limitations
Three limitations define how SPF is used in practice. First, forwarding breaks it: a forwarded message arrives from the forwarder's IP, which the original domain never authorized, so SPF fails through no fault of the sender. Second, evaluation is capped at 10 DNS lookups, and records that exceed the budget return a permanent error. Third, SPF alone says nothing about the visible From address, which is why it only becomes an anti-spoofing control in combination with DMARC alignment.
Because of the forwarding problem, modern practice treats SPF as one leg of authentication rather than the whole answer: DKIM signatures survive forwarding, and DMARC accepts either mechanism. A domain with strong DKIM and a correct SPF record gets the benefits of both without either's weakness becoming fatal.
SPF in the current compliance landscape
SPF stopped being optional for bulk senders in 2024. Google and Yahoo require SPF or DKIM (and both for volumes above 5,000 messages a day, together with DMARC) as a condition of delivery, and Microsoft adopted equivalent requirements for Outlook consumer domains in 2025. Every major mailbox provider now evaluates SPF on inbound mail, and a missing or broken record costs placement everywhere.
Frequently asked questions
Does SPF stop spoofing of my domain?
Do I need SPF if I already have DKIM?
Does every domain need an SPF record, even ones that send no mail?
Is SPF enough to reach the inbox?
Key takeaways
- SPF publishes the list of servers allowed to send mail for a domain as a DNS TXT record
- Receivers check the connecting IP against the record during the SMTP transaction and score the result
- SPF validates the envelope sender, not the visible From header; DMARC alignment connects the two
- Forwarding legitimately breaks SPF, which is why DKIM should carry authentication alongside it
- Every domain needs a record, including non-senders, which should publish v=spf1 -all