SPF record checker.
Validate a domain's SPF record with every include followed and every DNS lookup counted. Use it before a client mail migration, or when a new sender quietly pushes SPF over the limit.
More than a TXT lookup.
Most SPF problems hide below the surface of the record you published. The checker evaluates the record the way a receiving mail server does.
record presence & uniqueness
A domain must publish exactly one v=spf1 TXT record. Zero means no policy; two or more is a permanent error that breaks SPF entirely.
syntax validation
Every mechanism and modifier is parsed per RFC 7208: unknown mechanisms, malformed IP networks, bad CIDR prefixes, duplicate redirects, and invalid macros.
include & redirect chains
Each include and redirect is fetched and validated recursively, so a broken record three providers deep still shows up in your result.
the 10-lookup limit
include, a, mx, ptr, exists, and redirect each cost a DNS lookup, and receivers stop at 10. We count the whole tree so you know how close you are.
void lookups
Includes that point at domains with no SPF record count against a separate limit of two — a common leftover from providers you stopped using.
policy strength
A record ending in +all allows anyone to send as you. We flag permissive and neutral policies, including a +all hidden inside an include.
The SPF mistakes we see most.
too many DNS lookups
Every SaaS tool asks for one more include, and each include can hide several more. Past 10 lookups, receivers return a permanent error and your SPF stops working — usually silently.
multiple SPF records
Someone adds a second v=spf1 record instead of merging into the existing one. Receivers treat this as a permanent error, so both records stop counting.
permissive all
+all (or a bare all) tells the world any server may send as your domain. It usually gets pasted from a bad example and defeats the point of SPF.
dead includes
Includes pointing at providers you left years ago still cost lookups, and once the provider deletes their record they become void lookups that can fail the whole evaluation.
typos and syntax errors
ip4 networks with impossible octets, unknown mechanisms from typos like “inlcude”, or CIDR prefixes out of range — one bad term makes the record permanently invalid.
SPF questions, answered.
SPF (Sender Policy Framework) is a DNS TXT record, starting with v=spf1, that lists the servers allowed to send email for your domain. Receiving mail servers look it up during delivery and use it to decide whether the sending server is authorized, which feeds into spam filtering and DMARC.
RFC 7208 caps SPF evaluation at 10 DNS-lookup-causing terms (include, a, mx, ptr, exists, and redirect), counted across the whole include chain. Go over and receivers return a permanent error, which means your SPF fails even though the record looks fine. It is the most common way SPF silently breaks as teams add sending services.
-all (fail) tells receivers to reject mail from servers not in the record, while ~all (softfail) only asks them to treat it with suspicion. -all is the strongest policy, but ~all is a sensible choice while you confirm every legitimate sender is listed, and it is sufficient for DMARC alignment.
Yes. Without SPF, receivers have no way to tell your real mail from a spoofer's, so your legitimate mail is more likely to land in spam and your domain is easier to impersonate. It is also one of the two ways (with DKIM) to pass DMARC.
Remove includes for services you no longer use, replace mechanisms like mx or a with explicit ip4/ip6 networks where the addresses are stable, and consider SPF flattening for large provider includes. Re-check after each change — nested includes make the count hard to predict by hand.
Not by itself. SPF checks the envelope sender, which spoofers can work around, and it breaks on forwarded mail. Real spoofing protection comes from DMARC, which ties SPF and DKIM to the From address your recipients actually see and lets you tell receivers to reject failures.
SPF is one part of the client domain.
The free scan checks email auth & DMARC, SSL & domain expiry, look-alikes, and blacklists together from public records. One result, no signup.
Keep checking the same failure point.
Use the related tools one at a time, or run all four posture checks together.
DNS lookup →
Query A, AAAA, CNAME, MX, NS, SOA, TXT, and CAA records in parallel and share one result.
DMARC record checker →
Parse every DMARC tag, grade the policy, and flag weak enforcement or missing reporting.
DKIM record checker →
Probe common selectors, validate each public key, and flag weak, revoked, or broken records.