What is SPF?
Sender Policy Framework (SPF) is an email authentication protocol that prevents spammers from sending emails that appear to come from your domain.
What is SPF?
SPF (Sender Policy Framework) lets you declare which mail servers are allowed to send email on behalf of your domain. It works by publishing a special DNS TXT record that lists your authorized sending IP addresses and servers.
When someone receives an email claiming to be from your domain, their mail server checks your SPF record to verify that the email actually came from a server you authorized. If it didn't, the email can be flagged as suspicious or rejected entirely.
SPF is defined in RFC 7208 and is one of three pillars of email authentication, alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance).
Why SPF matters
Prevents email spoofing
Without SPF, anyone can send email that appears to come from your domain. Attackers exploit this for phishing, business email compromise, and spam.
Improves deliverability
Major providers like Google, Microsoft, and Yahoo require SPF authentication. Emails that fail SPF are more likely to be marked as spam or rejected.
Builds trust
When receiving servers see your emails consistently pass SPF, they trust your domain more. This protects your brand reputation.
Foundation for DMARC
SPF is one of two authentication mechanisms DMARC relies on. Without SPF, DMARC cannot provide full protection against impersonation.
How SPF works
Here's what happens when an email is sent from your domain:
Email is sent
A mail server sends an email with a Return-Path address of [email protected].
Receiving server checks DNS
The receiving server extracts the domain from the Return-Path (envelope sender) and queries DNS for a TXT record starting with v=spf1.
Mechanisms are evaluated
The server checks each mechanism in the SPF record from left to right. The first match determines the result.
Decision is made
Based on the result (pass, fail, softfail, etc.), the receiving server decides whether to deliver, quarantine, or reject the message.
Example SPF record
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all
This record says: "Allow emails from IP addresses in the 192.0.2.0/24 range and from Google Workspace servers. Reject everything else."
SPF mechanisms
An SPF record is a series of mechanisms evaluated left to right. Each defines a rule for matching the sender's IP address.
| Mechanism | What it does | DNS lookup? | Example |
|---|---|---|---|
ip4 |
Matches an IPv4 address or CIDR range | No | ip4:203.0.113.0/24 |
ip6 |
Matches an IPv6 address or CIDR range | No | ip6:2001:db8::/32 |
include |
Includes another domain's SPF record | Yes | include:_spf.google.com |
a |
Matches the domain's A/AAAA record IPs | Yes | a or a:mail.example.com |
mx |
Matches the domain's MX record IPs | Yes | mx or mx:example.com |
all |
Catch-all; always matches (used at the end) | No | -all or ~all |
exists |
Matches if a DNS A record exists for the domain | Yes | exists:%{i}._spf.example.com |
redirect |
Use another domain's SPF record entirely | Yes | redirect=_spf.example.com |
include, a, mx, exists, and redirect all count.
ip4, ip6, and all do not count.
Exceeding this limit causes a permanent error (permerror).
Qualifiers
Each mechanism can be prefixed with a qualifier that determines what happens when it matches:
| Qualifier | Name | Meaning |
|---|---|---|
+ |
Pass | The sender is authorized. This is the default if no qualifier is specified. |
- |
Fail (hard fail) | The sender is explicitly not authorized. The email should be rejected. |
~ |
Softfail | The sender is probably not authorized. Accept but flag as suspicious. Common during rollout. |
? |
Neutral | No assertion about authorization. Treated as if no SPF record exists for that mechanism. |
-all to explicitly reject
unauthorized senders. Use ~all only during initial testing.
SPF results explained
When a receiving server evaluates your SPF record, it produces one of these results:
The sender's IP matched an authorized mechanism. The email is authenticated.
The sender is explicitly unauthorized (-all). The email should be rejected.
The sender is probably unauthorized (~all). Accept but treat with suspicion.
No assertion about authorization (?all). No SPF-based decision.
No SPF record found for the domain. No SPF-based decision can be made.
The SPF record is malformed (syntax error, too many lookups, multiple records). Requires fixing.
Setup for common providers
Your domain can have only one SPF TXT record. If you use multiple email services, combine them into a single record.
Google Workspace
v=spf1 include:_spf.google.com -all
Microsoft 365
v=spf1 include:spf.protection.outlook.com -all
Amazon SES
v=spf1 include:amazonses.com -all
SendGrid
v=spf1 include:sendgrid.net -all
Zoho Mail
v=spf1 include:zohomail.com -all
Multiple services combined
v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com -all
Combine all your services into one record. Remember the 10 DNS lookup limit.
Common mistakes
Too many DNS lookups
SPF allows a maximum of 10 DNS-resolving mechanisms. Each include counts as 1 lookup
plus any nested lookups within. For example, include:_spf.google.com alone
can use 3–4 lookups.
Fix: Replace include and a/mx with direct ip4/ip6 entries where possible. Use subdomains for different sending services to get separate lookup budgets.
Using +all
This means "any server in the world is authorized to send email as my domain." It completely defeats the purpose of SPF.
Fix: Always use -all or at minimum ~all.
Multiple SPF records
A domain can only have one SPF record. If a receiving server finds two or more
records starting with v=spf1, it returns a permanent error and all SPF checks fail.
Fix: Merge all SPF entries into a single record.
Forgetting third-party senders
Your domain might send email through marketing platforms (Mailchimp, HubSpot), transactional services (SendGrid, Postmark), CRM systems (Salesforce), or helpdesks (Zendesk). If these aren't in your SPF record, their emails will fail.
Fix: Audit all services that send email on behalf of your domain before deploying SPF.
No all mechanism at the end
Without a catch-all all mechanism, IPs that don't match any mechanism default to
"neutral," which provides no protection.
Fix: Always end your SPF record with -all.
Best practices
Use -all (hard fail)
Once you've confirmed all legitimate senders are included, switch from ~all to -all for maximum protection.
Keep it simple
Minimize DNS-resolving mechanisms. Use ip4/ip6 when you know specific IPs. Remove includes for services you no longer use.
Test before deploying
Use SPF validation tools to verify syntax and DNS lookup count before publishing. Start with ~all and monitor before switching to -all.
Use subdomains for separation
Use marketing.example.com for marketing email and notifications.example.com for transactional email. Each subdomain gets its own 10-lookup budget.
Monitor with DMARC
Set up DMARC with reporting (rua tag) to receive aggregate reports showing SPF pass/fail rates. Review regularly.
Combine with DKIM and DMARC
SPF alone isn't enough. Use all three protocols together for robust protection against email spoofing and phishing.
Check your domain's SPF record
Domain Guarddog monitors your SPF, DKIM, and DMARC configuration and alerts you to issues.
Get Started Free