Find your DKIM key without knowing the selector.

A DKIM key lives under a name that only your email provider chose.

DKIM proves two things about a message: that your domain signed it, and that nobody changed it on the way. The sending server signs each message with a private key. The matching public key sits in your DNS at selector._domainkey.yourdomain.com, and the receiving server looks it up to check the signature.

The catch is the selector. Nothing in DNS says which one a domain uses, so a checker has to guess, and most checkers make you type it. Ours tries the 51 names providers use by default, the same list the Emailchaser app uses when it checks a sending domain's DNS, and reports every key it finds. The old check on this site tried 8.

If your provider picked a name nobody could guess (some self-hosted servers use a random string), type it next to the domain. You will find it in the s= value of the DKIM-Signature header of any email you sent: open the message, show the original or the headers, and look for s=.

These are the 51 selectors we try, and who uses each one by default.

The same list as the selector probe in the Emailchaser app's DNS checks, in the same order. A provider's own default is tried first when its MX records point at it.

Gmail and Yahoo accept 1024-bit keys, and Google recommends 2048.

Google's sender guidelines say that sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer, and recommend 2048 bits. Yahoo asks for a minimum of 1024 bits. Our check reads the length from the key itself: 2048 bits or more is a pass, 1024 is a warning that still works, and anything shorter fails, because Gmail ignores it.

Google's email sender guidelines and Yahoo Sender Hub best practices, read 6 October 2026.

Google Workspace and Microsoft 365 only sign with your domain after you switch DKIM on.

Both providers sign outgoing mail with a key of their own until you set up yours, so the mail is signed, but not as your domain, and it does not count for DMARC. This is the most common DKIM problem on new cold email domains.

Google Workspace

1. In the Google Admin console, open Apps, Google Workspace, Gmail, Authenticate email.
2. Pick the domain and generate a new record with a 2048-bit key. The selector is google unless you change it.
3. Publish the TXT record it shows at google._domainkey in your DNS.
4. Wait for DNS, then press Start authentication. Run the check above to see the key.

Microsoft 365

1. In Microsoft Defender, open Email and collaboration, Policies and rules, Threat policies, Email authentication settings, DKIM.
2. Pick the domain. It shows two CNAME records, for selector1._domainkey and selector2._domainkey.
3. Publish both CNAME records, then switch signing on for the domain.
4. Run the check above: we follow the CNAME and read the key behind it.

A DKIM check fails for one of three reasons, and only one is a missing key.

1. The key is not where the signature says. The receiver looks up the selector named in the message's s= tag. If DNS has no key there, or a different key, the signature cannot be checked. This is the case the report above can see.
2. The message changed on the way. A mailing list that adds a footer, or a gateway that rewrites links, changes the signed body, and the signature no longer matches. DNS looks perfect; the failure only shows in the headers of the message that arrived, which the email header analyzer reads.
3. The wrong domain signed it. The signature verifies, but its d= domain is the sending service's, not yours. DKIM passes and DMARC still fails, because DMARC needs the signing domain to match your From address.

A DKIM record is a short list of tags, and only p= has to be there.

The tags are defined in RFC 6376, and ed25519 keys in RFC 8463.

Rotate a DKIM key by publishing the new one before you remove the old one.

A key can stay in use for years, but changing it now and then limits the damage if the private key ever leaks. The safe way is to publish the new key under a new selector, switch signing to it, and leave the old key in DNS for a few days so mail already on its way still verifies. Then remove the old record, or empty its p= value to revoke it.

If you need a key pair for your own server, the DKIM record generator makes one in your browser. DKIM works together with SPF and DMARC: check the others on the SPF checker and the DMARC checker, or all five at once on the domain health check.

Common questions about DKIM

More free tools for your sending setup