An SPF (Sender Policy Framework) record is a single DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain — defined by RFC 7208. When a receiving server accepts a message that claims to be from you@yourdomain.com, it looks up your domain's SPF record and checks whether the server that actually delivered the message is on your approved list. If the IP matches, the message passes SPF; if it does not, the message fails and is more likely to be rejected or dropped in spam. You need one because without it, anyone on the internet can forge your domain in the envelope of their spam and phishing — and since February 2024, Gmail and Yahoo outright require SPF for anyone sending bulk mail.
That is the summary an AI Overview will give you. What it can't show you is the mechanism most guides get wrong (SPF checks a hidden address, not the one in your inbox), the exact anatomy of a record you can copy, the failure that silently breaks authentication, and a generator that builds a valid record for your providers. Here is the part that actually keeps mail flowing.
How SPF actually works: the envelope, not the inbox
The single most misunderstood fact about SPF is which sender it validates. Every email carries two "from" addresses: the visible From: header your mail client displays, and a hidden envelope sender (the Return-Path / MAIL FROM) used during SMTP delivery. SPF checks the envelope sender's domain — not the From: address you see. That is why SPF alone cannot stop a phisher who puts your brand in the visible From: while using their own domain in the envelope. Closing that gap is DMARC's entire job: it requires the SPF-authenticated domain to align with the visible From: domain.
Anatomy of an SPF record
An SPF record is one line, but every token matters. Here is a realistic record for a domain that sends through Google Workspace and SendGrid, broken down:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.20 ~all
| Token | Type | What it does |
|---|---|---|
v=spf1 | Version | Required first token. Marks this TXT record as SPF. |
include:_spf.google.com | Mechanism | Delegates authorization to Google's published SPF (Gmail/Workspace). Costs 1 DNS lookup (plus any nested). |
include:sendgrid.net | Mechanism | Authorizes SendGrid's sending IPs. |
ip4:198.51.100.20 | Mechanism | Authorizes one specific IPv4 address (e.g. your own mail server). Costs zero DNS lookups. |
~all | Qualifier + all | Catch-all for everything not matched above. ~ = softfail. |
The qualifier in front of all is the policy decision that people most often get wrong:
| Qualifier | Name | Receiver behavior for unlisted senders | When to use |
|---|---|---|---|
-all | Hardfail | Reject unauthorized mail | Once DMARC reports confirm no legitimate mail fails |
~all | Softfail | Accept but mark as suspicious | Start here — safe default during rollout |
?all | Neutral | No opinion; treat as if no SPF | Almost never — provides no protection |
+all | Pass-all | Authorize the entire internet | Never. This authorizes spammers to spoof you |
Build a valid record now
Rather than hand-assemble includes and risk a typo that silently breaks authentication, generate a record from your actual providers and paste it into DNS:
The two failures that quietly break SPF
Most broken SPF setups fail for one of two reasons, and neither throws an obvious error:
- More than one SPF record. A domain must publish exactly one
v=spf1TXT record. Publish two (easy to do when you add a new provider and paste a second line) and receivers return apermerror— which breaks SPF entirely rather than combining them. Always merge newincludemechanisms into the existing record. - The 10 DNS lookup limit. RFC 7208 caps evaluation at 10 DNS lookups. Every
include,a,mx,ptr, andexistsmechanism consumes lookups, and nested includes count recursively — a singleinclude:_spf.google.comcan hide several. Cross 10 and you get apermerror. Fixes: preferip4/ip6mechanisms (zero lookups), drop unused providers, or "flatten" the record. We cover this in depth in The SPF 10 DNS Lookup Limit.
Forwarding is a third gotcha: when a mailbox forwards your message, the forwarding server's IP is not on your list, so SPF fails at the final hop. This is not a bug in your record — it is why SPF is never deployed alone. DKIM survives forwarding because it signs the message itself, and DMARC lets a pass on either SPF or DKIM authenticate the message.
Why you need SPF in 2025: Gmail and Yahoo made it mandatory
In February 2024, Gmail and Yahoo began enforcing bulk-sender requirements: any domain sending more than roughly 5,000 messages a day to their users must publish SPF and DKIM, and have a DMARC policy (at minimum p=none). Fall short and your mail gets rejected or filtered to spam at massive scale. Even below that threshold, mailbox providers weigh authentication heavily in placement decisions. SPF is no longer optional hygiene — it is table stakes for the inbox.
The takeaway: SPF is the "who is allowed to send" layer. It is cheap (one DNS record), but it only validates the hidden envelope sender, it breaks on forwarding, and it dies silently if you exceed 10 lookups or publish two records. Deploy it with ~all, watch your DMARC reports, tighten to -all, and layer DKIM and DMARC on top. That combination — not SPF alone — is what actually stops spoofing and protects deliverability.