SPF checker
Who is allowed to send email as you?
Your SPF record is the list. We read it, count its DNS lookups against the hard limit of ten, and tell you what really happens to a sender that is not on it.
One second, straight from public DNS. Nothing is sent, nothing is signed in to.
Checking
Reading your domain
Your result
Rather not do it yourself?
We will publish all three records for you.
Everything above is yours to use — the records are public and every step is on this page. This is only for when you would rather not edit DNS yourself.
Written scope and a price in writing before anything is touched. Your records, your DNS, your control.
The fix
Build the list first. Tighten it last.
Publishing SPF is five minutes. Knowing what to put in it is the actual work — and doing those two in the wrong order is what breaks people’s mail.
Do this one today, if it applies
If your record ends +all, change that ending to ~all now.
+all explicitly authorises the entire internet to send as you — it is worse than
publishing nothing at all. It is the only SPF change safe to make without evidence.
Step by step: writing the record
Wherever your domain is managed — usually where you bought it, or whoever hosts your website.
include: line to use. It is the same for all their customers.include:.~all:@.If the lookup count comes back over ten
Every include: costs one lookup, and some includes contain includes of
their own — so four lines can easily cost twelve. Past ten, receiving servers may stop reading the
record and your own mail can start failing. Remove services you no longer use; that is usually enough.
And the step almost everyone skips
Do not change ~all to -all yet. Publish a
DMARC record first and read a few weeks of reports — they name every server genuinely sending as
you, including the one nobody remembers signing up for. Tighten once that list is complete, and nothing
of yours ever stops arriving.
What happens next
“I tightened it, and our invoices stopped arriving.”
This is the single most common disaster in email configuration, and it is always the same cause: one service that legitimately sends as you was not on the list when the record was made strict.
Why it is silent
A message refused by SPF does not bounce back to you. It is dropped at the receiving end. Your invoicing tool reports the email as sent, your customer never gets it, and nothing anywhere tells you.
That is why we never hand you a strict record. We cannot see a service that sends on your behalf from a server we have no way to detect from outside — and a record built on that guess would be the thing that breaks your mail.
The safe route is to publish DMARC first, read a few weeks of reports to find every real sender, and only then tighten. The DMARC page walks through it.
Why it matters
The list is right. The last word is wrong.
Almost every business we check has a correct list of senders that ends in an instruction to let everyone else through anyway. The list is there. It is simply not being enforced.
What the soft ending actually says
It tells every receiving server: this sender is not on my list — mark it as suspicious and deliver it anyway.
So a message from a server you have never heard of, carrying your address, arrives in your customer's inbox with nothing more than a quiet flag nobody sees.
Why nearly everyone has it
Because it is the safe default, and it is correct to start there. A strict ending refuses anything unlisted, and if one of your own services is missing from the list, its mail silently stops arriving.
The mistake is not starting soft. It is never coming back.
What is SPF
A guest list — and what the doorman does with it.
Anyone can put your address in the From field of an email. SPF is how you publish, in public, which servers are genuinely allowed to send on your behalf.
The list is the easy part. Your mail provider, your invoicing software, your newsletter tool — each publishes one line to include.
The last word is the whole decision. It tells the doorman what to do about somebody not on the list: turn them away, or let them in with a note attached.
The four endings
+all is worse than publishing nothing — it is an explicit invitation. We check for it, and it is the one SPF change worth making the same day.
What it reads
The record, the ending, and the limit nobody mentions.
The record itself
Exactly as published, character for character, with nothing summarised away.
The ending
Soft, strict, indifferent or reckless — and what that means for an unlisted sender.
Lookups used
SPF allows ten DNS lookups. Past that, receivers may stop reading your record entirely.
More than one record
Two SPF records is the same as none — receivers treat it as an error.
DKIM
SPF alone is not enough. We check whether your mail is signed as well.
DMARC
The record that decides whether an SPF failure actually stops anything.
MX
Which servers receive your mail — and the clue to which include line you need.
The verdict
One sentence on whether a forged message from your address gets delivered.
See it working
Type a domain — and see the list and the ending.
No account, no verification email. SPF records are public; the only reason you have not read yours is that it is one long line of machine syntax.
What you get back
The record as published, what its ending really does, and the lookup count — the one number nobody checks until their own mail starts failing.
The sentence
“Four senders are allowed, but the record needs twelve DNS lookups — past the limit of ten, so receivers may stop reading it altogether.”
Plus the command to check it yourself.
A real result
Our own record, and what is wrong with it.
include: costs one, and going past ten can make receivers ignore the record entirely.~all. Anything sent from a server not on that list is marked and delivered anyway — so in practice the list stops nothing.dig ihayz.com TXTpublished, permissiveWhy we have not tightened our own
Because we have not finished reading our own DMARC reports. Publishing -all before knowing every service that sends as us would be exactly the mistake this page warns about — and it would be a poor advertisement for the advice.
How it goes from here
Four steps, in this order, for a reason.
Read it
You type a domain. We show the record, its ending and the lookup count. Seconds, free, no account.
Fix only the reckless
If it ends +all, change that today. Everything else waits for evidence.
Find your real senders
Publish DMARC, collect a few weeks of reports. They name every server sending as you, including the forgotten ones.
Then tighten
Add anything missing, and only now change ~all to -all. Done in this order nothing of yours stops arriving.
Questions
Before you ask.
What is the difference between ~all and -all?
Both describe what to do with a sender that is not on your list. ~all is a soft fail: mark it as suspicious and deliver it anyway. -all is a hard fail: refuse it. Only the second one actually stops anything, and it is only safe once you know every service that legitimately sends as you.
Why does the number of DNS lookups matter?
SPF allows a maximum of ten. Every include:, a, mx or redirect costs one, and some includes contain includes of their own. Go past ten and receiving servers are entitled to stop evaluating your record — which can make your own legitimate mail start failing, for a reason nothing reports.
Can I have two SPF records?
No. Publishing two is treated as an error and receivers may apply neither, which leaves you worse off than having one. If you need to add a sender, edit the existing record and add another include: to it.
Why will you not give me a strict record?
Because we can only see your domain from the outside. A billing tool, a booking system or a form notifier may send as you from a server we have no way to detect. A strict record built on that guess would silently stop those messages arriving — and nothing would bounce to tell you.
My SPF looks correct but mail still goes to spam.
SPF is one of three signals. Without a DKIM signature and a DMARC policy, receiving servers still have little reason to trust you. This check reads all of them, so you can see which part is actually missing rather than guessing.
Does SPF stop someone forging my address?
On its own, almost never. SPF describes who may send; DMARC is what tells receiving servers to act on a failure. A domain with perfect SPF and no DMARC can still be forged, and that is the most common result we see.
Guardrails
We read. We never change.
This tool touches nothing. Everything it reports comes from public DNS, and every change is one you make yourself, at your own host, in your own time.
We ran it on ourselves
Fourteen domains. Eleven had nothing.
Before publishing this we pointed it at every domain we own. It is not a flattering result, and that is rather the point — nobody checks, including the people who should.
| What we found | Domains |
|---|---|
| No DMARC record at all — anyone could forge them | 11 |
DMARC published but p=none — enforcing nothing | 2 |
| Actually protected | 0 |
Find out in a second. Fix it in five minutes.
No sign-up, no mailbox access, no obligation. If it turns out you are already protected, we will tell you that too.
Check my domain