SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which servers are allowed to send email on behalf of your domain. If a server not on that list sends email claiming to be from your domain, the receiving server can reject or flag it.
Understanding the syntax makes it easier to set it up correctly and avoid common mistakes like accidentally hitting the 10-lookup limit.
The basic structure
An SPF record is a TXT record on your domain's DNS. It always starts with:
v=spf1
After that, you list your authorized senders as mechanisms, then end with an all directive.
A typical SPF record looks like this:
v=spf1 include:_spf.google.com include:spf.sendinblue.com ip4:203.0.113.50 ~all
Mechanisms
ip4: and ip6:
Authorizes a specific IP address or CIDR range.
ip4:203.0.113.50
ip4:203.0.113.0/24
ip6:2001:db8::1
Use this when you know the exact IP of a mail server you control.
include:
Delegates to another domain's SPF record. Each include: causes one DNS lookup.
include:_spf.google.com
include:sendgrid.net
include:spf.mailchimp.com
Most third-party email services give you an include: value to add. Each one authorizes all IPs in that service's SPF record.
a:
Authorizes the A record of a domain. If the domain's A record matches the IP the email came from, it passes.
mx:
Authorizes the MX records of a domain. Less common, typically used when your mail server and MX records are the same host.
ptr:
Avoid this one. It is slow, unreliable, and deprecated in practice.
The all directive
The all at the end controls what happens to mail from servers not on your list:
-
~all(softfail) — fail but usually deliver anyway, marking as suspicious -
-all(hardfail) — reject the email -
+all(pass all) — authorizes everything, which defeats the purpose of SPF entirely -
?all(neutral) — no policy, same as having no SPF
For most senders, ~all is the safe starting point. Once you are confident your record is complete, switch to -all for stronger protection.
The 10-lookup limit
SPF has a hard limit of 10 DNS lookups per evaluation. Each include:, a:, mx:, and ptr: costs one lookup. Exceed 10 and the SPF check returns permerror, which effectively means the record fails.
This is a common problem when a domain uses multiple services: Google Workspace plus Mailchimp plus SendGrid plus a CRM can easily push you over the limit.
To fix it:
- Audit your record and count your lookups
- Remove services you are no longer using
- Flatten the record by replacing
include:values with the raw IPs they resolve to (but you will need to update this when the provider changes their IPs) - Use an SPF flattening service if you have many senders and cannot reduce them
InboxGreen's SPF lookup tool shows your current record and flags lookup count issues.
Common mistakes
Multiple SPF records: You can only have one TXT SPF record per domain. A second record breaks SPF validation entirely. Merge them into one.
Wrong domain: SPF needs to match the domain in the From: header for DMARC alignment. If you send from noreply@mail.yourdomain.com, the SPF record needs to be on mail.yourdomain.com.
Forgetting subdomains: SPF on yourdomain.com does not cover mail.yourdomain.com or info.yourdomain.com. Each sending subdomain needs its own record.
Missing all: Every SPF record must end with some form of all. Without it, the result is undefined.
Checking your record
InboxGreen's free checker pulls your SPF record, parses the mechanisms, and runs an authentication check against your domain. No login required.
