Definition
SPF (Sender Policy Framework) is an email authentication standard published as a TXT record in your domain's DNS. The record lists the IP addresses and hostnames permitted to send mail using your domain in the envelope From address. When a receiving server gets your message, it checks the connecting IP against your published SPF list. If the IP is on the list, the source is considered legitimate. If not, the message is treated as suspicious — usually quarantined, sometimes rejected outright.
How SPF actually works
An SPF record looks unassuming. Something like v=spf1 include:_spf.google.com include:sendmsg.io ip4:192.0.2.0/24 ~all in a DNS TXT record. The mechanisms inside are doing real work though. include: chains in another domain's SPF list (used when your email provider hosts the sending IPs). ip4: and ip6: hard-code specific IPs or ranges you control. a: and mx: point at your existing A or MX records. The terminator at the end — ~all (soft fail), -all (hard fail), or ?all (neutral) — tells receiving servers how to treat messages from IPs not on the list.
When your message arrives at a receiving server, the server reads the envelope From domain (also called the Return-Path or MAIL FROM), fetches that domain's SPF record from DNS, walks through the mechanisms, and evaluates whether the connecting IP is permitted. The check completes in milliseconds. The result becomes part of the metadata the receiving server uses to decide what to do with the message.
One important nuance: SPF authenticates the envelope From, not the visible From header your users see in their inbox. This is why SPF on its own does not stop phishing where someone spoofs your visible address but sends from their own envelope domain. DMARC was designed specifically to close that gap by requiring the envelope SPF or DKIM result to align with the visible From header.
Why SPF matters in 2026
Same context as DKIM. Gmail and Yahoo's 2024 enforcement update made authentication mandatory for bulk senders. Outlook tightened similarly. SPF is no longer "nice to have" — without it, your bulk mail to those providers ends up in spam or gets rejected. The penalty is measurable in delivered-percentage points, not theoretical.
SPF is also the simplest of the three authentication standards to set up. It is a single DNS record, no key rotation, no cryptographic ceremony. The cost-to-protection ratio is excellent. There is no good reason for a domain that sends production email in 2026 to not have a working SPF record. Run our free deliverability check to confirm yours is right.
The 10-lookup limit that catches everyone
SPF has a built-in performance constraint: a receiving server can perform at most 10 DNS lookups to evaluate your record. Every include:, a:, mx:, and a few other mechanisms count toward that budget. If your record exceeds 10 lookups, SPF evaluation returns permerror — and your message fails authentication for that reason alone, not for any actual spoofing problem.
Most teams hit this limit by accident. They add Google Workspace, then HubSpot, then MailerLite, then Brevo, then SendGrid for transactional, then a CRM provider, each one as another include:. Each of those includes chains to two or three more lookups internally. Suddenly you are at lookup 12 and Gmail starts marking your mail as failing SPF. The fix is either consolidating senders, flattening the includes into raw IP ranges, or using an SPF-management tool to keep the count under 10 automatically.
Common SPF mistakes worth avoiding
Multiple TXT records for SPF on the same domain. RFC 7208 says one SPF TXT record per domain, full stop. Older how-to guides occasionally show people publishing two, which makes the entire SPF check fail. If you check your DNS and see two v=spf1 records, you have a bug to fix.
Wrong terminator for your situation. ~all is the safe default for most senders — it tells receivers "anything not in this list is suspicious but maybe still deliver." -all is the hard-fail version and only safe to use when you are sure your SPF list is complete. Most teams who switch to -all too aggressively lose legitimate mail from forgotten subprocessors and only realise weeks later when a customer complains they never got their invoice.
Forgetting to update SPF when you change ESPs. The new sender starts sending from IPs your domain has never authorised, every message fails SPF, and a chunk of your mail starts landing in spam. The fix is to publish the new ESP's include before you start sending, not after. Standard ESP migration playbook stuff but it gets missed under deadline pressure.
Related reading
- DKIM (DomainKeys Identified Mail) — the cryptographic-signature half of authentication. Pairs with SPF.
- Email Deliverability — broader context where SPF sits as one of several signals.
- The Email Deliverability Guide — full-length practical setup with DNS record templates.
- Run a free deliverability check — verifies SPF, DKIM, DMARC, and MX in one pass.