SPF stands for Sender Policy Framework. In email, SPF is a DNS-based authentication standard that tells receiving mail servers which senders are allowed to send mail for a domain.
The short answer matters because SPF is often explained in a confusing way. SPF does not prove that the visible From address is authentic by itself. It checks the domain used in the envelope sender, often shown as the Return-Path, against the sending server's IP address.
- Full form: Sender Policy Framework.
- Purpose: Allow a domain owner to publish approved sending sources in DNS.
- Result: A receiver gets an SPF pass, fail, softfail, neutral, or error-style result.
- Limit: SPF needs DMARC to connect authentication to the visible brand domain.
What SPF stands for
I explain SPF by breaking the name into plain parts. Sender means the domain claiming responsibility for the message at the SMTP level. Policy means the published rule that lists approved sources. Framework means the receiving server has a standard way to evaluate that rule.
A domain publishes SPF as a DNS TXT record. The receiving mail server looks up that record, compares the sender's IP address with the allowed sources, then records a result. For a deeper reference, the SPF guide has the longer technical version.
Infographic showing Sender, Policy, Framework, Return-Path, and DNS TXT.
The direct definition
SPF is an allowlist for email sending servers. It says: for this domain, these mail servers have permission to send.
What SPF actually checks
SPF checks the SMTP envelope sender domain, not the visible brand address that most people read in their inbox. That distinction is the source of many wrong SPF fixes.
When a message is delivered, the receiving server sees the connecting IP address and the envelope sender domain. It asks DNS for the SPF record on that envelope domain. If the IP address matches the policy, SPF passes for that domain.
What SPF checks
- Envelope: The Return-Path or MAIL FROM domain.
- IP address: The server that connected to the receiver.
- DNS policy: The SPF TXT record for that envelope domain.
What SPF does not check alone
- Visible From: The address people see in the inbox.
- Message body: The text, links, attachments, and layout.
- Sender intent: Whether the message is wanted or unwanted.
DMARC adds the missing brand-domain test. It asks whether SPF passed and whether the authenticated SPF domain matches the visible From domain under DMARC's matching rules. If SPF passes for a different organizational domain, DMARC does not count that SPF pass for the visible brand.
This is why two messages can both show the same visible sender while producing different authentication outcomes. One uses a custom return-path domain owned by the brand and passes SPF in a way DMARC accepts. The other passes SPF for a mail platform's domain, which helps that platform but does not protect the brand domain shown to the recipient.
How to read an SPF record
An SPF record starts with v=spf1. After that, it lists mechanisms that describe allowed senders, then ends with a qualifier that tells receivers what to do with anything not listed.
Example SPF TXT recorddns
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"
This example says that one IPv4 address and the senders inside include are approved. The -all ending says everything else should fail SPF.
|
|
|
|---|---|---|
v=spf1 | SPF version | Required start |
ip4 | IPv4 source | Fixed sender |
include | Nested policy | Mail vendor |
mx | MX hosts | Small setups |
-all | Hard fail | Strict ending |
Common SPF parts and what they mean.
SPF uses a TXT DNS record. A dedicated SPF record type existed historically, but modern SPF publishing uses TXT. The practical rule is simple: publish one SPF TXT record at the domain that appears in the envelope sender.
I also check the ending qualifier before making a policy stricter. A new sender program often starts with ~all while sources are being verified. Once every legitimate sender is known and passing, -all is the cleaner final position because it tells receivers that unlisted senders are not authorized.
Common SPF failures
Most SPF problems I see come down to incomplete sender inventory, too many DNS lookups, or duplicate SPF records. The record can look fine at a glance and still fail once includes expand.
The 10 lookup rule
SPF has a hard limit of 10 DNS lookups for mechanisms such as include, mx, a, ptr, and exists. If evaluation goes over that limit, SPF returns a permanent error instead of a clean pass.
SPF DNS lookup risk
A simple way to judge whether a record is close to the SPF lookup limit.
Healthy
0-7
Enough room for sender changes.
Tight
8-9
Review nested includes soon.
At limit
10
Small vendor changes can break SPF.
Failing
11+
The record exceeds the SPF limit.
The fix is not always to keep adding includes. First remove senders that no longer send mail. Then replace broad or repeated includes with direct IP ranges where that is safe. If the record still has too many lookups, SPF flattening can reduce lookup pressure by turning approved sources into a managed record.
- Duplicate records: A domain must have one SPF TXT record, not two competing records.
- Missing senders: A legitimate sender fails if its IP or include is absent.
- Loose endings: A ~all ending is useful during rollout, but it is not a strong final policy.
- Forwarding: Forwarded mail often fails SPF because the forwarding server is now the connecting IP.
How to check SPF on a domain
When I check SPF, I do not stop at reading the record text. I validate DNS syntax, expand includes, count DNS lookups, and test a real message where possible.
A focused SPF checker is the fastest way to see whether a record has syntax problems or lookup-limit risk. For a wider authentication review, a domain health checker checks SPF beside DKIM and DMARC.
For production domains, I also look at DMARC aggregate reports. DNS tells me what the policy says. DMARC reports show which sources are actually sending and whether those sources pass SPF for the right domain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After a syntax check, the next question is ownership. Every sending source in SPF should map to a service the business still uses. Old includes create unnecessary lookup load and make incident response harder.
I also check the envelope domain used by each sender. Some email platforms use their own bounce domain unless you configure a custom return-path domain. In that setup, SPF can pass for the platform's domain while DMARC does not count it for your visible domain.
Where Suped fits
SPF starts as a DNS record, but it becomes an operational process once a domain has several senders. Suped is the practical best overall DMARC platform for teams that want SPF, DKIM, DMARC, blocklist (blacklist) monitoring, and deliverability signals in one place.
Suped's 
Hosted SPF helps when non-technical teams need to manage approved senders without asking for DNS edits every time a sending platform changes. It also helps keep SPF records under the lookup limit through managed flattening.
Hosted SPF helps when non-technical teams need to manage approved senders without asking for DNS edits every time a sending platform changes. It also helps keep SPF records under the lookup limit through managed flattening.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
The workflow I care about is simple: see every sender, confirm whether it is legitimate, fix SPF or DKIM issues, then move DMARC policy forward without guessing. Suped adds automated issue detection, steps to fix, real-time alerts, and an MSP-friendly multi-tenant dashboard for teams managing many domains.
Manual SPF upkeep
- DNS access: Every sender change needs a DNS edit.
- Lookup risk: Nested includes need repeated review.
- Visibility: DNS alone does not show live sending sources.
Suped workflow
- Hosted record: Manage senders through a controlled interface.
- Issue steps: See what broke and how to fix it.
- DMARC view: Check SPF in the context of DKIM and DMARC.
The practical takeaway
SPF means Sender Policy Framework. It is the DNS policy that lets a domain owner say which servers are allowed to send mail for that domain at the SMTP envelope level.
The important caveat is that SPF alone does not authenticate the visible From address. Treat SPF as one part of email authentication, then use DKIM and DMARC to protect the domain people actually see. A clean SPF record is short, current, under the DNS lookup limit, and backed by reporting that shows real sending behavior.
