SPF Record Checker: Is Your SPF Record Working?
Mail landing in spam, or a service telling you your SPF is invalid? Enter your domain below. The checker fetches the SPF record, follows every include, counts the DNS lookups against the limit of 10, and lists what to fix in plain language.
How a receiving server uses your SPF record
When a message arrives, the receiving server looks at the domain in the envelope sender and fetches that domain's SPF record: a TXT record that starts with v=spf1. It then checks whether the IP address of the server that just connected is on the list. The result is pass, fail, softfail or neutral, and the receiver weighs it with other signals to decide whether the message goes to the inbox or the spam folder.
SPF checks the envelope sender, not the From address people see in their mail app. Closing that gap is DMARC's job.
SPF terms at a glance
| Term | What it does |
|---|---|
| ip4:192.0.2.0/24 | Allows an IPv4 address or range |
| ip6:2001:db8::/32 | Allows an IPv6 address or range |
| a | Allows the addresses in the domain's own A and AAAA records |
| mx | Allows the addresses of the domain's mail servers |
| include:_spf.example.net | Also allows whatever that domain's SPF record allows |
| exists:name | Allows when a DNS lookup of the name returns an address |
| ptr | Deprecated. Matches by reverse DNS and shouldn't be used |
| all | Matches everything, so it comes last and sets the default result |
A qualifier in front of a term sets the result when it matches: + pass (the default), - fail, ~ softfail, ? neutral. The usual endings are ~all, which marks unlisted senders as suspicious, and -all, which asks receivers to reject them.
Why SPF breaks when you add one more service
SPF allows at most 10 terms that trigger a DNS lookup while a record is evaluated. include, a, mx, ptr and exists count, and so does a redirect modifier. ip4, ip6 and all don't. Lookups inside an included record count towards the same total.
That's how a healthy record goes bad: you add a newsletter tool, a helpdesk, a CRM and a billing system, each with its own include, and some of those includes contain includes of their own. Go over 10 and SPF returns a permanent error. Receivers may then treat every message as if the domain had no SPF at all, and nobody tells you.
- Remove includes for services you no longer use.
- Replace an include with ip4 and ip6 ranges when a provider's addresses are stable.
- Never use ptr.
- Give each sending service its own subdomain where you can. Every name gets its own limit of 10.
- If you flatten includes into addresses, remember that providers change their ranges, so a flattened record needs regular updates.
A safe way to set your SPF policy
- Publish exactly one SPF record per name. Two records are a permanent error.
- Start with ~all while you confirm every legitimate sender is listed, then move to -all when you're sure.
- Remember that SPF isn't inherited. A subdomain that sends mail needs its own record, and a subdomain that never sends mail can publish v=spf1 -all.
- Pair SPF with DKIM and a DMARC policy. Each covers weaknesses in the others.