DKIM Record Checker

A DKIM public key lives at selector._domainkey.yourdomain.com. The selector is a label the sender picks, and DNS has no way to list every label under _domainkey. A receiver does not have this problem because the selector is written in the DKIM-Signature header of the message. A checker that only has your domain has to guess.

So this tool guesses in a bounded way. In quick mode, which is what this page runs, it tries 25 selectors: google, selector1, selector2, default, dkim, mail, email, s1, s2, k1, sendgrid, amazonses, mandrill, mailgun, postmark, resend, ses, sg, mg, pm, smtp, mta, mx, primary and main. If your provider uses something else, open the advanced options and enter the selectors yourself, separated by commas.

Finding nothing does not prove DKIM is broken. It proves none of those 25 names has a key. Amazon SES is the common case. Easy DKIM gives each identity three CNAME records with random tokens as the selector, so no guessable name will ever match. If the SPF record mentions Amazon SES and no selector turns up, the checker adds a note saying so.

For SES, copy the three tokens from the console under the identity's DKIM section, or from the DNS records the identity shows, and paste all three into the selector field. SendGrid and Mailgun also use provider-specific names, so the same approach applies.

For every selector with a key, the result shows the key type and size. RSA keys under 2048 bits produce a warning, and under 1024 bits an error, because short keys are easier to attack. Two other tags matter: t=y means the domain is in testing mode and receivers may ignore failures, and an empty p= means the key was revoked on purpose.

The checker also looks at the h= tag. A key that only allows sha1 gets flagged, since sha256 is the expected hash. A service type (s=) that excludes email gets flagged too.

Selectors exist so you can rotate. Publish the new selector, switch the sender to sign with it, wait until mail signed with the old key has been delivered, then retire the old record. Deleting the old key first turns in-flight messages into DKIM failures.

If you see both an old 1024-bit key and a new 2048-bit key in the results, that is usually a rotation caught halfway. Check that the sender is signing with the new one before you remove the old.

It checks that keys exist and look sane. It does not verify a signature on a real message, so it cannot tell you whether your sender is actually signing with the key it found. Send a test message to a mailbox you control and read the Authentication-Results header for that.