SPF Record Complete Guide: Mechanisms, Lookup Limits, Flattening & Authentication
From v=spf1 to -all — the complete guide to Sender Policy Framework (SPF) records, mechanisms, DNS limits, and email authentication.
What Is SPF and Why Do You Need It?
SPF (Sender Policy Framework), defined in RFC 7208, is an email authentication protocol that lets domain owners publish a list of IP addresses authorized to send email on behalf of their domain. Without SPF, anyone can forge your domain in the "From" address and send email impersonating your organization — a technique at the core of phishing attacks, business email compromise (BEC), and spam campaigns.
With SPF, receiving mail servers query DNS for your SPF record, check the sending IP against your authorized list, and either pass, softfail, or fail the message. Combined with DKIM and DMARC, SPF forms the complete email authentication triad that protects your domain's reputation and your recipients' inboxes.
Anatomy of an SPF Record
An SPF record is a DNS TXT record at your root domain with a specific format:
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all
Breaking this down:
v=spf1— Required version tag. Identifies this as an SPF record.ip4:203.0.113.0/24— Authorize all IPs in this CIDR range directly (no DNS lookup).include:_spf.google.com— Delegate to Google's SPF record (1 DNS lookup).include:sendgrid.net— Delegate to SendGrid's SPF record (1 DNS lookup).-all— Hardfail: reject email from any IP not matching above mechanisms.
The Critical 10 DNS Lookup Limit
RFC 7208 hard-limits SPF evaluation to 10 DNS-resolving lookups. Each a:, mx:, include:, exists:, and redirect= mechanism triggers one lookup. ip4: and ip6: mechanisms are free — they never trigger DNS lookups.
The problem: include: mechanisms are recursive. Including Google's SPF record might pull in 3–4 sub-includes, each consuming a lookup. Add Salesforce, Mailchimp, Zendesk, HubSpot — and you're past 10 before you know it. Exceeding 10 lookups causes a PermError, which many receiving servers treat the same as SPF fail — legitimate emails from your authorized senders may be rejected.
Use our SPF Lookup tool to instantly count DNS lookups in your current SPF record. It highlights the count in red when you exceed 10.
SPF Flattening: The Solution to Lookup Limits
SPF flattening replaces include: mechanisms with the actual ip4: and ip6: ranges they resolve to. Instead of include:_spf.google.com (which triggers lookups), you list Google's actual sending IP ranges directly:
v=spf1 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ... -all
The tradeoff: you must manually update when your email providers change their IP ranges. Some providers offer dynamic SPF management services that automate this. For most small-to-mid organizations, quarterly audits with our SPF Lookup tool catch changes before they cause delivery problems.
SPF Qualifiers and Their Real-World Effects
-all (hardfail): Unauthorized senders are rejected. Combined with a DMARC p=reject policy, this is the gold standard for anti-spoofing protection. Zero tolerance for unauthorized senders.
~all (softfail): Unauthorized senders are accepted but marked. Gmail delivers softfail messages to spam with a warning header. Appropriate during SPF setup/migration, but should eventually be hardened to -all.
?all (neutral): No enforcement. Functionally equivalent to having no SPF — does not protect your domain from spoofing. Should never be used in production.
+all (passall): Authorizes literally every IP in the world. Catastrophically wrong — completely disables SPF protection. Never use this.
SPF, DKIM, and DMARC: The Complete Picture
SPF validates the sending IP but doesn't validate the message body or headers. DKIM adds a cryptographic signature to email headers, verified against a public key published in DNS — DKIM survives forwarding where SPF doesn't. DMARC ties both together:
- DMARC passes if either SPF or DKIM passes AND the relevant domain is aligned with the From: header domain.
- DMARC policy (p=none/quarantine/reject) controls what happens to messages that fail.
- DMARC RUA reports show you exactly which IPs are sending as your domain — both legitimate and malicious.
Read the full comparison in our guide: SPF vs DKIM vs DMARC.
Common SPF Mistakes to Avoid
- Multiple SPF records: Only one TXT record with v=spf1 is allowed per domain. Multiple records cause PermError.
- Forgetting transactional email services: Sendgrid, Mailchimp, HubSpot, Zendesk — each needs an include: or ip4: in your SPF.
- Not covering subdomains: SPF only applies to the exact domain queried. email.example.com needs its own SPF record.
- Leaving ?all or +all: Either renders SPF useless for anti-spoofing. Always end with ~all (during testing) or -all (production).
- Forgetting to check lookup count: Use our SPF Lookup tool regularly as you add new email services.
Related Tools
Check your mail server setup with MX Lookup. Query all DNS records with DNS Lookup. Validate email addresses with Email Checker. For understanding the IPs your SPF authorizes, use IP Range Calculator. Also read: MX Record Complete Guide and SPF vs DKIM vs DMARC.
FAQ
ToolsNovaHub tools are built and independently maintained with a focus on accurate, no-signup network and security utilities. Spotted an error? Let us know.
📋 Related Tools & Guides Comparison
| Resource | Type | Link |
|---|---|---|
| DNS Lookup | Network | Open Tool → |
| DNS Propagation Checker | Network | Open Tool → |
| Reverse DNS Lookup | Network | Open Tool → |
| How to Debug Website Caching Issues Using HTTP Headers | Guide | Read Guide → |
| DNS Propagation Guide: TTL, Global DNS & Migration Best Practices | Guide | Read Guide → |