Email authentication
DKIM checker
Find a domain’s DKIM key, read its tags in plain words, and flag a weak, revoked or malformed one.
Free, no accountLive check
Result
Fill in the form and press Check DKIM record. The verdict and the detail appear here.
What this is
This DKIM checker finds the key a domain signs mail with, trying the common selectors when none is given, and reads the tags inside it - the key type, its length, and the flags that change how a receiver treats it.
DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key, and publishes the matching public key as a TXT record at "<selector>._domainkey.<domain>". The selector is just a label chosen by whoever set up sending, which is why there is no single address to check - a mailbox provider changing its signing key often changes the selector too, and the old one is left behind rather than removed.
A verifying server reads the selector out of the signature header on the message itself, fetches the matching key, and checks the signature against it. A key that is missing, malformed or revoked makes that check fail the same way a wrong one would - which is why this is worth checking on its own, before anything is sent.
How to read the result
"Selectors tried" lists every name this checked, in order, and which one (if any) had something published - useful on its own, since finding the right selector is often the actual problem.
The key record is read in plain words: its type, its length if it is RSA, and whether the flags inside it say anything that changes how a receiver treats it, like a revoked key or one still in testing mode.
Common mistakes
What goes wrong most often, and how to tell.
- Leaving an old selector’s key published after rotating to a new oneA retired selector with its old key still published is a route to spoof mail that a receiver would otherwise catch - it is still an active DKIM key as far as any verifier is concerned, whether or not anything signs with it any more.
- Assuming "no key found" means DKIM was never set upIt usually means the selector used was not on the common list this checker tries. Finding the real selector - check the mail provider's own DKIM setup page - is often the whole fix.
- Generating a key under 1024 bitsRFC 8301 §3.2 withdrew short RSA keys from DKIM entirely; a verifier that follows it ignores a signature made with one completely, which is functionally the same as not signing at all.
- Leaving "t=y" (testing mode) set after going liveThis flag tells a verifier not to treat a failed DKIM check as a hard failure, which is useful while confirming signing works and a liability once it is live - a real signing fault stops being visible as one.
Questions
What people ask about this tool.
- A label, chosen by whoever configured sending, that names which of possibly several published keys a given message was signed with. It appears in the "d=" and "s=" tags of the DKIM-Signature header on the message itself, and is not standardised across providers.
- The selector in use is probably not one of the common ones this checker tries by default. Enter the exact selector your mail provider's own setup page shows and the check runs against that name directly.
- RFC 6376 §3.6.1 defines an empty "p=" tag as a deliberate revocation - the key record is still published, on purpose, specifically so a verifier can tell the difference between "retired" and "never existed".
- Yes - RFC 8301 §3.2 removed RSA keys under 1024 bits from DKIM entirely, and most mail providers now default to 2048 bits. A correctly formed 512-bit key is still a weak one.
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.