The problem
In the default email protocol, any server can claim to send mail for your-company.com. Without additional information, recipients have no way to verify whether the sender address is genuine. This is the basis of phishing and CEO fraud.
How SPF works
SPF solves the problem with a DNS record. In a TXT record, you publish a list of servers that are allowed to send for your domain. The receiving mail server queries this list and compares it against the IP address that the email is currently coming from.
Example record
This is what a typical SPF entry in DNS looks like — here for a domain that uses Google Workspace and Mailgun:
; TXT record for @ (root domain) "v=spf1 include:_spf.google.com include:mailgun.org ~all"
The key components:
v=spf1— marks the record as SPF version 1.include:…— pulls in the allowed servers of a provider.~all— everything else is a softfail: mail probably gets through but is flagged.
The four policy endings
| Ending | Meaning | Recommendation |
|---|---|---|
-all | Hardfail — anything outside the list is rejected. | Ideal |
~all | Softfail — suspicious, but not blocked. | Good |
?all | Neutral — no statement. | Weak |
+all | Everything allowed. | Never |
The most common pitfalls
- More than 10 DNS lookups — SPF has a hard limit of 10 queries. Many
include:entries can blow past this limit and invalidate the record. - Two SPF records on one domain — technically forbidden and ignored by recipients. There must be exactly one TXT record with
v=spf1. - Forwarding — when mail is automatically forwarded from one address, SPF fails at the new recipient. DKIM solves this.