Free tool · no signup
Free SPF checker
Check your SPF record on any domain, follow every include it points to, and see whether it stays inside the ten DNS lookups the standard allows. Going over breaks SPF silently.
Ungated · no email required · unlimited checks
In short
- This is a free, ungated SPF checker. It reads the TXT record published on a domain, resolves every include, a, mx, exists and redirect term it contains, and reports whether the record is valid and how many of the ten permitted DNS lookups it uses.
- SPF (Sender Policy Framework) is an email authentication standard defined by RFC 7208. A domain owner publishes, in DNS, the list of mail servers allowed to send email for that domain, and receiving servers check the connecting server against that list.
- RFC 7208 §4.6.4 limits an SPF evaluation to ten DNS-querying terms. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost one lookup; ip4, ip6 and all cost nothing. The limit applies across the entire include tree, not per record, so a record with only two includes can still exceed it.
- Exceeding the ten-lookup limit is a permerror, and most receivers treat a permerror as though the domain published no SPF record at all. The record still looks valid, which is why this fault commonly goes unnoticed.
- A domain may publish only one v=spf1 record (RFC 7208 §4.5). Two records is a permerror and receivers do not merge them. Void lookups, meaning lookups that return NXDOMAIN or an empty answer, are separately capped at two.
- SPF validates the envelope sender rather than the visible From address, so it does not stop spoofing on its own. It works alongside DKIM and DMARC, and Gmail and Yahoo require bulk senders to have all three configured.
Enter the domain your mail is sent from. We read the live record, follow every include it points to, and add up the DNS lookups the way a receiving server does.
The shape of it
The three parts of an SPF record
The version tagAlways first, always exactly this. Without it the record is not SPF and receivers ignore it.
The sendersOne term per system that sends for you. Each include, a, mx, ptr and exists costs one of your ten lookups.
The catch-allWhat receivers do with everyone else. Evaluation stops here, so anything after it is never read.
The other two records
SPF is one of three checks
Receivers run SPF, DKIM and DMARC together. A perfect SPF record still fails you if the other two are missing or misconfigured, and SPF alone cannot stop spoofing.
Proof the message is really yours
DKIM Checker
DKIM signs every message with a key only you hold. Check that the public key is published, parses, is not revoked, and is long enough to be trusted.
What it looks like
v=DKIM1; k=rsa; p=MIIBIjANBgkq…
What happens when a check fails
DMARC Checker
Coming soonDMARC tells receivers whether to quarantine or reject mail that fails SPF and DKIM, and where to send the reports. Check your policy, alignment and reporting address.
What it looks like
v=DMARC1; p=reject; pct=100
The basics
What an SPF record is
SPF, or Sender Policy Framework, is how you tell the rest of the internet which servers are allowed to send email using your domain name. It is one TXT record, and it works in three moves.
Publish the list
One TXT record on your domain names every server and service allowed to send mail as you.
Looks it up
On every incoming message, Gmail or Outlook reads your record and resolves the includes behind it.
Pass, or your policy
If the sending server is on the list, SPF passes. If not, your all mechanism decides what happens next.
SPF checks the envelope sender, the return-path address used during delivery, not the From address a recipient sees in their mail client. That gap is why SPF on its own does not stop spoofing, and why DMARC exists to require the two to line up. Google and Yahoo both require bulk senders to authenticate with SPF, DKIM and DMARC.
The fault that hides
The SPF 10 DNS lookup limit, explained
An SPF record may trigger at most ten DNS lookups, and the count runs across every include, not just the ones in your own record.
RFC 7208 §4.6.4 sets the limit. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost one lookup. The ip4, ip6 and all mechanisms cost nothing at all, so a record listing fifty address ranges is perfectly valid while a much shorter one with eight includes can be over.
The part that catches people is that the budget is spent across the whole tree. If you include a provider whose own record contains three includes, all four count against your ten. Go over and the result is a permerror, which most receivers treat as though you had published no SPF record at all. Nothing about the record looks wrong, so this usually goes unnoticed until deliverability drops.
Thirty seconds
How the SPF checker works
Enter your domain
The domain your mail is sent from, for example example.com. A full URL or an email address works too.
We read your record
The tool queries live DNS for the TXT record on your domain and finds the one that starts with v=spf1.
We follow every include
Each include is resolved, then the includes inside it, all the way down, because the ten-lookup budget is spent across the whole tree and not just your record.
Read the verdict
You get the running lookup count, the full include tree, your policy in plain language, and every syntax error, dead include and deprecated term we found.
Macros (RFC 7208 §7.1) such as %{i} expand differently for every sender, so no static checker can resolve them. Where your record uses one, the lookup is still counted, because a receiving server pays for it too, and the term is reported as sender-dependent rather than as resolved.
Read your record
What each mechanism does, and what it costs
Every term defined by RFC 7208, and whether it spends one of your ten. If you run Google Workspace or Microsoft 365, the include line each of them gives you is a single lookup on its own, but the record behind it is not — which is why an SPF lookup has to follow the whole tree.
| Term | Cost | What it does |
|---|---|---|
| ip4 / ip6 | Free | Authorises an address or a CIDR range directly. Costs no DNS lookup, so you can list as many as you like. |
| include | 1 lookup | Pulls in another domain’s SPF record, usually a provider’s. Everything inside it counts against your ten as well. |
| a | 1 lookup | Authorises whatever the domain’s A record points at. Often left over from a template and no longer sending mail. |
| mx | 1 lookup | Authorises your inbound mail servers. Your MX hosts usually receive mail rather than send it, so check you need this. |
| exists | 1 lookup | Passes if a name resolves. Almost always used with a macro so the name varies per sender. |
| ptr | 1 lookup | Deprecated by RFC 7208 §5.5. Slow, unreliable, ignored by some receivers, and it still costs you a lookup. Remove it. |
| redirect= | 1 lookup | Hands evaluation to another domain’s record entirely. Ignored whenever an all mechanism is also present. |
| all | Free | The catch-all at the end, and the actual policy. Everything after it is never evaluated. |
What usually breaks
The three faults worth knowing
Over the ten-lookup limit
A permerror. Receivers behave as though you published nothing at all, so every sender loses SPF at once. The record still looks perfectly valid, which is why this goes unnoticed for months.
Two SPF records on one domain
RFC 7208 allows exactly one, and receivers do not merge them. Usually caused by adding a new tool’s record instead of merging its include into the existing one. Combine them into a single record.
A policy that decides nothing
Neutral tells receivers you have no opinion about unlisted senders, which is exactly the protection you get from publishing no record. Use ~all while you verify your senders, then move to -all.
Over the limit
How to get back under ten lookups
Remove tools you no longer use
Every ESP, helpdesk and CRM you have ever trialled probably left an include behind. Audit the list against what actually sends mail today. This is where the easy lookups are.
Drop a and mx if they do not send
Both are frequently copied from a template. Your MX hosts receive mail; unless they also send it, the mx mechanism is buying you nothing and costing a lookup.
Delete any ptr mechanism
Deprecated by RFC 7208 §5.5, ignored by some receivers, slow for the rest, and it still spends one of your ten. There is no case for keeping it.
Swap a vendor include for its ip4 ranges
Where a vendor publishes stable addresses, listing them directly costs nothing. The trade is that you now own keeping them current, so only do this where the vendor documents the ranges as fixed.
The ptr mechanism is deprecated by RFC 7208 §5.5, so removing it is free of any downside. Work down that list before reaching for an SPF flattening service. Flattening resolves your includes into raw IP ranges, which does fix the count, but it moves the job of tracking every provider's address changes onto that service. When a vendor rotates addresses and the flattened record has not caught up, mail from a legitimate sender starts failing.
Once SPF passes
Or skip the DNS editing entirely
Every sending tool you bolt on spends part of the same ten-lookup budget. SmartReach hands you sending domains and mailboxes with all three records already in place, then keeps the reputation behind them healthy.
- Sending domains and mailboxes bought and authenticated in minutes, no IT ticket
- SPF, DKIM and DMARC configured for you, so there is no record to hand-edit
- Warmup, inbox rotation and ESP matching across unlimited sending accounts
- Every address verified free before a campaign sends, so bounces never touch your domain
“This software is focused on the end receiver as much as the user.”Matt McQuin · Co-founder, ColdlyticsEvery rule on this page is checked against RFC 7208, the specification that defines SPF. Last reviewed .
FREQUENTLY ASKED QUESTIONS
SPF questions, answered
Stop fixing deliverability one DNS record at a time.
SmartReach buys and authenticates your sending domains and mailboxes with SPF, DKIM and DMARC already in place, then warms them, rotates them, and verifies every address before you send.