Free SPF Record Checker
Validate your domain's SPF configuration in seconds. Check record syntax, DNS lookup count, include chains, and policy strength — all in one scan.
Free, no account required. Enter any domain to get started.
What is SPF?
SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208. It allows domain owners to publish a DNS TXT record that lists every server authorized to send email on behalf of their domain. When a receiving mail server gets a message, it checks the sender's IP address against the domain's SPF record to determine whether the server is permitted to send for that domain.
Without SPF, anyone can send email claiming to be from your domain. Attackers exploit this to send phishing emails, deliver malware, and impersonate your brand. SPF provides the first layer of defense by giving receiving servers a way to verify that the sending server is legitimate.
An SPF record is a single TXT record published at your domain's root. It starts with v=spf1 and contains a series of mechanisms (like include:, ip4:, a) that define which servers are allowed, followed by an all mechanism that specifies how to handle unauthorized senders.
SPF is one of the three pillars of email authentication, alongside DKIM and DMARC. While SPF verifies the sending server, DKIM verifies message integrity, and DMARC ties them together with a policy that tells receivers what to do when authentication fails. All three are essential for comprehensive email security.
What this checker verifies
Our SPF checker performs a comprehensive analysis of your domain's SPF record and reports issues with clear explanations.
Record Presence & Syntax
Verifies that your domain publishes exactly one SPF TXT record and that it follows the correct syntax, including a valid version tag (v=spf1) and properly formatted mechanisms.
DNS Lookup Count
Counts the total number of DNS lookups triggered by your SPF record, including nested includes. Flags records that exceed or approach the strict 10-lookup limit defined in RFC 7208.
Include Chain Validation
Recursively resolves every include, redirect, and exists mechanism in your SPF record to verify the entire chain is valid, reachable, and free of circular references.
Policy Strength
Evaluates your SPF "all" mechanism to assess policy strength. Distinguishes between -all (hard fail), ~all (soft fail), ?all (neutral), and +all (open), and recommends the appropriate level for your domain.
The 10-Lookup Limit
The single most common SPF problem is exceeding the 10-DNS-lookup limit. RFC 7208 strictly limits the number of DNS-querying mechanisms in an SPF evaluation to 10. This includes include, a, mx, redirect, and exists — and every nested include counts toward the same limit.
When a receiving server encounters an SPF record that exceeds 10 lookups, the result is a permanent error (permerror). This means your SPF record is effectively broken, and most receivers will treat it as if SPF failed entirely. The dangerous part is that this failure is silent — you will not receive a bounce or error message. Your emails may simply land in spam or be rejected, and you have no way to know unless you actively monitor your SPF record.
This problem grows over time as organizations add more third-party services. Each SaaS tool that sends email on your behalf (marketing platforms, CRM systems, helpdesk software, transactional email providers) typically requires its own include: mechanism, and those includes often contain nested includes of their own. It is easy to go from 4 lookups to 12 without realizing it.
Our SPF checker counts every DNS lookup in your record, including nested ones, and tells you exactly where you stand. If you are over the limit, read our guide on fixing the SPF “too many DNS lookups” problem.
SPF Best Practices
Follow these recommendations to keep your SPF record healthy and your email authentication reliable.
- Keep your record under 10 DNS lookups — use ip4/ip6 mechanisms for your own servers to save lookups for third-party includes.
- Use -all (hard fail) once you have confirmed all legitimate senders are listed. Start with ~all during initial setup.
- Publish exactly one SPF record per domain. Multiple v=spf1 records cause a permanent error (permerror) and break authentication entirely.
- Audit your SPF record quarterly. Remove services you no longer use and verify that third-party includes are still valid.
- Flatten cautiously. Replacing includes with raw IP addresses can reduce lookups, but you lose automatic updates when the provider changes IPs.
- Use the include mechanism for third-party senders (Google Workspace, Microsoft 365, Mailchimp, etc.) rather than listing their IPs directly.
Monitor your SPF record continuously
A one-time check is not enough. DNS changes, new services, and provider updates can silently break your SPF. MailShield monitors your record around the clock and alerts you the moment something changes.