DKIM checker
Is your email actually signed as yours?
DKIM is the signature proving a message came from you and was not altered on the way. We probe the selectors real providers use and show you what is published.
A second or so. Public DNS only — we never ask for your mailbox or your provider login.
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
You do not write this one. Your provider generates it.
Unlike the other records, DKIM involves a private key you never see. Your mail provider creates the pair, keeps the private half, and hands you the public half to publish.
Step by step: switching it on
The menu name differs between providers. The sequence does not.
something._domainkey. That first word is the selector, and it is theirs to choose, not yours.Step 5 is the one people miss
Publishing the record without pressing verify is the most common half-finished setup we see. The DNS looks perfect, our check says “found”, and not a single outgoing message is actually being signed — because the provider never started.
What happens next
“It says not found, but we definitely have DKIM.”
Quite possibly you do. This is the one check on the site that can be wrong in your favour, and it is worth understanding why before you act on it.
DNS cannot list selectors
There is no query that means “show me every DKIM key on this domain”. A selector is only findable if you already know its name — and the name is whatever your provider chose.
So we probe the names real providers actually use. If yours picked something unusual, or a service you forgot about signs with a private name, we will not see it.
A miss means “not on the names we tried”. It never means no DKIM exists, and we say so in the result rather than letting you assume the worse reading.
Why it matters
A signature nobody checked for years.
DKIM is switched on once, during setup, for the main mailbox. Then the business grows and nothing is ever revisited.
What quietly accumulates
The accounting software starts emailing invoices. Somebody connects a newsletter tool. The website gets a booking form that sends confirmations.
Every one of them sends as you, and not one of them is signed. Nothing looks wrong — until the day you start enforcing, and those are exactly the messages that stop.
Why it bites later, not now
An unsigned message is only a problem once a policy exists to act on it. Publish DMARC at reject, and every unsigned sender you forgot about fails at once.
Which is why the order is: sign everything first, then enforce. Never the reverse.
What is DKIM
A wax seal only you can make.
When your provider sends a message, it stamps it with a private key that never leaves their servers. The matching public key sits in your DNS, where anyone can read it.
A receiving server checks the two against each other. If they match, the message genuinely came from something holding your key, and nothing in it was altered on the way.
That second part matters as much as the first. SPF says this server may send for you. DKIM says this exact message is intact and yours — which survives being forwarded, where SPF does not.
Reading the record
Only the selector varies. That is precisely why the whole record cannot be discovered from outside.
What it reads
The selectors that exist, and the three records around them.
The common selectors
The names real providers use, probed in order until one answers.
The published key
Shown exactly as it appears in DNS, not summarised.
What a miss means
Stated plainly, every time, so nobody reads “not found” as “not there”.
Which service signs
The selector name usually reveals which provider is doing the signing.
SPF
Who may send as you, and whether unlisted senders are actually refused.
DMARC
The record that decides whether an unsigned message is stopped or delivered.
MX
Which servers receive your mail — and a clue to which admin panel holds your DKIM switch.
The verdict
One sentence on whether a forged message from your address reaches the inbox.
See it working
Type a domain — and watch the selectors get tried.
Because there is no way to ask DNS for a list, the check works by asking about the names that are actually in use, one after another, until something answers.
What you get back
Which selector answered, the key exactly as published, and — when nothing answers — a sentence making clear that is not proof of absence.
The sentence
“A signature is published on the google selector, so mail from that service can be proven to be yours.”
Plus the command to check any selector yourself.
A real result
Our own domain, third name lucky.
zmail selector — the third name tried. Outgoing mail from that provider can be proven to be ours and unaltered.dig zmail._domainkey.ihayz.com TXTsignedHow it goes from here
Four steps, and the order is the whole trick.
Check
You type a domain. We probe the selectors real providers use and show what is published. Seconds, free, no account.
Switch it on
In your provider’s admin, not your DNS host. They generate the key and hand you the record.
Do the others
Every service sending as you needs its own signature. This is the step that decides whether enforcing later is painless or painful.
Then enforce
Only once everything is signed does a strict DMARC policy stop forgeries instead of stopping you.
Questions
Before you ask.
It says not found, but I am certain we have DKIM.
Very possibly true. DNS has no query meaning "list every DKIM key on this domain" — a selector can only be found if you already know its name. We probe the names real providers use, so an unusual one will be missed. Your provider's admin page is the authority; we are a second opinion.
What is a selector?
A label your provider chooses for a particular key, sitting at the front of the record name — the zmail in zmail._domainkey.yourdomain.com. It lets one domain carry several signatures at once, one per service that sends mail for you.
Can I have more than one DKIM record?
Yes, and on a healthy domain you usually should. Unlike SPF, where a second record is an error, each sending service publishes its own selector. Several is normal — it means several services are properly signing.
I published the record but nothing changed.
Publishing is only half of it. You have to return to your provider and press verify, or start authenticating — until you do, they are not signing anything. DNS looks perfect and no mail carries a signature. This is the most common half-finished setup.
Is DKIM better than SPF?
Neither replaces the other. SPF authorises a server; DKIM proves a particular message is intact and yours. DKIM survives forwarding, where SPF usually breaks — which is why a message forwarded through a mailing list can pass DKIM and fail SPF.
Does having DKIM stop someone forging my address?
On its own, no. A forger simply sends unsigned mail. What stops them is a DMARC policy telling receiving servers to refuse anything that fails — DKIM is what your genuine mail needs so it survives that policy.
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