DKIM record checker: find the selector, then read the key
DKIM is the one record you cannot look up by domain alone, because the key lives at a selector only the sender knows. Give us the selector for an exact answer, or leave it blank and we probe about thirty used by Google, Microsoft, Zoho, Postmark, Mailchimp and others, then we rate key hygiene and tell you what to rotate.
- <selector>._domainkey
- v=DKIM1
- k=rsa / ed25519
- p= public key
- t=y testing
- empty p= revoked
- DMARC context
DKIM record checker
The live lookup needs JavaScript, because it queries DNS from your browser. Enable JavaScript to check a domain, or read the guide below to find your selector by hand.
Quick answer
What is a DKIM record?
DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending server add a cryptographic signature to each message, covering the headers and body. The matching public key is published in DNS as a TXT record at <selector>._domainkey.<domain>. Receivers fetch that key, verify the signature, and learn that the message really came from the signing domain and was not altered on the way.
- The selector is arbitrary. It is chosen by the sender and named in the
s=tag of theDKIM-Signatureheader, which is why no tool can enumerate DKIM keys reliably. - One domain can have many keys. Each sending service publishes its own selector. Finding one key does not mean you have found them all.
- An empty
p=tag revokes the key. That is the defined way to retire a selector without deleting the record. - DKIM survives forwarding. The signature travels with the message, which is why it is the more durable half of DMARC alignment.
- 2048-bit RSA is the current norm. 1024-bit still verifies but is being retired; Ed25519 keys are short by design, not weak.
How the rating works
A score, a band, and the exact change to make
Every lookup returns a score out of 100 and a band, based on key hygiene rather than mere presence: key strength, whether a selector has been revoked with an empty p=, whether testing mode is still set, and whether DMARC exists to give the signature any consequence. Under the band is a numbered list of findings, each with the reason it matters and the change to make.
| Rating | What it means | Typical cause |
|---|---|---|
| Excellent | Live 2048-bit or Ed25519 keys, no testing flag, no stale revocations, DMARC in place. | A domain rotating keys on a schedule. |
| Strong | Keys are sound with one loose end, often a single selector where several senders exist. | Normal for a domain on one mail platform. |
| Normal | Working but dated: 1024-bit keys, or signing with no DMARC behind it. | The most common real-world state. |
| Low | A stale selector left in DNS, or testing mode never removed. | Setup completed and never revisited. |
| Weak | A revoked key still in use, or a sub-1024-bit key. | A rotation that was started and abandoned. |
| Missing | No key at the selector you named. | Wrong selector, or DKIM was never published. |
“Aggressive by design” is not a failure
DKIM has no aggressive setting, there is no way to make a published key too strict. What it does have is the one genuinely inconclusive result on this site: with no selector supplied, a blank answer means the guessed names missed, not that no key exists. That result is reported as inconclusive rather than scored as zero, because DNS offers no way to enumerate names under a subtree.
Two ways to read the same result
For a domain owner, the findings are the rotation and hygiene backlog: revoke properly, remove t=y, move off 1024-bit, publish DMARC. For an analyst, the selectors themselves are the signal, each one names a platform that signs as the domain, so the set of keys maps the organisation's mail vendors, and a revoked-but-published selector marks an incomplete migration. The intelligence panel reports both.
The hard part
How to find a DKIM selector
Everything else about DKIM is a straightforward DNS lookup. Getting the selector is the actual work, and there are three reliable routes.
From a message you sent
Send yourself a message, then view the raw source. In the DKIM-Signature header, the s= tag is the selector and d= is the signing domain. This is definitive.
From your provider's docs
The DNS records your mail platform asked you to add contain the selector in the hostname, for example google._domainkey or selector1._domainkey.
By probing common ones
What this tool does when you leave the field blank. It finds keys for well-known platforms, but a blank result is not proof that no key exists.
| Provider | Selector | Full hostname |
|---|---|---|
| Google Workspace | google | google._domainkey.example.com |
| Microsoft 365 | selector1, selector2 | selector1._domainkey.example.com |
| Zoho Mail | zoho, zmail | zoho._domainkey.example.com |
| Proton Mail | protonmail, protonmail2 | protonmail._domainkey.example.com |
| Fastmail | fm1, fm2, fm3 | fm1._domainkey.example.com |
| SendGrid | s1, s2 | s1._domainkey.example.com |
| Mailchimp / Mandrill | k1, k2, mandrill | k1._domainkey.example.com |
| Postmark | pm, pic | pm._domainkey.example.com |
| Amazon SES | three rotating tokens | <token>._domainkey.example.com (CNAMEs) |
| HubSpot, Brevo, Klaviyo, Zendesk | hs1, sendinblue, klaviyo, zendesk1 | Provider-specific |
Recommended records
What a good DKIM record looks like, and how to rotate it
Most platforms generate these for you, and the correct move is to publish exactly what they give you. These examples are for reading what you have, and for the cases where you are generating keys yourself.
A 2048-bit RSA key
Recommendedv=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
If your DNS interface rejects the long value, split it into 255-character strings inside the one record rather than dropping to 1024-bit. Include a dated or versioned selector name so rotation is obvious later.
Delegated to a provider
Most popularselector1._domainkey.example.com CNAME selector1-example-com._domainkey.tenant.onmicrosoft.com s1._domainkey.example.com CNAME s1.domainkey.uNNNNNN.wl.sendgrid.net
A CNAME lets the provider rotate the underlying key without touching your DNS, which is strictly better than a TXT record you have to maintain. Never flatten one into a TXT copy.
Retiring a key correctly
Rotation1 Publish the new key at a new selector. s2026b._domainkey 2 Wait for the old TTL to expire. 3 Switch signing to the new selector. 4 Revoke the old key, do not delete it: v=DKIM1; k=rsa; p=
An empty p= is the defined way to revoke. Deleting the record instead leaves messages already in transit unverifiable rather than definitively unsigned, and it removes the evidence that the selector was ever yours.
What not to publish
Anti-patternv=DKIM1; k=rsa; t=y; p=MIGfMA0... testing mode left on v=DKIM1; k=rsa; h=sha1; p=MIGfMA0... deprecated hash v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb... 512 or 1024-bit in 2026
t=y tells receivers to ignore failures, which cancels the value of signing at all. It belongs in the first hour of a deployment and nowhere else.
A selector name is often enough to name the platform behind it. The fingerprint reference maps the common ones, including the default and mail selectors that indicate a self-hosted server rather than a hosted platform.
Reference
What the tags in a DKIM record mean
A DKIM DNS record is a short list of semicolon-separated tags. Two of them matter for whether mail verifies at all.
| Tag | Meaning | Watch for |
|---|---|---|
v | Version, always DKIM1 when present. | Optional, but must be first if included. |
k | Key type: rsa (default) or ed25519. | Ed25519 keys are much shorter. Short does not mean weak. |
p | The base64 public key. | An empty p= revokes the key. A truncated key fails verification silently. |
t | Flags. t=y means testing mode. | In testing mode receivers ignore failures. Remove it once live. |
h | Permitted hash algorithms, e.g. sha256. | Do not restrict to sha1; it is deprecated. |
s | Service type, usually email or *. | Rarely set. Harmless. |
n | Free-text note for administrators. | Ignored by verifiers. |
Signature-side tags you will see in headers
The DKIM-Signature header on a message carries d= (the signing domain), s= (the selector), h= (the list of signed headers) and bh= (the body hash). If d= does not match or align with the visible From domain, the signature can verify perfectly and still fail DMARC.
Playbook
Publishing and rotating DKIM keys
- Use 2048-bit RSA. Some DNS interfaces still reject the long TXT value; split it into 255-character strings within one record rather than dropping to 1024-bit.
- One selector per sending service. Separate selectors mean you can rotate or revoke one platform without touching any other.
- Rotate on a schedule. Publish the new selector, wait for DNS to propagate, switch signing to it, then revoke the old key with an empty
p=rather than deleting the record. - Remove
t=ywhen you go live. Testing mode tells receivers to ignore failures, which quietly defeats the point. - Confirm alignment. The signing
d=domain must match or be a parent of your From domain, or DMARC will not pass on DKIM. - Watch DMARC reports. Aggregate reports show DKIM pass rates per source, which is how you catch a provider signing with a stale key.
FAQ
DKIM questions, answered
How does the DKIM rating work?
Each lookup returns a score out of 100 and a band from Missing through Weak, Low, Normal and Strong to Excellent, based on key hygiene rather than mere presence: approximate key strength, whether a selector has been revoked with an empty p= tag, whether testing mode (t=y) is still set, and whether a DMARC record exists to give the signature consequence. One result is deliberately not scored as zero: when you supply no selector and nothing is found, that is reported as inconclusive, because DNS offers no way to enumerate names under a subtree and the guessed selectors may simply have missed.
What is a DKIM record?
DKIM (DomainKeys Identified Mail, RFC 6376) is a system where a sending server signs each message cryptographically and publishes the matching public key in DNS, as a TXT record at <selector>._domainkey.<domain>. A receiving server fetches that key and verifies the signature, confirming the message was sent by the signing domain and not altered in transit.
What is a DKIM selector and how do I find mine?
The selector is an arbitrary label chosen by the sender that identifies which key to use, letting one domain publish many keys. To find it, view the raw source of a message you sent and read the s= tag of the DKIM-Signature header; the d= tag beside it is the signing domain. Your mail provider's DNS setup instructions also name it, for example google for Google Workspace or selector1 for Microsoft 365.
Why can't a checker find my DKIM record automatically?
Because DNS offers no way to list the names under a subtree. Selectors are arbitrary strings, so a tool can only guess. This checker probes about thirty selectors used by common providers, which covers most hosted mail, but a blank result is not proof that no key exists: it means none of the guessed names matched.
Should DKIM keys be 1024-bit or 2048-bit?
Use 2048-bit RSA. 1024-bit keys still verify at most receivers but are being retired, and 512-bit is unsafe. If your DNS provider rejects the longer value, split the p= tag into multiple 255-character strings inside one TXT record rather than downgrading the key. Ed25519 keys look far shorter and are not weak.
What does an empty p= tag mean?
It revokes the key. Publishing p= with no value is the defined way to retire a selector: signatures made with that key stop verifying, while the record itself stays in place. If you see an empty p= on a selector you are still signing with, mail from that service is failing DKIM right now.
Do I need DKIM if I already have SPF?
Yes. SPF breaks whenever a message is forwarded, because the relaying server is not in your SPF record. A DKIM signature travels with the message and still verifies after forwarding. DMARC passes when either SPF or DKIM aligns, so publishing both is what keeps legitimate mail passing in the real world.
What is DKIM testing mode (t=y)?
t=y tells receivers the domain is still testing DKIM and that failures should not affect handling. It is useful during initial setup and harmful afterwards, because it neutralises the signature's value. Remove the tag once you have confirmed signatures verify.
Does this DKIM checker store the domains I look up?
No. The lookup runs in your browser: the selector and domain are sent to a public DNS-over-HTTPS resolver (Cloudflare, with Google as a fallback) to obtain the answer, and nothing is logged on our side. Your last five lookups are kept in your browser's local storage only, on your own device.
Key terms
Glossary
- DKIM
- DomainKeys Identified Mail (RFC 6376): a cryptographic signature over a message's headers and body, verified against a public key in DNS.
- Selector
- An arbitrary label naming which key to use, published at
<selector>._domainkey.<domain>and carried in the signature'ss=tag. _domainkey- The fixed DNS label under which all DKIM public keys for a domain are published.
p=tag- The base64-encoded public key. An empty value revokes the key.
- Testing mode (
t=y) - A flag telling receivers to ignore DKIM failures for this key. Should be removed once live.
d=domain- The signing domain named in the message's DKIM-Signature header. It must align with the From domain for DMARC to pass on DKIM.
- Body hash (
bh=) - A hash of the message body. Any modification in transit, including some mailing-list footers, breaks it.
- Key rotation
- Publishing a new selector, switching signing to it, then revoking the old key with an empty
p=.
Sources & methodology
How this tool gets its answers
Lookups run from your browser over DNS-over-HTTPS against Cloudflare's resolver at cloudflare-dns.com, falling back to Google's at dns.google. With a selector supplied, the tool queries TXT on <selector>._domainkey.<domain> only. With the field blank it queries about thirty selectors used by common providers, in batches, and stops early once it has found three keys. It also queries _dmarc.<domain> for context.
Key length is estimated from the encoded length of the p= value, not parsed out of the key structure, so treat it as an indication rather than a measurement. The tool does not verify a signature against a real message; that requires the message itself. Tag definitions cite RFC 6376, and DMARC alignment RFC 7489. We publish no invented ratings, review counts or certifications.
A key is published. Does anything act on it?
DKIM proves a message is genuine. DMARC is what tells receivers to do something when the proof is missing. Check that next.