DKIM checker and key generator

The DKIM checker finds a domain’s DKIM public keys in DNS, reads each one the way a verifier would, and grades what it finds. Use it to confirm that your provider’s keys are live and strong, or to set up signing on your own server with a new key pair.

What it checks in each key record

• Tags. v=, if present, must come first and say DKIM1. A tag that appears twice makes the whole record invalid, and tag names are case-sensitive, so P= isn’t p=.
• The key. The RSA size is read from the key itself. An Ed25519 key must be the raw 32 bytes, and a key whose type doesn’t match k= is flagged.
• Flags and limits. t=y (testing) tells verifiers to treat signed mail like unsigned mail, so remove it once signing works. An h= that allows only sha1 fails, because RFC 8301 retired it, and an s= without email or * means verifiers must ignore the key for mail.
• One record per selector. With two TXT records at one selector, the result is undefined, so verifiers may pick either.

How the grade is worked out

Each key that isn’t revoked earns points: 100 for RSA of 2048 bits or more, 95 for Ed25519, 75 for RSA of 1024 to 2047 bits, and 0 for a broken key, including RSA under 1024 bits. Test mode costs 25, and an h= that still lists sha1 costs 10. The grade counts the strongest key at 70% and the weakest at 30%, so one old key under a forgotten selector pulls a domain down. A+ needs 95, A 85, B 70, C 55 and D 40. With no live key, or a wildcard record that answers every selector, there is no grade.

Other signs of trouble

• A wildcard. If a made-up selector also returns a record, every selector seems to have a key. Enter the exact selector from a DKIM-Signature header instead.
• A CNAME that leads nowhere. Mail signed with that selector fails; if nothing signs with it, the record is probably left over from a provider you stopped using. For a provider known to publish the key only while it rotates keys, the page says to keep the CNAME.
• A TXT record that isn’t a key at the selector you entered.
• Failed lookups, named by selector, because a key there may have been missed.

How the lookups run

Every lookup runs from your browser over DNS-over-HTTPS: Cloudflare first, with Google as the fallback, and an answer marked as truncated is never trusted. The domain itself is looked up first, so an unreachable resolver or a domain that doesn’t exist ends the check before the selector sweep. Then the 60 common selectors, any selector you entered and one made-up selector (the wildcard test) go out 16 at a time. One check stops after 20 seconds: a lookup still open by then counts as failed and is named in the results. After 3 seconds, the page shows how many lookups have answered.

Using the generator

Enter the domain and a selector, and pick a key type: RSA of 2048, 3072 or 4096 bits (public exponent 65537), or Ed25519. 1024-bit RSA isn’t offered, because RFC 8301 says signers should use at least 2048 bits. Your browser’s WebCrypto API makes the key pair, and the record is read back the way a verifier reads it before it is shown. You get the TXT record and its name, its zone-file form split into strings of up to 255 characters, and the signing key as PKCS #8 PEM, the format most signing software accepts, to copy or download. A 4096-bit key can take several seconds, and Ed25519 needs a recent browser. Once the record is live, Check the published record compares DNS with the generated key and flags a record that still needs a fix, such as a missing k=ed25519 or a leftover t=y. Then check your policy in the DMARC checker, or grade DKIM with the rest of your setup in the deliverability score.

Updated October 13, 2026 · Maintained by Liviu Tanase