SPF Record Explained: What It Is and Why Every Domain Needs One (2026 Guide)
Learn what an SPF record is, how it stops email spoofing, and how to write, publish, and troubleshoot yours in minutes with real provider examples.
Every day, spammers and phishers send emails that appear to come from real, trusted domains — including yours. If your domain doesn't publish an SPF record, there is nothing stopping a stranger from forging "From: billing@yourcompany.com" and sending a scam email that looks completely legitimate.
SPF is one of the three pillars of email authentication (alongside DKIM and DMARC), and it's usually the fastest one to set up. This guide breaks down exactly what SPF is, how it works under the hood, and how to write, publish, and debug your own record — with real configurations for Google Workspace, Microsoft 365, and other major providers.
1. What Is an SPF Record?
SPF (Sender Policy Framework) is a DNS TXT record that lists every mail server and IP address authorized to send email on behalf of your domain.
When a receiving mail server gets a message claiming to be from yourdomain.com, it looks up your domain's SPF record and checks: "Is the server that sent this actually on the approved list?" If the sending IP isn't listed, the receiving server can flag, quarantine, or reject the message outright.
SPF is formally defined in RFC 7208, and unlike an MX record (which tells the world where to deliver mail for your domain), SPF tells the world who's allowed to send mail claiming to be from your domain.
2. Why SPF Matters
- Stops domain spoofing — prevents attackers from impersonating your brand in phishing campaigns.
- Protects deliverability — Gmail, Outlook, and Yahoo increasingly reject or spam-folder unauthenticated mail. No SPF record can tank your inbox placement rate even for legitimate marketing and transactional email.
- Required by major providers — as of 2024, Gmail and Yahoo require SPF (or DKIM) for any domain sending more than ~5,000 emails a day, and it's a best practice for every domain regardless of volume.
- Builds a foundation for DKIM and DMARC — SPF alone is a partial defense; it becomes far stronger once layered with the other two protocols.
3. Anatomy of an SPF Record
A typical SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all
Here's what each mechanism means:
| Mechanism | Meaning |
|---|---|
v=spf1 | Declares this TXT record as SPF version 1. Always required, always first. |
ip4: / ip6: | Authorizes a specific IPv4 or IPv6 address to send mail. |
a | Authorizes the domain's own A record IP address. |
mx | Authorizes the domain's MX record servers to also send mail. |
include: | Pulls in another domain's SPF record — used for third-party senders like Google Workspace, SendGrid, or Mailchimp. |
~all | SoftFail — mail from unlisted sources is accepted but flagged as suspicious. |
-all | HardFail — mail from unlisted sources should be rejected outright. Recommended once you're confident your record is complete. |
+all | Allows any server to send as your domain. Never use this — it defeats the purpose of SPF entirely. |
?all | Neutral — no explicit policy; rarely used, offers little protection. |
4. Common SPF Configurations by Provider
Google Workspace
v=spf1 include:_spf.google.com ~all
Microsoft 365
v=spf1 include:spf.protection.outlook.com ~all
Zoho Mail
v=spf1 include:zoho.in ~all
(Use zoho.com instead of zoho.in if your account is registered outside India.)
Amazon SES
v=spf1 include:amazonses.com ~all
Combining Multiple Senders
If you send email from Google Workspace and a marketing tool like Mailchimp, combine both include statements into a single record — you can only have one SPF TXT record per domain:
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
5. The 10 DNS Lookup Limit (Where Most SPF Records Break)
This is the single most common reason SPF records silently fail: SPF permits a maximum of 10 DNS lookups per validation check, as defined in RFC 7208. Every include, a, mx, exists, and redirect mechanism counts toward that limit — and nested includes count too (Google's include:_spf.google.com, for example, may itself trigger multiple lookups).
Exceed the limit and receiving servers return a PermError, which means your entire SPF record is treated as if it doesn't exist — even though it looks perfectly valid.
How to avoid it:
- Flatten redundant includes (remove services you no longer use).
- Replace
includewith staticip4:/ip6:addresses where the sending IPs are fixed. - Run a lookup audit with the SPF Checker any time you add a new email tool or marketing platform.
6. Common SPF Mistakes
- Multiple SPF records on one domain. DNS only recognizes the first, and having two is technically invalid per spec — many validators will simply fail the check. Merge them into one.
- Missing
includefor a legitimate sender. Forgetting to add your CRM, helpdesk, or e-commerce platform's SPF include means their emails will fail authentication. - Using
+all. This publicly authorizes anyone to spoof your domain — the opposite of SPF's purpose. - Forgetting subdomains. SPF does not automatically apply to subdomains;
mail.yourdomain.comneeds its own record if it sends email independently.
7. How to Check Your SPF Record
- Open the SPF Checker and enter your domain.
- Confirm exactly one SPF TXT record is published.
- Verify every legitimate sending service (Google Workspace, your CRM, your marketing platform) appears via
includeorip4. - Check the lookup count is under 10.
- Once confident all senders are covered, move your policy from
~all(soft fail) to-all(hard fail) for maximum protection.
For a full picture of your domain's mail setup, pair this with the MX Lookup Tool and DNS Checker — see our MX records guide for how mail routing and authentication fit together.
8. SPF Is Not Enough on Its Own
SPF has one major limitation: it doesn't survive email forwarding, and it only validates the envelope sender, not the visible "From" address a recipient actually sees — which is exactly what phishing emails exploit. That's why SPF is meant to be paired with DKIM (cryptographic signing) and DMARC (the policy layer that ties them together).
Read next: DKIM Explained: How to Set Up and Verify DKIM Signatures and SPF vs DKIM vs DMARC: What's the Difference?
FAQ
Does SPF stop all spam? No. SPF only verifies the sending server is authorized — it doesn't inspect content. It's an authentication layer, not a spam filter.
Can I have SPF without DKIM? Yes, but it's not recommended. SPF alone breaks on forwarded mail and doesn't protect against "From" header spoofing the way DKIM + DMARC does.
How long does an SPF change take to go live? It depends on your DNS TTL — typically anywhere from a few minutes to 24-48 hours. Lower your TTL before making changes if you need faster propagation, and confirm with the DNS Checker.
What happens if I don't have an SPF record at all? Receiving servers have no way to verify your domain's authorized senders, which increases the chance legitimate mail lands in spam — and makes it trivial for attackers to spoof your domain.