SPF Record Checker
Look up a domain's SPF record, see which servers are authorized to send its mail, and catch the errors that silently break protection — the 10-lookup limit, a missing or weak all-qualifier, and duplicate records.
Live DNS lookup via DNS-over-HTTPS. We only read public DNS records.
What the SPF check validates
The tool looks up your domain's TXT records, isolates the one beginning with v=spf1, and checks the two things that most often break SPF:
- The 10-lookup limit — too many
include:statements push you over the cap and cause a permerror. - The all qualifier — whether unlisted senders are rejected (
-all), softly failed (~all), or dangerously allowed (+all).
It also flags the invalid case of multiple SPF records on one domain.
SPF is necessary but not sufficient
SPF authenticates the envelope sender, not the visible From: address — so on its own it doesn't stop display-name spoofing. It works as one of the two checks (with DKIM) that DMARC aligns to the From: domain. Build a clean record with the SPF generator.
SPF mechanisms and qualifiers reference
An SPF record is a single v=spf1 string built from mechanisms (which authorize senders) and qualifiers (which set the result when a mechanism matches). Receivers read the record left to right, and the first mechanism that matches decides the outcome. Use this reference when you run an spf record check and need to know exactly what each token does.
include:_spf.google.comauthorizes the sending IPs published in another domain's SPF record; this is a DNS lookup and counts toward the cap of 10.aauthorizes the IPs in the domain'sAandAAAArecords (counts as one lookup).mxauthorizes the IPs of the domain'sMXmail exchangers (counts as one lookup).ip4:198.51.100.0/24authorizes a literal IPv4 address or CIDR range (no DNS lookup, so it is free against the limit).ip6:2001:db8::/32authorizes a literal IPv6 address or range (also no DNS lookup).exists:%{i}._spf.example.compasses if the constructed hostname resolves to anyArecord; used for macro-based conditional rules (counts as one lookup).ptrmatches on the reverse DNS of the connecting IP; discouraged by RFC 7208 because it is slow and unreliable, and many receivers skip it.redirect=_spf.example.comhands evaluation entirely to another domain's SPF record; use it instead of anallmechanism, never alongside one.allmatches everything, so it always goes last and sets the default result for any sender not matched above.+(pass),-(fail),~(softfail), and?(neutral) are the four qualifiers that prefix a mechanism; a mechanism with no prefix defaults to+. In practice you mostly set them onall:-allrejects unlisted senders,~allmarks them suspicious but delivers,?alldoes nothing, and+allauthorizes the entire internet and must never be published.
A well-formed record reads like v=spf1 include:_spf.google.com ip4:198.51.100.10 -all. Build one that stays inside the lookup budget with the SPF generator, then confirm the matching signatures with the DKIM checker.
Why SPF can pass and spoofed mail still lands
An SPF pass is narrower than most people assume. SPF authenticates the envelope MAIL FROM (the Return-Path, also called the bounce address), not the From: header your recipients actually see. An attacker can register their own domain, publish a valid v=spf1 record for it, and send mail that passes SPF while the visible From: shows your brand. The check succeeded, but it validated the wrong identity, which is the core mechanic behind email spoofing.
Only DMARC closes that gap through alignment: it requires the SPF-authenticated envelope domain (or the DKIM signing domain) to match the From: domain the recipient sees. Without a published DMARC policy at p=quarantine or p=reject, a passing SPF result says nothing about whether the From: address is genuine. Publish and monitor policy with the DMARC checker.
Forwarding is the other reason SPF alone is fragile. When a mailing list or a forwarding rule relays your message, the connecting IP becomes the forwarder's server, which is not in your SPF record, so SPF fails on the way to the final recipient unless the forwarder rewrites the envelope with SRS (Sender Rewriting Scheme). Because the forwarder does not break the DKIM signature, DKIM survives forwarding where SPF does not. That asymmetry is exactly why DKIM and DMARC are required rather than optional additions to SPF.
Frequently asked questions
What is an SPF record?
SPF (Sender Policy Framework) is a TXT record that lists which mail servers and IP addresses are allowed to send email for your domain. Receiving servers check it to detect forged senders. It starts with v=spf1 and ends with an 'all' mechanism that sets what happens to unlisted senders.
What is the SPF 10-lookup limit?
SPF allows a maximum of 10 DNS-lookup mechanisms (include, a, mx, ptr, exists, redirect) when it's evaluated. Exceed it and SPF returns a permerror, which can cause legitimate mail to fail authentication. Flatten or consolidate includes to stay under the limit.
What does ~all vs -all mean?
The qualifier on 'all' decides enforcement: -all (hard fail) tells receivers to reject mail from any server not listed; ~all (soft fail) marks it as suspicious but still accepts it; ?all (neutral) does nothing; +all authorizes everyone and must never be used. Aim for -all once you're confident every legitimate source is listed.
Can I have more than one SPF record?
No. A domain must publish exactly one SPF record. Two or more v=spf1 records is invalid and causes a permerror, effectively breaking SPF. Merge all your includes and mechanisms into a single record.
What is an SPF permerror and what causes it?
A permerror (permanent error) means the SPF record could not be evaluated because it is malformed or exceeds a hard limit, so receivers cannot make an authentication decision from it. The most common causes are exceeding the 10 DNS-lookup limit, publishing two or more separate v=spf1 records on one domain, a syntax mistake such as a stray character or an unknown mechanism, or an include that points at a domain with no SPF record. A permerror often causes DMARC to treat SPF as failed, which can send legitimate mail to spam or rejection.
Does SPF survive when mail is forwarded?
Usually not. When a message is forwarded by a mailing list or a forwarding rule, the sending IP seen by the final receiver belongs to the forwarding server, not your original mail server, so that IP is not listed in your SPF record and SPF fails. SPF only survives forwarding if the forwarder implements SRS (Sender Rewriting Scheme), which rewrites the envelope Return-Path to a domain the forwarder controls. DKIM, by contrast, normally survives forwarding because the cryptographic signature stays intact, which is one reason DMARC accepts either SPF or DKIM alignment.
How do I fix a too many DNS lookups permerror?
Count the mechanisms that trigger DNS lookups: include, a, mx, ptr, exists, and redirect. Nested includes count too, so one include can consume several lookups. Reduce the total below 10 by removing unused includes for services you no longer send from, replacing an a or mx mechanism with the explicit ip4 and ip6 ranges it resolves to (literal IP mechanisms do not count against the limit), and consolidating multiple vendors where possible. Avoid ptr entirely. If you still cannot get under 10, SPF flattening is the last resort.
What is SPF flattening and what are its trade-offs?
SPF flattening replaces include mechanisms with the actual ip4 and ip6 addresses those includes currently resolve to, collapsing many DNS lookups into a static list that fits under the 10-lookup limit. The benefit is that you avoid permerror and keep the record valid. The trade-off is maintenance: when a provider such as your email platform changes its sending IPs, your flattened record becomes stale and legitimate mail can start failing, so a flattened record needs automated monitoring and regular refreshing. It also tends to grow long, which can push you toward the 255-character-per-string TXT limit.
Related free tools
Authenticated email is step one.
PhishEye covers the impersonation email auth can't — lookalike domains, scam sites, and fake apps abusing your brand.