Sender Policy Framework is the foundation of email security — and one of the most commonly misconfigured DNS records. Here's everything you need to know.
By default, email has no authentication. Anyone with an email server can send a message claiming to be from [email protected] — and most email clients will display it as if it genuinely came from you. This is called email spoofing, and it's the starting point for the majority of phishing attacks.
SPF was created to solve this. It lets you publish a list of authorised mail servers in your DNS, so that when an email arrives claiming to be from your domain, the receiving server can verify whether it came from a source you approved.
SPF is published as a TXT record in your domain's DNS. When a receiving mail server gets an email claiming to be from your domain, it performs three steps:
1. Extract the sending IP address — the IP of the server that delivered the email.
2. Look up your SPF record — fetch the TXT record at your domain in DNS.
3. Check if the IP is authorised — does the sending IP appear in your SPF record? If yes, the email passes SPF. If not, it fails.
Here's a typical SPF record for an organisation using Google Workspace and Mailchimp:
v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.5 -all
Breaking it down:
v=spf1 — declares this as an SPF record (required).
include:_spf.google.com — authorises Google's mail servers to send on your behalf.
include:servers.mcsv.net — authorises Mailchimp's servers.
ip4:203.0.113.5 — authorises a specific IP address (e.g. your office mail server).
-all — reject all other senders. This is the policy qualifier (see below).
The final mechanism in your SPF record tells receivers what to do when an email fails the SPF check.
-all (Hard fail) — reject the email. Strongest protection. Use this once you're confident all your sending sources are listed.
~all (Soft fail) — accept the email but mark it as suspicious. Good when you're still discovering all your sending services.
?all (Neutral) — no policy. The SPF result is ignored. Not recommended.
+all explicitly authorises every server in the world to send as your domain. It completely negates SPF protection and is a critical misconfiguration.
SPF has a hard limit: a maximum of 10 DNS lookups when resolving your record. Each include:, a:, mx:, or ptr: mechanism counts toward this limit. If you exceed 10, receiving servers will return a permerror and your SPF check will fail — even for legitimate emails.
ip4: entries, reducing lookup count to near zero. The tradeoff is that you need to keep the record updated when providers change their IPs.
RFC 7208 is explicit: a domain must have exactly one SPF record. If you have two TXT records starting with v=spf1, receiving servers will return a permerror and your SPF will fail entirely. This is a surprisingly common issue when organisations migrate email providers and forget to remove the old record.
Missing the record entirely — the most common finding. Add it today.
Using +all — negates all protection. Change to ~all or -all immediately.
Duplicate SPF records — merge them into one TXT record.
Too many DNS lookups — use SPF flattening or remove unused includes.
Forgetting third-party senders — CRMs, helpdesks, and marketing tools all need to be included if they send email on your behalf.
Not testing after changes — always re-check with a tool after making DNS changes.
Use our free SPF checker to instantly look up and analyse your domain's SPF record. You'll get a traffic light result and specific steps to fix any issues found.
🔍 Check Your SPF Record