Free DKIM Checker
Enter a domain to discover likely DKIM selectors, inspect published records and identify DNS or key problems. No selector or account required.
Most checkers demand a selector you do not have. This one reads your MX and SPF records to work out which platforms you send through, checks the selectors those platforms use, follows CNAME delegation, and reports only what is genuinely published in your DNS.
Your DKIM records
How it works
- 1
Enter your domain
Type the domain your mail is sent from. Most people don’t know their DKIM selector — that’s the normal starting point, not a gap in your setup.
- 2
We read your DNS
Your MX and SPF records tell us which platforms you send through. We check the selectors those platforms use first, then work outwards, following CNAME delegation to the published key.
- 3
Read the findings
Every record shows its key type and real size, whether it is healthy, needs attention, revoked or malformed, and the exact DNS evidence behind that verdict.
What is a DKIM record?
A DKIM record is a DNS TXT record holding the public key that lets receivers verify the cryptographic signature on your email.
DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key held by your sending platform. The matching public key is published in DNS at selector._domainkey.yourdomain.com, where the selector is a label naming which key to use — the same value that appears in the s= tag of every signed message. One domain can publish many selectors, which is how a business sending through several platforms keeps a separate key for each. DKIM works alongside SPF and is one of the two ways to satisfy DMARC. Validated against the DKIM specification (RFC 6376).
What this checker verifies
- Selector discoveryReads your MX and SPF records to work out which platforms you send through, then checks the selectors those platforms use.
- CNAME delegationMost providers delegate DKIM by CNAME. We follow the chain and show you exactly where it lands.
- Real key strengthReads the actual public key and reports its true size. 1024-bit keys are called out; Ed25519 is correctly treated as strong, not weak.
- Revoked keysAn empty p= value means the key has been withdrawn. We say “revoked” plainly rather than calling the record valid.
- Record syntaxTag-by-tag parsing against RFC 6376, including multi-string records that many checkers join incorrectly and silently corrupt.
- Wildcard DNSSome zones answer every lookup. We detect that and filter the echoes out instead of inventing selectors that do not exist.
Understanding your results
There is no single pass or fail, because a domain can legitimately have healthy keys and retired ones side by side. Each record gets its own verdict.
Healthy
A well-formed, usable key: RSA 2048-bit or larger, or Ed25519.
Needs attention
Works today but sits below current best practice — an RSA 1024-bit key, or test mode still switched on.
Revoked
The record exists but the key has been deliberately withdrawn. Often the normal tail of a key rotation, not a fault.
Malformed
A record is published but cannot be parsed or used — a broken key, a missing required tag, or duplicate records at one selector.
Lookup incomplete
DNS did not give a conclusive answer. This is a lookup failure, not a finding about your domain — we never dress it up as one.
Information
True facts that are not problems, such as strict subdomain mode (t=s), which several major providers set by default.
How to find your DKIM selector
DNS gives no way to list selectors, so any tool that finds them is making educated guesses. These three methods give you the exact answer.
Read it from an email header
Open a message you have sent, view its full source, and find the
DKIM-Signatureheader. Thes=value is your selector andd=is the signing domain. This always works, including for providers whose selectors cannot be guessed.Check your sending platform’s settings
Look for domain authentication, sender authentication or email DNS settings in the platform you send from. The records it asks you to publish contain the selector.
Query DNS directly
If you already know the selector, you can confirm it yourself:
dig TXT selector1._domainkey.example.com
Some selectors genuinely cannot be discovered
Amazon SES, Postmark, Shopify, Wix, Squarespace, Intercom, Freshdesk, beehiiv, Ghost, Braze and others generate a different selector for every account. No tool can find these by guessing — read yours from an email header or your platform’s settings. We would rather tell you that than invent an answer.
What a DNS check can and cannot tell you
This check confirms
- A DKIM key is published at a given selector
- The record parses correctly and the key is well-formed
- The key type and its real size
- Whether the key has been revoked or the record is malformed
It cannot confirm
- That your mail is actually being signed
- That a signature would verify on a real message
- That DKIM aligns with your From domain for DMARC
- That you have no DKIM — we can only report the selectors we checked
To confirm your mail is really being signed, run an actual message through the Email Header Analyzer.
DKIM Checker FAQ
Can every DKIM selector be discovered from a domain?
No. DNS provides no way to list the selectors that exist under a domain, so every discovery tool works by guessing common selector names and seeing which ones answer. That finds most mainstream setups, but providers such as Amazon SES, Postmark and Shopify generate a unique selector per account, and those can never be guessed. A result of nothing found means nothing was found among the names we tried — it does not mean the domain has no DKIM.
Why did the checker find no records?
Usually one of three reasons: your provider uses an account-specific selector we cannot guess, DKIM has genuinely not been set up, or the DNS lookup did not complete. We show which of those applies. The reliable fix is to read the selector from an email header, which always gives the exact value.
Does a valid DKIM record mean my email passes DKIM?
Not on its own. A published record proves a key exists and is well-formed. It cannot prove your server is signing messages with the matching private key, that a signature would verify, or that DKIM aligns with your From domain for DMARC. Those need a real message, which is what the Email Header Analyzer checks.
What is a DKIM selector?
A selector is a label that lets one domain publish several DKIM keys at once. The key lives in DNS at selector._domainkey.yourdomain.com, and every signed message names its selector in the s= tag of the DKIM-Signature header. That is how a receiver knows which key to fetch.
Is a 1024-bit DKIM key still valid?
It still works. RFC 8301 requires signers to use at least 1024 bits and recommends 2048, and Yahoo enforces a 1024-bit minimum for bulk senders. So a 1024-bit key is accepted today but sits below current best practice — worth upgrading at your next key rotation rather than treating as an emergency.
Can a domain have multiple DKIM records?
Yes, and it is normal. Each sending platform publishes its own key under its own selector, so a domain sending through Google Workspace and two marketing platforms will have several. What you must not have is more than one TXT record at the same selector — the specification leaves that case undefined, and receivers handle it inconsistently.
Why does my DKIM record point to a CNAME?
Most providers delegate DKIM so they can rotate keys without asking you to change DNS. Your selector is a CNAME pointing into their zone, and the real key lives at the other end. This checker follows that chain and shows you both the delegation and the record it resolves to.
DKIM passes but you’re still landing in spam?
That is reputation, not authentication. Authentication gets you considered; reputation gets you delivered.