DMARC · SPF · DKIM · MX checker
Check your DMARC record. Anyone can send email as you.
Your DMARC, SPF, DKIM and MX records decide whether a forged email from your address is delivered or refused. We read all four and answer in one line — then hand you the record that fixes it.
About a second. We read public DNS — never your mailbox, never your domain.
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.
Why it matters
It is not a prank. It is an invoice.
Email carries no proof of who sent it. Anyone can type your address into the From field, and without these records the message lands in the inbox looking exactly like yours.
What actually happens
A customer who owes you money receives a message from your address. Same signature, same wording, different bank account. They pay it, because nothing about it looked wrong.
When it unwinds, they do not blame the forger.
And the quieter cost
Domains with no policy get filtered harder everywhere. Your real invoices, quotes and replies are more likely to sit in spam — and you never find out, because nobody tells you their mail went missing.
Publishing the record helps your own delivery as much as it blocks a forger.
What is DMARC
A note on your door telling the postman what to do.
Email was built without any proof of who sent it. Typing someone else's address in the From field is as easy as writing a false return address on an envelope — and the post still gets delivered.
DMARC is a short note you pin to your own domain, in public, telling every mail server on earth what to do when a message claiming to be from you cannot be verified. Deliver it anyway. Send it to spam. Or refuse it.
Without that note, every server makes its own guess — and the safe guess, for them, is to deliver it. That is why forgery works.
Three notes you can pin
Most businesses have pinned no note at all.
A good number pinned p=none years ago and never went further — which
protects nothing.
What it reads
Four records. Only one of them decides anything.
The first three describe your mail. The fourth tells every receiving server on earth what to do when a message fails them — and most businesses have never published it.
MX — does it receive mail
Which servers answer for the domain. A domain with no mail at all is the easiest of all to forge.
SPF — who may send
The list of allowed servers, and what to do with everything else: ~all lets it through, -all refuses.
DKIM — the signature
Proof a message came from you and was not altered on the way. We test the selectors providers actually use.
DMARC — the instruction
Deliver it anyway, send it to spam, or refuse it. This is the only record with teeth.
Where reports go
Whether anyone is collecting evidence at all, and which address receives it.
Alignment
Whether the visible From address must match the signed one, or whether a lookalike passes.
Subdomains
A policy on the domain does not always cover mail.yourdomain.com. We say which.
What to change first
The one entry to add today, and what it is safe to tighten to after two weeks of reports.
See it working
Type a domain — and watch four records arrive.
No account, no verification email, no waiting. The answer is public information; the only reason you have not seen it is that nobody reads DNS by hand.
What you get back
One sentence in plain words, then the evidence under it. Never a score out of a hundred — a number tells you nothing about what to change.
The sentence
“Yes — anyone can send email pretending to be this domain, and it will be delivered.”
Underneath it: each record exactly as published, the command to check it yourself, and the one DNS entry that fixes it.
A real result
Our own domain, before we fixed it.
Every line read live, every line checkable — the command is printed underneath so you never have to take our word for it.
~all, a soft fail: anything else is marked suspicious and delivered anyway. The strict ending is -all.zmail selector. Outgoing mail can be proven to be yours.p=none tells every receiving server to take no action and send a report. The forgery is noticed and delivered.dig _dmarc.ihayz.com TXTnot protectedThe fix
One record. Yours, free, today.
Add this at your DNS host. The first setting changes nothing about delivery — it only starts the reports that show who is sending as you.
Read this before you paste it
The rua= part asks every mail provider to send you a report.
They will — daily, starting about a day after you publish, and continuing forever.
Point it at an address you do not read every morning. Otherwise you will
switch DMARC off within a week, like most people do. There is a section on this below.
Step by step: publishing the record
Wherever your domain is managed — usually the company you bought it from, or whoever hosts your website. The screens differ between providers. These seven steps do not.
_dmarc — with the underscore.If step 3 does not look right
Some providers want the whole name instead of just _dmarc.
Look at the records already listed. If they show full names like mail.yourdomain.com,
type _dmarc.yourdomain.com. If they show short names like mail, type
_dmarc. This is the most common mistake, and re-running the check tells you within
a minute whether it took.
If the check said your SPF is missing
SPF is the list of servers allowed to send as you. We cannot write it for you, because only you know every service that sends your mail — but the check already told you where to start.
include: value to use. It is one line, and it is the same for all their customers.include:.~all:@ — not _dmarc.Two limits that catch people out
Ten lookups, hard maximum. Every include:
costs one. Go past ten and receiving servers may stop reading your record altogether — which
can make your real email start failing. The check counts these for you.
End with ~all, not -all, until you have read a few
weeks of reports. -all tells the world to refuse anything not on your list, and if
you have missed one service, its mail silently stops arriving.
If the check found no DKIM
DKIM is a signature proving a message really came from you. Unlike the other two, you do not write this one — your mail provider generates it.
v=DKIM1;.something._domainkey; copy their spelling character for character.Then, about two weeks later
p=quarantine to p=reject. Now a forgery is refused outright instead of going to spam.~all to -all. Never before.What we will not hand you
We do not generate a strict SPF record for you. If a sender we cannot see from outside — a billing tool, a form notifier, a newsletter — is missing from the list, a strict record would stop those emails arriving. Tighten SPF after the reports confirm what really sends as you, not before.
What happens next
“Why am I suddenly getting hundreds of these emails?”
Because you asked for them. The rua= part of that record is a request for
reports, and every large provider takes it seriously — daily, forever, starting
about a day after you publish.
This is not a fault. It is the point.
Those reports are the only way to find out who is really sending email as you — your invoicing tool, your booking system, a marketing service someone signed up for years ago, and anyone forging you.
Until you read them, you cannot safely move from p=none to something
that actually blocks a forgery. So most people leave DMARC switched on, achieving
nothing, buried in mail they cannot open.
Three ways out
1. Send them somewhere you never look.
Point rua= at an address like dmarc@yourdomain.com and filter
it into its own folder. Free, and the reports pile up unread.
2. Remove rua= entirely. The
mail stops. So does any chance of knowing whether it is safe to tighten. We do not
recommend it.
3. Have someone read them. That is the only route that ends with a domain actually protected. If you would rather not do it yourself, ask us in writing.
How it goes from here
Four steps, and only one of them is ours.
Read
You type a domain. We read the four records and answer in one sentence. Seconds, free, no account.
Publish
You add the record at your own DNS host. Nothing about delivery changes; reports begin arriving.
Read the reports
Every provider sends daily XML. We turn a month of it into one line: which of your real senders is failing.
Tighten
When nothing legitimate is failing, you move to reject. Now a forgery is refused instead of delivered.
Questions
Before you ask.
Will this change anything about my email?
No. We read public DNS records, the same ones any mail server reads. Nothing is sent, nothing is altered, and we never ask for access to your mailbox, your domain or your hosting.
Does it work if I am not on a big provider?
Yes. This is DNS, not a mail provider. Whether your mail runs on a large platform, a small host or your own server, the four records read the same way and the fix is the same.
What if I have no DMARC record at all?
That is the most common result, and it means nothing is enforced — a forged email from your address is delivered normally. The fix is one TXT record, and the first setting only turns on reporting. It changes no delivery, so it is safe to add straight away.
Why do you not give me a strict SPF record too?
Because we cannot see every service that sends on your behalf. A billing tool, a booking system or a form notifier may be sending as you from a server we have no way to detect from outside. A strict record would stop those messages arriving, silently. We tighten SPF after the reports have shown what really sends as you.
The reports are arriving and I cannot read them.
Nobody can — they are XML inside a compressed attachment, produced for machines, not people. You have three options: point them at a mailbox you never open, remove the rua= tag and lose the evidence, or have someone read them for you. Only the last one ends with your domain protected.
Can protection disappear after I fix it?
Yes, and it usually does so quietly. A record gets re-pointed during a website move, a mail provider changes, someone tidies DNS. Nothing announces it and nothing breaks visibly, so it can sit unprotected for months. The watch re-reads every month and tells you the day it changes.
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