DKIM checker
Probes the selectors common providers use, or checks the one you give it, and reads the size of every key it finds.
Leave the selector empty to probe the names common providers use. Your exact selector is the s= value in the DKIM-Signature header of an email from this domain.
Public data, possible errors. Every result here is built only from publicly available information: DNS records, and what a server shows to anyone who connects. It can be incomplete or wrong. DNS caching, a record changed minutes ago, split-horizon DNS, or a provider that signs and routes mail on your behalf can all make the public view differ from your real configuration. Treat a result as a starting point, not a verdict, and always have an administrator with the appropriate privileged access confirm it on the systems themselves before changing anything.
What DKIM does
DKIM signs every outgoing message with a private key; the matching public key is published in DNS at selector._domainkey.your-domain. A receiver fetches the key, checks the signature, and knows the message wasn't altered and really came through a server holding your key.
Unlike SPF, a DKIM signature survives forwarding, which makes it the more reliable of DMARC's two signals. Keys should be 2048-bit RSA; 1024-bit keys are still accepted but below current guidance.
Nothing in DNS lists which selectors a domain uses, so a check like this one can only probe common names. If it finds nothing, that isn't proof DKIM is off: look up the s= value in a real message's headers and check that selector.
Records fixed? Now test the people.
SPF, DKIM and DMARC stop someone forging your domain. They don't stop a lookalike domain, or a colleague typing their password into one. Phishtime runs authorised phishing simulations against your own team, free for up to 25 employees.