DKIM Checker

A selector cannot be discovered from DNS. TXT records are only returned for an exact name, and there is no way to list every name under _domainkey. So the reliable method is to read the selector off a message the domain has actually sent. Every signed message carries a DKIM-Signature header, and the selector is its s= tag. The d= tag in the same header is the signing domain, which is what you should enter above if it differs from the From domain.

• Gmail: open the message, click the three-dot menu, choose Show original. The summary at the top lists DKIM with the signing domain, and the raw headers below contain the DKIM-Signature line.
• Outlook (desktop): open the message in its own window, then File, Properties, and scroll the Internet headers box.
• Outlook on the web: open the message, click the three-dot menu, View, View message source.
• Apple Mail: View, Message, All Headers.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google;
        h=from:to:subject:date:message-id; bh=...; b=...
                                             │           │
                                       signing domain  selector  ->  google._domainkey.example.com

Without a sample message, the selector is usually predictable from the provider. The quick buttons above the form cover the common ones, and the table further down lists more.

Use 2048 bits. RFC 6376 originally required verifiers to support keys from 512 to 2048 bits. RFC 8301 raised the floor in 2018: verifiers must accept 1024 to 4096 bits, must not accept less than 1024, and signers should use at least 2048. Gmail enforces the 1024-bit minimum. A 1024-bit RSA modulus is considered breakable by a well-resourced attacker, and a broken DKIM key lets that attacker sign mail as your domain that passes DMARC.

The old reason for staying at 1024 was DNS. A TXT record is made of strings no longer than 255 characters, and a 2048-bit key is about 392 characters of base64, so it has to be split across two strings. Every current DNS provider handles that, either automatically or by letting you paste the two quoted strings. Our tool reads the key length from the DER-encoded modulus itself rather than estimating from the record length, so a key that has been mangled during copy and paste shows up as failing to parse.

Ed25519 keys (RFC 8463) are 256 bits and far shorter in DNS, but receiver support is still incomplete, so a domain that uses them should dual-sign with RSA as well.

Selectors exist so that two keys can be live at once. Generate a new key pair, publish the public half under a new selector (for example, move from s2024a to s2025a), and confirm it resolves. Switch the mail server or provider to sign with the new selector. Wait at least a week, because mail already sent is verified when it is received, and a message stuck in a queue over a weekend still references the old selector. Then delete the old record, or better, publish it with an empty p tag, which RFC 6376 defines as a revoked key.

Rotate every 6 to 12 months and immediately after any suspicion the private key leaked. Providers that manage the key for you, such as Google Workspace and Microsoft 365, rotate automatically. Microsoft alternates between selector1 and selector2, which is why both must be published as CNAMEs.

Most hosted providers publish the key on their own domain and ask you to add a CNAME under _domainkey pointing at it. A lookup still works, because resolvers follow the CNAME and return the TXT record at the other end. Our tool shows the final record. If it comes back empty, the CNAME is usually pointing at a name the provider has not activated yet.

Query the TXT record at selector._domainkey.domain. A 2048-bit key comes back as two quoted strings that the verifier joins together. A CNAME in the answer section before the TXT record is normal for hosted providers. The DNSX API returns the joined record and the parsed tags.

$ dig TXT google._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...IDAQAB"

$ curl -s "https://api.dnsx.dev/email/dkim/example.com?selector=google" | jq '.found, .parsed.key_type'