Free SPF Record Checker
Look up and validate any domain's SPF record — check mechanisms, lookup count, and get actionable recommendations.
How SPF Works Under the Hood
SPF (RFC 7208) is a published allowlist of the servers permitted to send mail for your domain, expressed as a single DNS TXT record. The record starts with v=spf1 and chains together mechanisms evaluated left to right: ip4: and ip6: authorise addresses directly, include: delegates to another domain's record (how you authorise Google, Microsoft, or SendGrid), and mx authorises your inbound mail hosts. The terminal ~all (softfail) or -all (hardfail) declares what receivers should do with everything unlisted.
The constraint that trips up most real-world records is the 10-DNS-lookup limit. Every include, a, mx, ptr, exists, and redirect consumes a lookup — recursively, through every nested include inside your providers' records — and blowing past ten yields a permerror that many receivers, and DMARC, treat as a failure. Domains that accumulate SaaS senders over the years hit this ceiling quietly. The fix is pruning unused includes or flattening: replacing include chains with the underlying ip4/ip6 ranges, which costs zero lookups but must be refreshed when providers change their netblocks.
It also matters to understand what SPF does not do. SPF validates the envelope sender (Return-Path) used during the SMTP transaction — not the From header your users actually see in their mail client. An attacker can pass SPF cleanly with their own domain in the envelope while displaying yours in the From line. Closing that hole is DMARC's job: it requires the SPF-validated domain (or a DKIM signature's domain) to align with the visible From domain. SPF is a necessary foundation, but it only becomes an anti-spoofing control once DMARC sits on top of it.
SPF Concepts Worth Knowing
Frequently Asked Questions
What is an SPF record?
SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks your SPF record to verify the sending server is authorised. This prevents email spoofing and improves deliverability.
What is the SPF 10 DNS lookup limit?
SPF limits you to 10 DNS lookups during evaluation. Each include:, a, mx, ptr, and exists mechanism counts as one lookup. Exceeding 10 causes a "permerror" which can result in SPF failure. Use SPF record flattening to stay within the limit.
What is the difference between ~all and -all?
~all (softfail) means mail from unlisted servers should be accepted but marked as suspicious. -all (hardfail) means mail from unlisted servers should be rejected outright. Use -all for maximum protection.
Does SPF prevent phishing?
SPF alone is not sufficient — combined with DKIM and DMARC, it provides strong protection. DMARC uses SPF and DKIM alignment to protect the visible From header that users see.
Why do most domains use ~all instead of -all?
Softfail (~all) is the forgiving choice during rollout: mail from an unlisted server is accepted but marked, so a forgotten sender — a billing system, a marketing platform someone signed up for — degrades gracefully instead of bouncing. Hardfail (-all) tells receivers to reject outright, which is the right end state once you have a complete inventory of sending services. In practice, once DMARC is deployed the distinction matters less, because DMARC treats anything short of an aligned SPF pass as a failure anyway.
How do I count DNS lookups in my SPF record?
Count every include, a, mx, ptr, exists, and redirect — plus everything they trigger recursively inside included records. The ip4, ip6, and all mechanisms cost nothing. A record combining a couple of provider includes and an mx mechanism can already sit at five or six lookups once the nested includes inside each provider record are expanded. Exceeding ten produces a permerror, which DMARC treats as an SPF failure, so audit the fully expanded tree rather than just the top-level record.
Do subdomains inherit my SPF record?
No. SPF is evaluated against the exact domain in the envelope sender, so mail sent as billing.example.com is checked against the SPF record of billing.example.com, not example.com. Every subdomain that sends mail needs its own record, and subdomains that should never send mail can be locked down explicitly with v=spf1 -all to stop them being spoofed.
Does SPF survive email forwarding?
No — this is SPF's fundamental weakness. When a recipient forwards your mail onward, the forwarding server delivers it from its own IP address, which is not in your SPF record, so the check fails at the final destination. Some forwarders work around this with SRS (Sender Rewriting Scheme), rewriting the envelope sender to their own domain so SPF passes — but that domain no longer aligns with yours for DMARC. This is exactly why DMARC accepts either SPF or DKIM alignment: DKIM signatures survive forwarding when SPF cannot.
Monitor Your Email Authentication Setup
Get notified if your SPF, DKIM, or DMARC records change or break — before it impacts deliverability.