DKIM checker

How to use it

1. Type the sending domain in Domain name.
2. If you know the selector, type it in Selector (optional); leave it empty to try the usual names. Press Check.
3. Read the table: Selector, Key type, Key size and State. Open a selector's line below it to see the full record.
4. Nothing found? Look up the selector in one of your sent emails (below) and check again with it.

Where DKIM keys live

A DKIM signature in an email's DKIM-Signature header names a domain (d=) and a selector (s=). Receivers fetch the public key from a TXT record at selector._domainkey.domain, for example google._domainkey.example.com (RFC 6376). DNS has no list of a domain's selectors, so a checker has to know or guess the name.

To find yours, open a message you sent, view its original source and look for s= in the DKIM-Signature line. Type that value in Selector (optional).

Which selectors the checker tries

With the field empty, the checker first tries the names used by the mail provider it recognises from the domain's MX records, then a few generic names, up to 10 in all. The result lists every one under Selectors tried.

Newsletter and CRM tools often use their own selector names, so "not found" doesn't prove a domain has no DKIM.

1024 or 2048 bits

RFC 8301 says signers must use RSA keys of at least 1024 bits and should use 2048, and receivers must not accept signatures made with shorter keys. The checker marks keys under 1024 bits as a problem and 1024-bit keys as a warning.

Google offers 2048 bits whenever your DNS host supports it. Microsoft's New-DkimSigningConfig command creates 1024-bit keys unless you ask for 2048, so Microsoft 365 domains often get the warning. The size is estimated from the length of the published key and rounded to the usual sizes; Ed25519 keys show as 256 bit.

A 2048-bit key is longer than the 255-octet maximum of one DNS text string (RFC 7208 explains the limit). Split it into several quoted strings inside one TXT record: RFC 6376 says they are joined with nothing in between.

Revoked keys and test mode

• Empty p=: RFC 6376 defines that as a revoked key. That's normal for an old selector after a rotation, and a problem if it's the one your mail is signed with.
• t=y: the domain is testing DKIM, and receivers must treat its mail as unsigned. Remove the flag once signatures verify.
• Two TXT records under one selector: RFC 6376 requires one per selector. Publish each key under its own name.

Why it matters

Gmail and Yahoo require DKIM, alongside SPF and DMARC, from bulk senders, and Outlook.com requires it to pass for domains sending over 5,000 messages a day. In the Whole email setup grade, no key found costs 10 points, a key problem 10 and a warning 3.

Questions

Why does it say no DKIM key was found when my mail is signed?

Your sender probably uses a selector that isn't on the list. Copy the s= value from a sent message's DKIM-Signature header into Selector (optional).

Is a 1024-bit DKIM key still accepted?

Yes. RFC 8301 sets 1024 bits as the minimum receivers must accept, but recommends 2048 for signers. Switch when your DNS host supports long TXT records.

Does every sending service need its own selector?

Usually, yes. Each service keeps its own private key, so each publishes its public key under its own selector, side by side in your DNS.

How do I rotate a DKIM key safely?

Publish the new key under a new selector, switch signing to it, keep the old key published for a while so mail already in transit still verifies, then revoke it with an empty p=.

Why is my Microsoft 365 selector a CNAME?

Microsoft hosts the keys and asks you to publish selector1._domainkey and selector2._domainkey as CNAMEs pointing to them. The resolver follows the alias and the checker reads the key at the end.