DKIM checker: common selectors, key length, and what we cannot see

How to read this

DKIM (RFC 6376) publishes a public key at <selector>._domainkey.<domain>. The selector is chosen by the signer — Microsoft 365 uses selector1 and selector2, Google Workspace usually uses google, Mailchimp uses k1. There is no DNS list of selectors. If we do not try the right name, we will not see the key.

That is why a miss is Unknown, not a fail. Saying “this domain has no DKIM” after checking twenty common names would be a false positive. Type the selector your admin or ESP gave you if the common list is empty.

We do fail when we find a record whose p= is empty. That is a revoked key (RFC 6376 §3.6.1). Mail still being signed with that selector will not verify. We also measure RSA modulus length. 1024-bit keys are flagged as weak and Verified — they are published, and they are too short. Prefer 2048-bit RSA or Ed25519.

Each selector we find is labeled with the provider that typically owns it, so you can see “selector1 → Microsoft 365” versus “k1 → Mailchimp.” Custom selectors show as unknown/custom. CNAMEs (Microsoft’s selector1._domainkey → selector1-example-com._domainkey.example.onmicrosoft.com) are followed by the DNS lookup.

DKIM alone does not stop spoofing. A thief can skip your key and still put your domain in From:. DMARC is what requires alignment. DKIM is how your legitimate mail proves it is yours so that a reject policy does not eat it.

We probe the same common selectors as the Client Posture scanner (google, selector1, selector2, k1, default, resend, pm, and the rest of that list) plus one selector you type. Each hit shows the provider that usually owns that name and the RSA bit length when the p= value decodes. A CNAME from selector1._domainkey to Microsoft’s onmicrosoft.com host is followed automatically. Empty results stay off the fail list on purpose.

If every common selector returns the identical empty p= value, that is almost always a wildcard on _domainkey, not thirty revoked keys. We collapse that to one Verified finding so IANA-style example zones do not look like a mass outage. Timeouts are Unknown. We never brute-force the zone; that would be a probe, and this product does not probe.

A published key with t=y is in test mode (RFC 6376 §3.6.1): receivers should treat a failed signature as if it were unsigned. We still report the key and its length, and we note the flag. Multiple valid selectors are normal — Microsoft publishes two so they can rotate. A 2048-bit RSA key with an empty h= accepts both sha1 and sha256; prefer sha256-only when the signer supports it. We do not fetch the message itself, so we cannot prove a given mailbox is signing today; we can only prove the public key is in DNS.