CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
What is an SPF Record? Sender Policy Framework Explained (2025)
Email Security
SPF Records Explained: How Sender Policy Framework Stops Email Spoofing
SPF (Sender Policy Framework) is a DNS-published email authentication standard that defines which mail servers can send email on behalf of your domain. Learn how SPF records work, how to fix the 10-DNS-lookup limit, how to avoid softfail vs hardfail mistakes, and how SPF pairs with DKIM and DMARC for complete email security.
SPF (Sender Policy Framework) is a DNS-published email authentication standard that defines which mail servers can …
What is SPF?
SPF (Sender Policy Framework) is a DNS-based email authentication standard that lets domain owners specify which mail servers are authorized to send email on their behalf. Published as a DNS TXT record at the domain root, SPF gives receiving mail servers a way to verify that incoming email claiming to be from your domain actually came from a server you authorized.
When an attacker tries to send spoofed email using your domain, the receiving server queries your SPF record. If the attacker's server IP is not listed and your record ends with -all, the message is marked as a failure. This prevents unauthorized servers from successfully impersonating your domain — but only at the envelope (Return-Path) level. For full spoofing protection against the visible From address, SPF must be paired with .
Every SPF record begins with v=spf1, identifying it as an SPF policy. After the version tag come mechanisms and qualifiers:
DNS Record / Config
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all"
| Part | Meaning |
|------|---------|
| v=spf1 | Version identifier — required |
| ip4:192.0.2.0/24 | Authorize this IP range directly |
| include:_spf.google.com | Pull in Google Workspace's authorized IPs |
| include:sendgrid.net | Pull in SendGrid's authorized IPs |
| -all | Hard fail — reject all other senders |
SPF is evaluated left to right. The first matching mechanism wins. If no mechanism matches, the all qualifier at the end determines the result.
SPF mechanisms: include, a, mx, ip4, ip6, ~all, -all
include: — the most common mechanism. Delegates trust to another domain's SPF record. Each include: consumes one DNS lookup. Use for cloud email providers (Google Workspace, Microsoft 365, SendGrid, Mailchimp).
ip4: / ip6: — authorizes specific IP addresses or CIDR ranges directly. Does not consume a DNS lookup. Preferred for servers with static IPs because it is explicit, fast to evaluate, and does not create a lookup chain.
a — authorizes the IP addresses behind the domain's A record. Consumes one DNS lookup. Use sparingly.
mx — authorizes the domain's MX (mail exchanger) hosts. Consumes one lookup plus one per MX record. Rarely needed for outbound authorization.
~all (softfail) — non-matching senders are marked as suspicious but delivered. The legacy default. Use -all instead for cleaner enforcement.
-all (hardfail) — non-matching senders are definitively unauthorized. Receiving servers should reject or quarantine. The recommended ending for all production SPF records.
+all (pass all) — authorizes every mail server on the internet. Never use this. It completely defeats the purpose of SPF.
The 10-DNS-lookup limit (and how to fix it)
RFC 7208 caps SPF processing at 10 DNS lookups. Each include:, a, mx, exists, and redirect mechanism counts as one lookup. If your record exceeds this limit, receivers return PermError and SPF fails entirely — even for legitimate mail.
Why this happens: Organizations accumulate email providers over years — a CRM tool, a transactional mailer, a marketing platform, a helpdesk ticketing system. Each adds an include:. After several vendor changes, the record may have 15+ lookups with half of them pointing to services no longer in use.
How to fix it:
Audit your current lookup count with an SPF checker tool
Remove all include: entries for vendors no longer sending your email
Replace include: entries with ip4: where the provider uses static IP ranges
Use SPF flattening only as a last resort (see below)
SPF flattening explained
SPF flattening is the process of replacing recursive include: chains with the actual resolved IP addresses (ip4: entries). This eliminates DNS lookups and keeps the record within the 10-lookup limit.
The tradeoff: Once flattened, you own the update cycle. When Google Workspace, SendGrid, or any included provider changes their IP ranges (which happens regularly), your flat SPF record becomes stale — and legitimate mail starts failing.
Flattening is appropriate when you have exhausted other options. If you flatten, you must implement automated monitoring that detects when provider IPs change and alerts you to update your record.
Common SPF errors and how to debug them
Multiple SPF records: Only one v=spf1 record is allowed per domain. Multiple records cause PermError immediately. Merge them into a single record.
PermError from too many lookups: Count your lookups. Remove stale providers. Replace include: with ip4: where possible.
SPF passes but DMARC fails: SPF only checks the envelope sender (Return-Path). If the Return-Path domain does not align with the visible From domain, SPF pass does not satisfy DMARC. This is a DMARC alignment issue, not an SPF error.
Forwarding failures: Forwarded email fails SPF because the forwarding server IP is not in your record. This is expected behavior. DKIM authentication survives forwarding; SPF does not. Ensure DKIM is properly configured so forwarded mail can still satisfy DMARC.
Stale includes: The include:_spf.salesforce.com in your record authorizes every IP Salesforce uses globally. If you stopped using Salesforce three years ago, remove the include — it is an unnecessary attack surface.
SPF vs DMARC alignment
SPF can pass and still contribute nothing to DMARC protection if the authenticated domain does not align with the visible From domain. Consider this scenario: you use a shared email platform, SPF passes using the platform's Return-Path domain, but your From address is @yourcompany.com. SPF passes, DMARC alignment fails.
This is why teams often believe SPF is healthy while DMARC aggregate reports still show failures. SPF should be reviewed as one identity layer inside a complete DMARC authentication chain — not as a standalone checkbox.
How to publish your SPF record
step 1─────────>
step 2─────────>
step 3─────────>
step 4─────────>
step 5
1. Step 1:Use an SPF checker to read your current v=spf1 record and count the DNS lookups it requires. Simultaneously, analyze 2-4 weeks of DMARC aggregate reports to identify every IP and service actively sending email for your domain. Build a list of authorized senders — distinguish between active providers (keep), legacy providers (remove), and unauthorized senders (investigate).
2. Step 2:For every include: in your SPF record, verify the provider is actively sending email for your domain today. If a vendor was replaced, removed, or consolidated, delete their include: from your SPF record immediately. Each removed include: is one fewer DNS lookup and eliminates a potential shadow-IT abuse vector. Fix any syntax errors identified by the checker.
3. Step 3:Write a new SPF record that authorizes exactly the mail servers you need. Use ip4: and ip6: for servers with static IPs, include: for cloud providers, and end with -all for hard fail. Test the lookup count. Keep it under 8 lookups to leave headroom for future additions. Example: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all
4. Step 4:Replace your old SPF TXT record with the corrected version. Allow up to 48 hours for global DNS propagation. Re-run your SPF checker to confirm the record is syntactically valid, resolves within the 10-lookup limit, and that your primary mail servers pass. Send a test email through each authorized provider and inspect the Authentication-Results header to confirm spf=pass.
5. Step 5:SPF records drift as teams add new ESPs, marketing tools, and transactional mail providers. Implement continuous SPF monitoring to alert when the record changes, when new unauthorized IPs start sending mail (visible in DMARC reports), or when the lookup count approaches the limit. Review and re-audit SPF quarterly.
Technical Architecture
SPF operates entirely at the DNS level during the SMTP transaction:
Envelope Extraction: The receiving MTA extracts the domain from the Return-Path (MAIL FROM) envelope — often different from the user-visible From: header.
DNS Query: The receiver queries for a TXT record at that domain starting with v=spf1.
Mechanism Evaluation: Mechanisms are evaluated left to right to build the authorized IP list.
IP Matching: The connecting server's IP is compared against the authorized list.
Qualifier Application: The match result is combined with the qualifier (-all, ~all, etc.) to produce the final SPF result.
DNS Record / Config
cyberfurl.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all"
Common Misconfigurations
The 10-Lookup Limit (RFC 7208): Exceeding 10 lookups causes PermError, failing SPF for all mail
Multiple SPF Records: Two v=spf1 records = immediate PermError for all receivers
Stale Vendor Includes: Legacy include: entries for discontinued SaaS tools create shadow-IT abuse vectors
Over-reliance on +all: +all authorizes the entire internet — never use it
Using mx excessively: Each MX record behind mx adds another lookup to the count
Security Risks
Return-Path Spoofing: Without -all, spam filters cannot classify non-matching senders as unauthorized
Shadow IT Abuse: Stale include: entries let attackers use your legacy SaaS tools to send authenticated mail as your domain
Deliverability Breakage: A broken SPF record (PermError from too many lookups) causes legitimate mail — password resets, invoices, MFA tokens — to fail globally
Compliance Impact
NIST Guidelines: Recommend strict SPF as part of anti-phishing and malware defense
HIPAA/GLBA: Require controls over unauthorized communication channels — an open SPF record violates baseline secure communication requirements
Vendor Risk Management: Enterprise buyers scan SPF records during security reviews. An invalid or permissive SPF record stalls procurement
Best Practices for SPF in 2025/2026
Use ip4/ip6 over includes where possible: Direct IP authorization is cheaper (no lookups) and more explicit
Quarterly vendor audit: Remove every include: for tools your organization no longer uses
Always end with -all: Explicit hard-fail signals clear intent to receivers and reduces ambiguity
Pair with DMARC: SPF alone does not protect the visible From: address — always pair with DMARC enforcement
Tools to check your SPF
Use the CyberFurl SPF validator as your primary SPF checker to inspect the live record on any domain. A comprehensive SPF lookup shows the full mechanism chain, lookup count, resolved IPs, and any syntax errors. After fixing your record, re-run the SPF record checker to confirm the corrected version is clean and within the lookup limit. For continuous monitoring that alerts on drift, unauthorized senders, and record changes, combine the SPF checker with Email Security monitoring.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl continuously monitors your public SPF record and DMARC aggregate reports together, automatically detecting 10-lookup limit violations, syntax errors, unauthorized sender IPs, and stale vendor includes. When a new ESP is added without updating SPF, CyberFurl flags the misalignment in DMARC reports before it becomes a deliverability incident.
An SPF record is a DNS TXT record published at your domain root (example.com) that lists all the mail servers and IP addresses authorized to send email on your domain's behalf. When a receiving mail server (MTA) gets an email claiming to be from your domain, it queries your DNS for the SPF record and checks whether the sending server's IP address is in the authorized list. If the IP is not listed and your SPF record ends with -all (hard fail), the message can be rejected or flagged. SPF protects the envelope sender (Return-Path) domain — not the visible From address, which is why it must be paired with DMARC for complete spoofing protection.
What is the SPF 10-lookup limit?
RFC 7208 limits SPF processing to 10 DNS lookups. Each include:, a, mx, exists, and redirect mechanism counts as one lookup. If your record requires more than 10 lookups to fully resolve, receivers return a PermError — which causes SPF to fail for all mail from your domain, even legitimate mail. This happens when organizations accumulate multiple email service providers (ESPs), each adding their own include: statement. The fix is to audit and remove stale providers, replace expensive mechanisms with direct ip4:/ip6: entries where possible, or use SPF macro flattening as a controlled solution.
What's the difference between ~all (softfail) and -all (hardfail)?
The qualifier at the end of your SPF record determines how receivers handle mail that does not match any authorized sender. ~all (tilde, softfail) marks non-matching mail as suspicious but still delivers it — most receivers will tag it or pass it to spam filters. -all (dash, hardfail) marks non-matching mail as a definitive failure — well-configured receivers should reject or quarantine it. For domains with DMARC enforcement, the distinction matters less because DMARC overrides SPF's own disposition. However, -all is still the recommended default because it signals explicit intent. Never use +all (pass all) — this authorizes the entire internet to send as your domain.
Can I have multiple SPF records?
No. RFC 7208 explicitly states that a domain must have exactly one TXT record starting with v=spf1. If you publish two or more SPF records for the same domain, receivers return a PermError (permanent error) and SPF fails entirely for all mail — including legitimate mail. The correct approach is to merge all your authorized senders into a single SPF record using multiple include: statements or ip4:/ip6: ranges. If you need to authorize many senders, count your DNS lookups carefully to stay under the 10-lookup limit.
How do I fix the 'too many DNS lookups' SPF error?
Start by auditing your current SPF record with a checker tool and counting exactly how many lookups it requires. Then remove stale include: entries for ESPs and mail services you no longer use — this is usually the quickest win. For remaining providers, check if they publish a dedicated SPF IP list you can reference with ip4: instead of include:. As a last resort, use SPF flattening (resolving all includes to direct IPs), but be aware that flattening shifts the maintenance burden to you — you must update the IPs when the provider changes their infrastructure.
Does SPF stop email forwarding?
SPF deliberately breaks when email is forwarded, because the forwarding server's IP is typically not listed in the original sender's SPF record. This is a known limitation of SPF by design. For domains with DMARC, this creates a real problem: forwarded mail fails SPF alignment, which contributes to DMARC failures. The solution is DKIM — unlike SPF, a valid DKIM signature survives forwarding because it is carried in the message headers, not tied to the sending IP. For complex forwarding scenarios across mailing lists and security gateways, the ARC (Authenticated Received Chain) protocol preserves authentication results across hops.
How do I fix SPF when I have multiple email providers?
Consolidate all providers into a single SPF record using include: statements ordered from highest to lowest traffic volume. Check the total DNS lookup count first — each include: consumes one lookup and the RFC 7208 limit is 10 total. A common multi-provider pattern: v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com -all. If adding all providers exceeds 10 lookups, audit which providers are still actively sending on your behalf and remove stale entries first. For providers with static IP ranges, replace include: with ip4:/ip6: to eliminate the lookup cost.
Does SPF protect the From address that email users actually see?
No — this is the most important SPF misconception. SPF only validates the Return-Path (envelope sender) domain, which is a routing address that email clients typically hide from users. Attackers can pass SPF on the envelope sender while forging a completely different visible From address. The visible From address is only protected by DMARC alignment, which requires that the SPF-authenticated domain aligns with the From domain. This is why SPF alone does not stop spoofing — you need DMARC to connect the technical envelope authentication to the address your users actually see.
