Validate SPF records and see a friendly breakdown of mechanisms, warnings, and estimated DNS lookups.
SPF (Sender Policy Framework) is a TXT record that tells receiving mail servers which hosts are allowed to send mail for your domain. It is a core deliverability control and a common source of configuration mistakes. A proper SPF record limits unauthorized senders while still allowing legitimate services such as your primary mail provider, marketing tools, and transactional platforms. This SPF checker validates the record structure, highlights risky patterns, and estimates DNS lookup usage to keep you within the SPF limit of 10 lookups.
Unlike a basic TXT lookup, this validator parses the SPF mechanisms and modifiers so you can see what they do. It flags dangerous patterns like +all, warns about deprecated mechanisms like ptr, and notes potential self‑include loops. It also shows the estimated number of DNS lookups based on the record itself. That count is only an estimate, because include chains and redirect targets are not expanded here, but it is still a useful indicator when you are close to the limit.
If you publish multiple SPF records, mail receivers may treat your domain as having a permanent error. This is why a single, consolidated SPF record is recommended. Use this page when migrating email providers, adding new sending services, or tightening policy. It is also helpful when users report messages landing in spam, because SPF is often the first signal evaluated by receivers.
If you need related checks, try TXT record check tool and DMARC check DNS lookup.
An SPF record is a TXT record that starts with v=spf1 followed by mechanisms like a, mx, ip4, include, and ends with a policy such as -all or ~all. Example: v=spf1 include:_spf.google.com -all.
+all allows any server on the internet to send mail for your domain. It effectively disables SPF protection and should almost never be used. This checker marks it as a failure.
SPF allows a maximum of 10 DNS lookups for mechanisms that require DNS queries (include, a, mx, ptr, exists, redirect). Exceeding this limit can cause SPF to fail with a permerror.
ptr authorizes senders based on reverse DNS. It is expensive, unreliable, and widely discouraged. Many receivers treat it as unsafe. This checker warns when ptr appears.
No. Multiple SPF records are evaluated as a permanent error. Always combine all sending sources into a single SPF record.
redirect= points SPF evaluation to another domain. It is mutually exclusive with all mechanisms after it and still counts as a DNS lookup.
Common causes include too many DNS lookups through include chains, multiple SPF records, or missing entries for a sending service. Always test after changes.
~all (softfail) is common during transitions. -all is stricter and recommended once you are confident the sending sources are complete.