Is the mail that leaves your domain signed?
DKIM is a signature that proves a message came from your domain and was not altered on the way. The checker tries the selector names mail providers use, shows the key exactly as published, and says so when a miss means only that we did not find it.
defaultnothings1nothingmailfoundChecking
Reading your domain
Your result
The record is on this page. Publishing it is yours to do, or ours.
Copy the record shown above and follow the numbered steps further down. Most domains take one sitting at the DNS host.
Go to the stepsWe publish SPF, DKIM and DMARC for the domain and verify each one once it is live. Report reading, the later move to reject and support after that are separate work.
Ask us in writingYou receive the scope and the price in writing before any record is touched.
The names we try, and what we find under them.
DNS has no way to list every selector a domain uses, so the checker asks for the names providers use most and reports exactly what came back.
Common selectors
A set of names in wide use across mail providers, tried one after another.
The published key
The record under the first name that answers, shown character for character.
What a miss means
Only that the key is absent from the names we asked for. It is never reported as proof that DKIM is missing.
Which service signs
A selector that answers often tells you which provider or tool owns the key.
SPF
The list of servers allowed to send, read in the same pass.
DMARC
Whether a policy will start refusing unsigned mail once it enforces.
MX
Who runs your mail, and so which admin panel holds the DKIM switch.
The verdict
A single line saying whether your mail can be proven to be yours.
You switch DKIM on; the provider writes the record.
The provider creates the key pair and keeps the private half. Your part is to publish the public half exactly and press verify.
Open the provider admin
The admin console of your mail provider, not the mailbox itself.
Find the DKIM switch
Look under DKIM, email authentication or domain authentication, and turn it on for the domain.
Copy the selector name
The Name looks like something._domainkey. Copy it exactly as the provider spells it.
Publish the whole value
Paste the long value, usually beginning v=DKIM1;, into a TXT record without trimming it.
Press verify
Return to the provider’s page and press verify, or start authentication. Signing does not begin until you do, and this is the step most people miss.
Repeat for each sender
The invoicing tool, the newsletter and the booking system each sign with a key of their own.
Several DKIM records are normal
Each sending service publishes its own selector, so a domain with four services can carry four keys side by side.
Sign first, enforce second
Get every sender signing before DMARC moves past p=none. Anything unsigned would start failing the day enforcement begins.
The order: check the domain, switch signing on for your main mail, do the other senders, then enforce DMARC.
Rather not edit DNS yourself? We publish SPF, DKIM and DMARC for the domain and verify them, with the scope and the price in writing first. Ask us in writing.
“Not found” has four meanings.
DNS cannot list selectors, so a miss means the key is not on the names we tried. Your provider’s admin page is the authority on what is published.
DKIM is switched off
The provider has a key ready and nobody has turned it on.
An unusual selector name
The key exists under a name outside our list. The provider’s admin page shows it.
Published, never verified
The record is in DNS, but verify was never pressed, so the mail still leaves unsigned.
No DKIM at all
Nothing has been set up yet. Start at the first step above.
When we first checked our own fourteen domains, eleven had no DMARC policy. On the three that send mail, every service was signing before enforcement was turned on.
Unsigned senders fail the day DMARC enforces.
Services added over the years often send unsigned. They pass today because nothing enforces, and they stop arriving the moment the policy tightens.
Sign first
Get every service that sends as you signing before DMARC moves beyond p=none.
Then enforce
With everything signed, quarantine and reject turn away forgeries without touching your own mail.
A wax seal on every message you send.
The provider signs each outgoing message with a private key. Receivers check the seal against the public key published in your DNS.
Selector
The name the key is published under, chosen by the provider or the tool.
_domainkey
The fixed label between the selector and your domain: mail._domainkey.yourbusiness.example.
v=DKIM1 and p=
The version tag, and the public key itself, a long run of characters after p=.
It survives forwarding
SPF checks the server that delivered the message, so forwarding breaks it. The seal travels with the message; neither replaces the other, and DKIM alone does not stop a forgery.
Four rules the checker keeps.
The checker only looks. Every change is one you make, in your provider’s admin and at your own DNS host.
Always: public DNS, and nothing else
Every answer comes from records any mail server can look up. Nothing is sent to the domain and nothing about it is kept.
Always: the record as published, and a command to check it
Each line shows the raw text we read, with a dig command that returns the same answer on your own machine.
Never: your mailbox, your password or your DNS login
The check needs a domain name and nothing more. No test message is sent to or from the domain.
Never: a strict SPF record we cannot verify
Senders we cannot see from outside would be refused by it. When a record cannot be read, the result says unread, never missing.
Before you check your DKIM.
Send any other question in writing; a written answer follows within one business day.
It says not found, but we have DKIM.
Then it is published under a selector name outside the set we try. DNS cannot list selectors, so the check can only ask for the common ones. Your provider’s admin page shows the name it uses; if the key is there and verified, your mail is signed.
Is it normal to have several DKIM records?
Yes, and most businesses should. Each service that sends as you signs with its own key under its own selector, so several records sit side by side without conflict.
We published the record and nothing changed.
The usual cause is the verify button. Once the record is in DNS, return to the provider and press the verify or start authentication button; signing begins only after that. If it still fails, compare the published value with the provider’s, character for character.
Check another domain.
Probe a second domain, or check this one again after pressing verify. The selectors are tried afresh in about a second.