DKIM checker
DKIM Checker
Look up the public key for one exact DKIM selector and review its record structure, key type, and verifiable strength.
Free DNS lookup
Check a DKIM selector
Enter the signing domain and its exact selector. We will query the public key at selector._domainkey.domain.
How do I find my selector?
Your email provider or sending service usually shows it in DKIM setup instructions.
For a message you are authorized to inspect, open its headers and find DKIM-Signature. Use the value after s= as the selector and d= as the signing domain. Do not paste the message or header here.
What DKIM is
DomainKeys Identified Mail lets a receiving system retrieve a public key and use it to verify a signature added by a sending system.
What this checker tests
It requests TXT data at <selector>._domainkey.<domain>, follows a short provider CNAME chain when needed, parses the key record, and validates RSA or Ed25519 public-key structure.
Why a selector is required
A domain can rotate or delegate many DKIM keys. DNS does not provide a reliable way to enumerate every selector, so MailDNSLab checks only the explicit selector you provide.
Understand DKIM key fields
- v=DKIM1
- Identifies the DKIM key-record version. It is optional in a key record, but when present it must be first.
- p=
- Contains the base64 public key. An intentionally empty value means the selector is revoked or inactive.
- k=
- Identifies the key type. RSA is the default; this checker also validates Ed25519 keys.
- h=
- Limits allowed hash algorithms. Modern DKIM requires SHA-256; SHA-1 must not be used.
- s=
- Limits service use. The record must permit email or all services for DKIM email verification.
- t= and n=
- Flags can mark testing or same-domain identity restrictions. Notes are optional text from the publisher.
What a DKIM DNS result does not prove
- That any real message contains a DKIM signature
- That a message’s signature verifies successfully
- That the signing d= domain aligns with the visible From domain
- That DMARC passes for a message
- That email will be accepted or delivered
- That the domain is secure or cannot be spoofed
Troubleshoot the selector
- No record
- Confirm the s= selector and d= signing domain from current mail. A provider may use a different selector for each key rotation.
- Malformed record
- Review duplicate tags, tag syntax, TXT chunking, and the base64 public key with the DNS or email provider.
- Revoked key
- An empty p= explicitly disables the selector. Confirm that current mail has moved to a new selector before removing old DNS.
- Weak RSA key
- A 1024-bit key meets the minimum but is below the 2048-bit recommendation. Keys below 1024 bits are unacceptable.
- Provider delegation problem
- Review the CNAME target for loops, conflicts, missing target data, or an unusually deep chain.
Common questions
How do I find my selector?
Check your email provider’s DKIM setup screen. For a message you are authorized to inspect, the DKIM-Signature header contains the selector in s= and the signing domain in d=. Do not paste the message into this checker.
Can MailDNSLab discover every selector automatically?
No. Selectors are chosen by the signer and DNS cannot reliably enumerate arbitrary names. This checker does not guess, scan, or brute-force selectors.
What does p= mean?
It carries the public verification key. The public key is expected to be visible in DNS and is not a private signing key.
What does k= mean?
It identifies the public-key type. RSA is the default if the tag is omitted; Ed25519 is the other type validated here.
What does a revoked key mean?
An empty p= tells verifiers that the selector’s key is revoked or inactive. It is reported separately from malformed data.
What key size is considered weak?
RSA keys below 1024 bits are unacceptable for modern DKIM. A 1024-bit key is legacy-level and shown as weak; at least 2048 bits is recommended. Ed25519 keys use a fixed 256-bit format and are not compared to RSA bit counts.
Does a valid record mean my email passes DKIM?
No. A receiver must verify a specific message’s signature and signed content. This DNS-only checker has no message evidence.
Does this prove DMARC passes?
No. DMARC evaluates a message and requires an authenticated SPF or DKIM identifier to align with the visible From domain. A selector lookup alone cannot establish that alignment.
Why might the record be missing?
The selector or signing domain may be wrong, the key may have rotated, DNS may not have propagated, or the provider delegation may be incomplete.
How is my data handled?
The domain and selector are sent to the MailDNSLab backend for a fixed Google Public DNS lookup. Usage analytics are designed to contain only tool, outcome, normalized error category, and count—not the domain, selector, DNS name, raw record, or public key.
What does MailDNSLab not check?
It does not accept messages, headers, private keys, resolver choices, arbitrary hostnames, or URLs. It does not sign mail, rotate keys, test SMTP, score deliverability, or monitor results.
Related Email DNS checks
These tools answer different questions. Use either one when it fits your investigation; neither is a substitute for the current check.