Validate your Sender Policy Framework (SPF) record. Check for syntax errors, multiple records, and the 10 DNS lookup limit to ensure your emails reach the inbox.
SPF (Sender Policy Framework) is a DNS-based email authentication standard defined in RFC 7208. It lets domain owners publish a list of IP addresses and services that are authorised to send email on behalf of their domain. When a receiving mail server gets an email from your domain, it looks up your SPF record in DNS and checks whether the sending IP is on the approved list.
A valid SPF record is published as a DNS TXT record at the root of your domain (e.g., example.com) and starts with v=spf1. Without SPF, anyone can forge your domain in the From header — a technique used in phishing attacks.
| Component | Example | What it does |
|---|---|---|
v=spf1 | v=spf1 | Required. Declares this is an SPF record. Must be first. |
ip4: | ip4:203.0.113.0/24 | Authorises a specific IPv4 address or CIDR range. |
ip6: | ip6:2001:db8::/32 | Authorises a specific IPv6 address or CIDR range. |
include: | include:_spf.google.com | Imports another domain's SPF record. Counts as 1 lookup. |
a | a:mail.example.com | Authorises the A/AAAA record(s) of the specified domain. |
mx | mx | Authorises the IP addresses in your domain's MX records. |
redirect= | redirect=_spf.example.com | Delegates SPF entirely to another domain's record. |
exists: | exists:%{i}._spf.example.com | Passes if a matching A record is found (advanced). |
~all | ~all | Softfail. Non-matching senders are marked suspicious. |
-all | -all | Fail. Non-matching senders are rejected. Recommended. |
+all | +all | ⚠ Pass all. Authorises any sender — never use this. |
?all | ?all | Neutral. No policy — offers no protection. |
Each mechanism can be prefixed with a qualifier that controls what happens when it matches:
| Qualifier | Result | Meaning |
|---|---|---|
+ (default) | Pass | Sender is authorised. |
- | Fail | Sender is not authorised. Reject the mail. |
~ | Softfail | Sender is probably not authorised. Accept but mark. |
? | Neutral | No assertion. Do not use in production. |
The most important qualifier is the all mechanism at the end of your record. Use -all for strict enforcement once all your sending services are included.
RFC 7208 limits SPF evaluation to 10 DNS lookups. Every include:, a, mx, ptr, exists, and redirect= mechanism consumes one lookup. Exceeding 10 causes a PermError — which most receivers treat as a hard failure, breaking email delivery.
Mechanisms that count toward the limit:
| Mechanism | Lookup count |
|---|---|
include:domain | 1 per include |
a:domain | 1 per a |
mx:domain | 1 per mx |
ptr:domain | 1 per ptr (deprecated, avoid) |
exists:domain | 1 per exists |
redirect=domain | 1 for redirect + nested lookups |
ip4: / ip6: | 0 — no lookup needed |
Mechanisms that do NOT count: ip4:, ip6:, v=spf1, all, +, -, ~, ?
How to fix lookup limit exceeded:
include: chains to see their nested lookups.include:provider.com with ip4: ranges where the provider publishes stable IPs.mail.example.com) with its own SPF.| Error | Cause | Fix |
|---|---|---|
PermError: too many DNS lookups | More than 10 mechanisms that trigger lookups | Flatten SPF or remove unused includes |
Multiple SPF records found | Two TXT records starting with v=spf1 | Merge into one record — only one is allowed |
No SPF record found | Missing TXT record | Add v=spf1 [mechanisms] -all to your DNS |
+all in SPF record | Record authorises every sender | Replace with -all immediately — this is a critical misconfiguration |
Softfail only (~all) | Weak enforcement | Upgrade to -all once all senders are verified |
ptr mechanism used | Deprecated mechanism that triggers reverse DNS | Remove ptr — use ip4: or include: instead |
Void lookup limit exceeded | More than 2 lookups returning no results | Remove mechanisms that resolve to empty results |
Google Workspace only:
v=spf1 include:_spf.google.com -all
Google Workspace + Mailchimp + custom IP:
v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.42 -all
Multiple sending services (watch the lookup count):
v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com ip4:198.51.100.0/24 -all
Check this record's lookup count: Google (_spf.google.com) + SendGrid (sendgrid.net) + Salesforce (_spf.salesforce.com) = 3 includes at minimum, each resolving to further nested includes. Use this tool to verify you stay under 10.
Verify your SPF record without a browser:
# Query SPF TXT record
dig +short TXT example.com | grep v=spf1
# Same on Windows PowerShell
Resolve-DnsName -Name example.com -Type TXT | Where-Object { $_.Strings -match "v=spf1" }
# Check a specific DNS resolver (Cloudflare)
dig +short TXT example.com @1.1.1.1
# Simulate SPF check with swaks (SMTP Swiss Army Knife)
swaks --to user@example.com --from sender@yourdomain.com --server mail.example.com
SPF alone is not sufficient for strong email security. DMARC builds on SPF (and DKIM) and requires alignment — the domain in the Return-Path header must match the From domain (for strict alignment) or be a subdomain of it (relaxed alignment).
-all but no DMARC record still has no reporting or policy enforcementUse the DMARC Checker to verify your DMARC policy and alignment settings alongside SPF.
DNS, email auth, and security playbooks delivered when they publish. No spam.