SPF is a way to publish a list of servers that are allowed to send email on behalf of your business. When someone receives an email claiming to be from your domain, their email provider checks your list — if the server that actually sent it isn’t on the list, the email gets flagged or rejected. (The full name is Sender Policy Framework.)
How SPF Works
Here’s what happens step by step when an email is sent from a domain protected by SPF:
A server at IP address 203.0.113.5 sends an email claiming to be from you@example.com.
The recipient’s email provider (e.g. Gmail, Outlook) receives the email and looks up the approved sender list (called an SPF record) for example.com in your domain’s settings. It finds:v=spf1 ip4:203.0.113.5 -all
The receiving server asks: “Is 203.0.113.5 in the list of IPs that example.com says are allowed to send email?”
The IP address is in the SPF record, so the check passes. The email is legitimate and gets delivered.
If an attacker at IP 198.51.100.9 tries to send email pretending to be example.com, the receiving server sees that IP is not in the SPF record and marks it as a failure. The email may be rejected or flagged as spam.
SPF Check — Visual Overview
What an SPF Record Looks Like
Your SPF record is a short line of text stored in your domain’s public directory (DNS). It starts with v=spf1 and lists all the servers allowed to send email for your business:
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all
Don’t worry about memorising this — here’s what each part means:
| Part | Meaning |
|---|---|
v=spf1 |
SPF version 1 (required, always first) |
ip4:203.0.113.0/24 |
Allow this IPv4 address range to send email |
include:_spf.google.com |
Also allow Google Workspace servers |
include:sendgrid.net |
Also allow SendGrid servers |
-all |
Reject everything else (hard fail) |
The Building Blocks of an SPF Record
SPF records use these building blocks (called mechanisms) to define who’s allowed to send:
| Mechanism | Example | What it does |
|---|---|---|
ip4 |
ip4:203.0.113.5 |
Match a specific IPv4 address or range |
ip6 |
ip6:2001:db8::/32 |
Match a specific IPv6 address or range |
include |
include:_spf.google.com |
Include another domain’s SPF record (delegates) |
a |
a or a:mail.example.com |
Match the domain’s A record IP(s) |
mx |
mx |
Match the domain’s MX record IP(s) |
exists |
exists:%{i}._spf.example.com |
Match if a DNS A record exists (advanced macro) |
redirect |
redirect=_spf.example.com |
Use another domain’s SPF record entirely |
What Happens When a Server Isn’t on the List
The ending of your SPF record (the “qualifier”) tells email providers what to do with servers that aren’t on your approved list:
all.The 10 Lookup Limit (Important!)
include counts as one. If you go over 10, SPF breaks completely for all your emails — not just some.
This is the most common SPF problem for businesses that use several email services. For example:
v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com include:spf.protection.outlook.com include:servers.mcsv.net include:amazonses.com include:zendesk.com include:spf.freshdesk.com a mx -all
How to fix it:
- Remove unused services — audit which includes you actually still use
- Use
ip4/ip6instead ofinclude— IP mechanisms don’t count toward the limit - SPF flattening — resolve includes to their IP addresses (requires maintenance)
- Use subdomains — send marketing email from
mail.example.comwith its own SPF record
Common SPF Records by Provider
| Service | Include |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| SendGrid | include:sendgrid.net |
| Mailchimp | include:servers.mcsv.net |
| Amazon SES | include:amazonses.com |
| Zendesk | include:mail.zendesk.com |
| Freshdesk | include:email.freshdesk.com |
| HubSpot | include:spf.hubspot.com |
| Zoho | include:zoho.com |
SPF Alone Isn’t Enough
SPF is a great first step, but it has some important limitations:
- SPF only checks the behind-the-scenes sender address, not the “From” your customers see — a clever attacker can pass SPF while still faking the visible “From” address
- Email forwarding breaks SPF — when someone auto-forwards your email, it comes from a different server, so SPF fails even though the email is genuine
- No reporting — SPF doesn’t tell you when checks fail, so you’re flying blind
That’s why you need SPF alongside DKIM (a digital signature that proves the email is genuine) and DMARC (which ties everything together and gives you reports). Together, the three form a complete defence.
Check your domain’s email authentication
Use our free Domain Checker to see your current SPF, DKIM, and DMARC records — and find out what needs fixing.