Look up DKIM keys by selector or probe common selectors; measure real key length against Gmail's 1024-bit minimum.
Built & maintained by Pappu Venkata Subbi Reddy, founder of Clacify · Updated October 2026
DKIM Checker finds a domain's DKIM public keys in DNS and tells you whether they are valid and strong enough. DKIM (DomainKeys Identified Mail, RFC 6376) is the cryptographic signature on outgoing email: the sending server signs each message with a private key, and receivers verify the signature with the public key the domain publishes at <selector>._domainkey.<domain>. A valid signature proves the message was sent with the domain's approval and was not altered on the way, and unlike SPF it survives forwarding. The difficulty is the selector: it is a name the sender chooses, and DNS has no way to list a domain's selectors. This checker handles that two ways. If you know the selector, enter it. If you do not, leave the field empty and it tries 35 selectors used by common providers. For every key it finds, it decodes the published public key to measure its actual length, rather than trusting what the record claims, and checks it against Gmail's 1024-bit minimum.
For each selector the checker queries the TXT record at <selector>._domainkey.<domain> through DNS-over-HTTPS. A record may be split into several strings, because a single DNS text string holds at most 255 characters and a 2048-bit key is longer than that; the strings are joined before parsing, as RFC 6376 specifies. The record is split into tag=value pairs: v (must be DKIM1 if present), k (key type, rsa by default, or ed25519), p (the public key in base64), t (flags) and h (allowed hash algorithms). Key length is measured from the key, not guessed from the record's size. For RSA, p= contains a DER-encoded SubjectPublicKeyInfo structure. The checker decodes the base64, walks the DER structure to the RSA modulus and counts its bits after removing the leading zero byte, which gives exactly 1024, 2048 or 4096 for standard keys. It also accepts the bare PKCS#1 form some tools produce. An Ed25519 key (RFC 8463) is always 32 bytes, a 256-bit key whose strength is comparable to roughly 3072-bit RSA. Keys are then assessed: an empty p= is a revoked key, under 1024 bits is an error (RFC 8301 requires signers to use at least 1024 bits, and Gmail requires the same), exactly 1024 is a warning to plan an upgrade, and t=y means the domain says it is still testing DKIM, which some receivers treat as unsigned. When probing, the selectors are queried in parallel, and only those that return a valid DKIM record are shown.
| Provider | Typical selector(s) | Where it is set up |
|---|---|---|
| Google Workspace | Admin console > Apps > Google Workspace > Gmail > Authenticate email | |
| Microsoft 365 | selector1, selector2 | Defender portal > Email authentication settings > DKIM (published as CNAMEs) |
| Zoho Mail | Chosen when you add the key | Zoho Mail Admin > Domains > Email configuration > DKIM |
| Mailchimp | k2, k3 | Domains > Authenticate (CNAMEs to dkim2.mcsv.net and dkim3.mcsv.net) |
| SendGrid | s1, s2 | Settings > Sender Authentication |
| Amazon SES | Three random selectors | Verified identities > Easy DKIM (CNAMEs to dkim.amazonses.com) |
Selectors vary by account. The reliable way to find yours is the s= value in the DKIM-Signature header of a message you sent.
Never overwrite the key on an active selector: messages already in transit or queued for retry were signed with the old key, and replacing it makes them fail. Rotate instead. Generate a new 2048-bit key in your email platform under a new selector, publish its TXT record, wait for DNS to propagate (check it here), switch signing to the new selector, and only then, a few days later, remove the old record or empty its p= value. Google Workspace and Microsoft 365 both support this flow, and Microsoft's two selectors exist specifically to allow it. Industry guidance from M3AAWG recommends rotating DKIM keys regularly, at least every six months, so a key that has been in place for years is worth rotating even if it is already 2048 bits.
A 2048-bit RSA public key is about 392 base64 characters, more than the 255 a single DNS text string can hold. The record must be published as two or more strings within the same TXT record, which receivers join together. Most DNS providers handle this automatically, but some control panels truncate long values silently or reject them, and pasting a key that already contains quote marks can produce a record with stray quotes inside it. Both break DKIM completely, while the record still looks present at a glance. If this checker finds your selector but reports a bad or unreadable key, a split or pasting problem is the most likely cause: delete the record and paste the key again as a single value.
A passing DKIM signature is only useful for DMARC if its d= domain matches the From domain (or shares its organizational domain under relaxed alignment). Many services sign with their own domain by default, for example a newsletter platform signing as its own sending domain, so the signature passes but does not align, and DMARC fails for your domain. The fix is the "authenticate your domain" step in the service, which publishes a key under your domain so it signs as you. Gmail requires this alignment from senders of more than 5,000 messages a day, and Outlook.com has required SPF, DKIM and DMARC from the same senders since May 2025, rejecting non-compliant mail with error 550 5.7.515.
Open an email sent from your domain, view the original headers and find the DKIM-Signature header: the s= value is the selector and d= is the signing domain. Common examples are "google" for Google Workspace and "selector1"/"selector2" for Microsoft 365. Paste the headers into the Email Header Analyzer to pick them out automatically.
It meets Gmail's minimum: Google requires DKIM keys of at least 1024 bits for mail to personal Gmail accounts. 2048 bits is the current recommendation, and most providers now generate 2048-bit keys by default. To upgrade, generate a new key under a new selector, publish it, switch signing to it, then remove the old one.
DKIM keys are published under a selector name chosen by the sender, and DNS offers no way to list them. If your provider uses a selector outside the common list, enter it directly. If the selector is right and still nothing is found, DKIM signing has not been set up in your DNS yet.
An empty p= value means the key has been revoked. Any message still signed with that selector will fail DKIM, so make sure your email service has switched to a current key.