DKIM checker

DKIM lets your mail carry a cryptographic signature that receivers verify against a public key in your DNS. The key lives in a TXT record at selector._domainkey.yourdomain.com, where the selector is a short name that lets one domain hold many keys at once: one per provider, or old and new during a rotation. The signing server holds the private key; DNS only ever holds the public half.

Unlike SPF, a DKIM signature survives forwarding: the signature travels inside the message, so it verifies wherever the message ends up, as long as nothing along the way rewrites the signed parts. That is why DKIM is usually the sturdier of the two legs DMARC can stand on.

The selector is not secret, but no tool can list a domain's selectors from DNS: you have to know the name to look it up, which is exactly where most people get stuck. Two reliable places to find yours. First, any message you have already sent: view its headers and read the s= tag inside DKIM-Signature. Second, your provider's DNS setup page, which shows the exact records it asked you to publish.

The probe on this page covers the third case, where you have neither. It queries 15 selectors providers commonly use (google, selector1 and selector2, s1 and s2, k1, and so on) and reports which ones hold a key. One honest limit: Amazon SES Easy DKIM generates randomized selectors per domain, so an SES domain with perfect DKIM shows nothing in a probe. That is a limit of guessing, not a verdict about your setup.

A DKIM record with p= and nothing after it is not broken or half-published. RFC 6376 defines it precisely: an empty p= value means the key has been revoked. Receivers treat signatures made with it as unverifiable, which is the point: it is how a domain says "this key is dead" without deleting the record. Google's retired 2016 selector at 20161025._domainkey.google.com publishes exactly this as we write this page, and it is deliberate.

So the verdict depends on which selector your mail is signing with right now. A revoked record on a retired selector is hygiene. A revoked record on the selector in your outgoing DKIM-Signature headers means every message you send fails verification until you publish the current key.

RFC 8301 sets the floor and the target: verifiers must not accept RSA keys shorter than 1024 bits, and signers should use at least 2048. In practice that makes 1024 the minimum that works and 2048 the size to be on; providers issue 2048-bit keys by default today, so a 1024-bit key usually marks a setup that predates the upgrade and is worth re-verifying next time you touch DNS. This checker reads the actual key material and reports the real size, not a guess from the record's length.

Most providers do not hand you a TXT value: they hand you CNAMEs pointing into their own DNS, so they can rotate keys without asking you to edit records. Amazon SES Easy DKIM works exactly this way. Receivers follow the chain to the TXT at the end, and so does this checker, showing you each hop. A checker that stops at "no TXT record" on a CNAME falsely fails the most common real-world DKIM setup there is.