DKIM checker
DKIM lets a receiving server confirm that a message was signed by your domain. This looks up the public key your sending service published, finds it by selector, and checks its type, its size and whether it is still in test mode. No selector? It tries the common ones.
Finds the signing key by selector and checks its type, size and test mode. No selector? It tries the common ones.
What this checks, and how.
- We query selector._domainkey.yourdomain.com for a TXT record. If you give no selector, we try a list of common ones.
- We parse the record and read the key: its type (RSA or ed25519), its size in bits, and the t=y test flag.
- A missing key, an empty p= tag, a weak key or test mode each show up as a finding with what to change.
What a DKIM record does.
DKIM (DomainKeys Identified Mail) lets a receiving server check that a message was signed by a domain and was not changed on the way. Your sending service signs each outgoing message with a private key it keeps secret. You publish the matching public key in your DNS. The receiver reads the signature, looks up the public key, and checks that the two fit.
The public key lives in a TXT record at a name made from a selector, the text _domainkey, and your domain: selector._domainkey.yourdomain.com. The selector exists so one domain can hold several keys at once, for example one per sending service or one per year. Your sending service chooses the selector and shows it where it asks you to publish the record.
selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Each message then carries a DKIM-Signature header that names the signing domain (d=) and the selector (s=). That is how a receiver knows which record to fetch, and it is also the easiest place for you to find a selector you have lost: open the full headers of a message you sent and read the s= tag.
How to read what the checker shows.
The checker looks up the key by selector, or tries a list of common selectors if you do not give one, and then reads the tags of the record it finds.
| Tag | Meaning | What to look for |
|---|---|---|
v=DKIM1 | Record version | Present and spelled exactly as shown |
k= | Key type: rsa or ed25519 | If missing, receivers assume rsa |
p= | The public key, in base64 | Must not be empty. An empty p= means the key has been revoked |
t=y | Test mode | Fine while you set up. Remove it once signing works, because receivers may ignore the result of a domain in test mode |
t=s | Strict: the key may be used only for the exact domain | Valid, but it stops the key being used for subdomains |
Key size
The checker reports the size of an RSA key in bits. Google's sender guidelines, read on 24 October 2026, say that sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer, and recommend 2048 bits if your provider supports it. A 1024-bit key still meets Google's line, but the checker warns on keys of 1024 bits or shorter, because a 2048-bit key is the longer-lived choice. A 2048-bit public key is too long for a single DNS string of 255 characters, so it is published as two quoted strings in one record. Most DNS hosts do this when you paste the whole value. If yours does not, the record may not be readable.
What the checker cannot tell you
It reads DNS only. It can confirm that a key exists and is well formed. It cannot confirm that your mail is signed with it. To check that, send yourself a message and read its DKIM-Signature header, or look at the authentication result your mailbox provider shows in the headers.
The usual faults, and the fix for each.
| Finding | Usual cause | Fix |
|---|---|---|
| No key found | The selector is not one of the common ones, or the record is on the wrong host | Enter your own selector. Check the host is selector._domainkey, with your domain added by your DNS host and not typed twice |
Empty p= | The key was revoked, or the value was cut when pasted | Copy the full key again from your sending service and publish it |
| Record found but not valid | A line break or stray space in the pasted key, or a missing split in a long value | Paste as one value without spaces, or let your DNS host split it into quoted pieces |
| Weak key (1024 bits or shorter) | An old key that was never rotated | Generate a new key in your sending service, ideally 2048 bits, and publish it under a new selector |
Test mode (t=y) | Left on from setup | Remove t=y once your mail shows a DKIM pass |
| CNAME instead of TXT | Some providers ask you to publish a CNAME that points at their own record | That is expected. A DNS resolver follows the CNAME for you, so if a key is found, nothing is wrong |
Rotating a key without a gap
Publish the new key under a new selector first, switch your sending service to sign with it, and leave the old record in place for a while so mail already in transit still checks out. Remove the old record only after that. This is why selectors exist, and why replacing a record in place is the riskier route.
Where DKIM fits with SPF and DMARC.
A DKIM pass helps your mail on its own, and it matters more for DMARC: DMARC asks that either SPF or DKIM passes and that the domain it passed for matches the domain in your From address. The signing domain in d= should therefore be your own domain, not only your sending service's. Most services let you set this up by publishing the record they give you under your domain. If you check a message and see the service's domain in d= rather than yours, DMARC alignment through DKIM will not pass.
Because DKIM signs the message and not the connection, it usually survives forwarding, where SPF does not. That makes it the more dependable of the two for mail that gets forwarded. Check the other halves with the SPF checker and DMARC checker, or run all four lookups at once with the deliverability checker.
Quick answers.
Where do I find my selector?
Your sending service shows it where it asks you to publish the DKIM record, as the first part of a host like selector1._domainkey. Mail headers also carry it in the s= tag of the DKIM-Signature line.
The checker says no key was found. Is DKIM missing?
Not necessarily. We can only try the selectors we know. If your service uses a custom one, enter it and run the check again.
Does this check that my mail is actually signed?
No. It reads DNS only, so it confirms the key exists and is well formed, not that your mail is signed with it.
How do I find my DKIM selector?
Your sending service shows it when it asks you to publish the record, as the first part of a host such as selector1._domainkey. If you have lost it, send yourself a message and open its full headers: the s= tag of the DKIM-Signature line is the selector.
What key size should I use for DKIM?
Google's guidelines, read on 24 October 2026, require at least 1024 bits to send to personal Gmail accounts and recommend 2048 bits where your provider supports it. A 2048-bit key is published as two quoted strings in one record because a single DNS string is limited to 255 characters.
Why does the checker say my DKIM is missing when my provider says it is set up?
The checker can only try selectors it knows. If your provider uses a custom selector, enter it in the selector box and run the check again. The record may also still be propagating, or be published at the wrong host.
Do I need a different DKIM record for each sending service?
Yes. Each service signs with its own private key, so each needs its own public key under its own selector. Several selectors can sit under one domain at the same time.
Fixed the records? Now warm the mailbox.
Free plan: one mailbox, capped sends. Every signup gets a free sandbox mailbox that's already warming.
- Free plan, no time limit
- 7-day trial on paid plans
- 30-day inbox guarantee, with conditions
- Customer data is hosted in the EU