About the DKIM Checker
The DKIM checker looks up a domain's DKIM public key straight from DNS, given the selector and domain you provide. It queries the standard selector._domainkey.domain location, pulls the TXT record, and parses its tags, so you can read the key type, the public key material, and any flags without decoding a raw string of base64 by hand.
Use it whenever you set up a new mail service and need to confirm the DKIM selector actually published, when a signed message is failing verification and you want to see what a receiver sees, or when you're auditing a domain you've inherited and don't yet know which selectors are live. Because it queries public DNS resolvers directly rather than a cached copy, the result reflects what mail servers around the world are actually reading right now.
The lookup runs server-side, since DNS resolution isn't something a browser can do on its own, so the domain and selector you enter are sent to our server to run the query; nothing beyond that is stored or shared. What sets this checker apart from a plain TXT lookup is the parsing layer on top: it splits the record into its v, k, p, t, and other tags, flags an empty p= value as a revoked key, and flags t=y as a selector still running in test mode, two conditions that are easy to miss when reading a long base64 blob by eye.
If you don't know the selector, the DKIM-Signature header of a signed message contains it in the s= tag, alongside the signing domain in d=, or your mail provider's own setup documentation names it directly. For a broader deliverability picture that also covers MX, SPF, and DMARC in one pass, the mailcheck tool runs a DKIM probe across common selectors alongside those other checks.
How to use it
- Enter the domain that owns the DKIM key, for example example.com.
- Enter the selector for that domain; check the s= tag of a signed message's DKIM-Signature header if you don't already know it.
- Submit the form to query selector._domainkey.domain in DNS.
- Read the parsed tags table for v, k, and any other values found alongside the raw record.
- Check the warnings panel for a revoked key (empty p=) or a test-mode selector (t=y).
- If no record turns up, try another likely selector such as google, selector1, selector2, or k1 before concluding DKIM isn't configured.
- Re-run the check after fixing a DNS record; propagation across resolvers can take a few minutes depending on the TXT record's TTL.
Examples
- selector google with domain example.com queries google._domainkey.example.com, the location Google Workspace publishes its signing key at.
- selector selector1 with a Microsoft 365 domain covers one of the two rotating selectors (selector1, selector2) Outlook uses for signing.
- selector k1 with a Mailgun-connected domain is where Mailgun publishes its default signing key for that sending domain.
- A record with tags v=DKIM1, k=rsa and an empty p= value is flagged as revoked, meaning the key has been retired and signatures against it no longer verify.
- A record containing t=y is flagged as test mode, telling you the domain owner is asking receivers not to penalize DKIM failures yet.
- No record found at selector._domainkey.domain returns a clear result stating no DKIM record exists at that selector, rather than a raw DNS error, so you know to try a different selector.
How DKIM selectors work, and how to find yours
A DKIM key lives at a DNS name built from two parts: the selector and the signing domain, joined as selector._domainkey.domain. The selector exists because a domain can publish more than one key at once, for key rotation, for different sending services, or because several providers send mail on the domain's behalf. Without the right selector there is nothing to look up; DNS returns an empty answer and it looks like DKIM is missing even when a valid key is published under a different selector.
The most reliable source for a selector is a message the domain actually signed: open the raw headers and read the DKIM-Signature line, where s= is the selector and d= is the signing domain. When you can't get a sample message, the sending platform's own setup documentation lists the selector it expects you to publish, and several providers use a small, predictable set of them:
- google - Google Workspace and Gmail
- selector1, selector2 - Microsoft 365 and Outlook, rotated automatically
- k1, k2 - Mailgun
- mandrill - Mailchimp Transactional (Mandrill)
- s1, s2 - SparkPost and several legacy ESP integrations
- zoho - Zoho Mail
- protonmail - Proton Mail custom domains
- fm1, fm2, fm3 - Fastmail
- default, dkim, mail, smtp - common choices for self-hosted mail servers
DKIM record anatomy: the v, k, and p tags
A DKIM TXT record is a semicolon-separated list of tag=value pairs, similar in shape to SPF but describing a cryptographic key rather than a list of servers. The tags that matter most for troubleshooting are:
- v=DKIM1 - record version; must be exactly this literal value
- k=rsa - key algorithm; rsa is the default, ed25519 appears in newer setups
- p=<base64> - the public key itself; an empty p= means the key has been revoked
- t=y - test mode; receivers should treat failures as informational only
- h=sha256 - which hash algorithm the signature is allowed to use
- s=email - restricts the key to signing email specifically, rarely set
Common DKIM record mistakes
Most DKIM problems trace back to a handful of recurring issues, usually in how the record was published rather than in the key itself.
- Guessing the wrong selector: the lookup depends entirely on knowing the exact selector; a correct key published under a different selector than the one you queried looks identical to no key at all
- Split TXT strings: DNS limits each TXT string to 255 bytes, and a 2048-bit RSA key's base64 value is longer than that; some DNS panels require the value entered as multiple quoted strings, and a copy-paste that drops one fragment leaves a truncated, unparseable p= value
- 1024-bit vs 2048-bit keys: a 1024-bit key still fits in one TXT string, but several large receivers now flag or ignore 1024-bit DKIM keys as too weak; 2048-bit is the current baseline, at the cost of needing the split-string handling above
- Leftover selector after key rotation: rotating to a new selector without retiring the old one leaves a stale key resolvable indefinitely, so a compromised old key can still be used to forge valid signatures
- Publishing under the wrong domain: a key set on a subdomain or the bare apex when the signing software actually uses a different sending domain is never found by the receiver's lookup
DKIM's role in SPF and DMARC alignment
DKIM on its own only proves a message wasn't altered in transit and was signed by whoever holds the private key; it doesn't tell a receiver what to do when a signature is missing or broken. That policy layer is DMARC, which combines DKIM with SPF and requires at least one of them to pass and align. Alignment means the domain in DKIM's d= tag has to match, or share a parent domain with in relaxed mode, the domain in the message's From header, not just the domain in the selector you queried. A DKIM key can resolve perfectly in a lookup like this one and still fail DMARC alignment if it was signed with an unrelated d= domain, a common surprise when a marketing platform signs mail with its own domain instead of the customer's.
Frequently asked questions
What does a DKIM checker actually verify?
It queries the selector._domainkey.domain TXT record and parses it, confirming the key is published and readable and showing whether it's revoked or in test mode. It doesn't verify an actual signed message; that requires the mailcheck tool or reading the Authentication-Results header on a received email.
How do I check DKIM for a domain if I don't know the selector?
Find a message the domain has sent and read the s= value in its DKIM-Signature header, which is the selector, alongside d= for the signing domain. If no sample message is available, try the sending provider's documented default, such as google for Google Workspace or selector1 and selector2 for Microsoft 365.
Why doesn't nslookup show my DKIM record?
nslookup -type=TXT selector._domainkey.domain only returns a result if you query the exact selector the domain actually uses; the most common cause of an empty answer is the wrong selector, not a missing record. An empty response with the right selector does mean nothing is published there.
Is this DKIM record checker free to use?
Yes. Domain and selector lookups run without a login or a rate-limited paywall, the same as the site's other DNS tools.
What's the difference between a DKIM checker and a tool that tests DKIM by sending mail?
A checker like this one reads the published public key from DNS and confirms the record exists and is well-formed. Testing whether a real message actually signs and verifies correctly requires sending mail through the domain and inspecting the resulting Authentication-Results header, which is what the inbox tool does.
What does it mean if the lookup finds no DKIM record at all?
Either the selector is wrong, the domain never published a key under that name, or DKIM simply isn't set up. Try a couple of common provider selectors before concluding DKIM is absent entirely.
Can I check DKIM for a subdomain that sends its own mail?
Yes, enter the subdomain as the domain value. DKIM selectors are looked up per exact signing domain, so a subdomain with its own mail flow needs its own selector and key, separate from the parent domain's.
Does key length, 1024-bit vs 2048-bit, actually matter?
Yes. 1024-bit RSA keys are increasingly treated as weak or rejected outright by large mailbox providers, while 2048-bit is now the practical minimum. The tradeoff is that a 2048-bit key's p= value no longer fits in a single 255-byte TXT string and needs to be split correctly.
What's the difference between DKIM, SPF, and DMARC?
DKIM cryptographically signs a message so it can't be altered undetected, SPF lists which servers may send for a domain, and DMARC sets policy for what happens when either check fails and ties both together via alignment. This tool checks the DKIM side specifically.
Is the domain and selector I enter sent anywhere?
They're sent to our server to run the live DNS query, since a browser can't perform DNS resolution on its own. Nothing you enter is stored or shared beyond producing the result you see.