Look up a DKIM key by selector and see its type, real key length and any problems
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device. Updated on 18 Oct 2026.A DKIM checker fetches the public key a domain publishes at selector._domainkey.domain and reads it. RFC 8301 requires RSA keys of at least 1024 bits and recommends 2048; an empty p= means the key was revoked. The selector comes from the s= tag of a signed message.
Type the domain in Domain and the selector in Selector (s= in the signature).
Press Check DKIM to fetch the key at selector._domainkey.domain.
Read Key type and Key length, worked out from the key itself, with any problems listed above them.
Press Copy beside the key record to keep it.
Type a domain and a selector and the page asks a public DNS-over-HTTPS resolver for the TXT record at the selector, then ._domainkey., then the domain. The record's tags are read as RFC 6376 section 3.6.1 defines them: the version, the key type, the allowed hash algorithms, the service types, the flags, and the key itself.
The key length is worked out from the key, not guessed from how long the text is. The base64 in p= is decoded and the DER structure inside it is read down to the RSA modulus, whose exact bit length is the key size. An ed25519 key, defined in RFC 8463, is always 256 bits. RFC 8301 section 3.2 says receivers must reject RSA keys under 1024 bits and senders should use 2048, and the verdict says which side of those lines a key falls.
Other problems are listed in plain words: an empty p=, which means the key has been revoked; t=y, which marks the domain as still testing, so receivers treat its signed mail as unsigned; an h= that allows only sha1, which RFC 8301 retired; and records that are not DKIM at all. A selector that points elsewhere with a CNAME, as many mail services arrange, is followed and the target is shown.
Finding the selector is the hard part. It is the s= value in the DKIM-Signature header of a message the domain sent, and that is the only certain way to know it. The "Try common selectors" button asks for nine names that large providers and hosting panels use. A hit proves a key exists; a miss proves nothing, because selectors can be any name at all.
What it does not do: it does not verify a signature on a message. That needs the message.
The domain and selector you type are sent to the resolver you pick, because a lookup needs them. Nothing else leaves your device.
Open a message the domain sent, view the original or raw source, and find the DKIM-Signature header. Its s= tag is the selector and its d= tag is the domain. Common selectors can be guessed, and the button here tries nine, but only the header tells you for certain.
RFC 8301 requires RSA keys of at least 1024 bits and recommends 2048. Receivers must reject keys under 1024 bits, so signatures made with them fail. Keys over 4096 bits may not be verified by every receiver. An ed25519 key is 256 bits and is usually published alongside an RSA key.
An empty p= tag means the key behind that selector has been revoked on purpose. Mail signed with it now fails DKIM. Providers publish a revoked record when they rotate to a new selector, so an old selector showing p= empty is normal if current mail uses a newer one.
Usually the selector is wrong: each sending service uses its own selector, and the name is free text. The key may also not be published yet, or the service may expect a CNAME record pointing at its own key. Check the s= value in a real message header first.
The domain and selector go to the public DNS resolver you pick, Cloudflare or Google, because looking up a record needs the name. The resolver sees the names asked and your IP address. Nothing else leaves your device, and nothing about the check is stored on this site.
Still stuck? Ask about DKIM Checker and anybody who knows can answer. No account needed.
Also works as: DKIM Lookup.
Same job, other tools: SPF Record Generator – Write an SPF record for your mail providers and see how many lookups it uses · DMARC Record Generator – Build a DMARC record step by step, from p=none reporting to p=reject · Find the Sender IP of an Email – Paste the headers of an email to find the IP address of the server that sent it · JSON Validator – Check JSON and see exactly where it breaks.