Check a DKIM Record — Look Up the Selector, Judge the Key

Why DKIM works differently from SPF and DMARC

SPF always lives in the domain's TXT record, DMARC always under _dmarc. Both can be looked up knowing only the domain name. DKIM is different: the key sits at <selector>._domainkey.<domain>, and the selector is a freely chosen name.

Selectors cannot be enumerated from DNS. There is no query that returns all _domainkey entries of a domain — DNS only answers questions about a specific name. Without knowing the selector you have exactly two options: read it from the s= tag of a real signature, or try the names that known providers assign permanently.

What this tool checks

• A targeted lookup when you supply a selector.
• 26 fixed selector names when you do not — google (Google Workspace), selector1/selector2 (Microsoft 365), k1 to k3 (Mailchimp), s1/s2 (SendGrid), fm1 to fm3 (Fastmail), protonmail, zoho and the usual self-chosen names.
• Exact key length — the key is actually parsed rather than estimated from the length of the base64 block. An estimate is wrong at the edges: 3072 bit falls into the same length range as 4096.
• Assessment against RFC 8301 — below 1024 bit not permitted, below 2048 no longer recommended, sha1 rejected.
• Test mode and revocation — t=y marks the record as a test and lets receivers ignore failures; an empty p= explicitly withdraws the key.
• Wildcard detection — if the domain answers for any made-up selector, there is an entry at *._domainkey. Every guessed name then "exists" and probing says nothing. The tool checks this first and tells you.

No hit does not mean "no DKIM"

This is the tool's most important limitation. If none of the 26 names answers, the domain may still sign perfectly well — just under a selector nobody can guess. Amazon SES, for instance, issues a random token per domain; names like that are deliberately absent from the list, because guessing them cannot work.

Conversely, a key that is found only proves a key has been published. Whether it is actually used for signing, whether the signature verifies, and whether it aligns with the domain in the From header is not in DNS.

What this check cannot see

Verification itself needs the message. The body hash is computed over the message body, and which header fields the signature covers is stated in the signature's h= tag — not in the DNS record. The same goes for DMARC alignment. For all of that, send any email to hello@analyzemy.email; the reply contains the full report including DKIM verification.