DKIM Checker - Look Up and Validate Any DKIM Record
Check any DKIM key in seconds: auto-detect common selectors, measure the real key length, and catch revoked or malformed records. No signup.
domain:selector or a full selector._domainkey.domain name.This DKIM checker runs a DKIM record lookup for any domain and inspects the public key it publishes: whether the record exists, whether the key is present or revoked, how long it is, and whether every tag is valid. If you don't know the selector, leave it empty and the checker finds the ones common email services use.
How to Check a DKIM Record
d= of your DKIM signature, usually your From domain, such as example.com.s= value from the DKIM-Signature header. Leave it empty and the checker tries the selectors common senders use, then lists every one it finds a record for. You can switch between them in the results.A published DKIM record looks like this (key shortened):
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAj6T5sl/RwdSqGoYW...IDAQABWhat This DKIM Checker Tests
Every DKIM record check marks each test Ok, Warning or Problem, with advice on anything that isn't Ok. Flags appears only when the record sets t=, and RSA key length runs only when an RSA key is present.
- DKIM record published. A TXT record exists at
selector._domainkey.domain. CNAME delegation, which Microsoft 365, SendGrid and Amazon SES use, is followed to the published key. A record withoutv=still counts, with DKIM1 assumed. - Public key. The
p=tag holds a key. An emptyp=is reported as a revoked key. - Record syntax. If
v=is present, it must beDKIM1and come first. The test also catches malformed or duplicate tags, uppercase tag names and illegal characters. - Key type.
rsais Ok.ed25519is valid but gets a warning, because receivers that don't support it skip those signatures. Any other value is a problem. - RSA key length. The length of the key itself, in bits. 2048 bits or more is Ok, 1024 to 2047 bits is a warning, and anything under 1024 bits is a problem.
- Flags.
t=ymeans the domain is still testing DKIM and gets a warning, because receivers may treat its signatures as unsigned. - Ignored tags. Tags that key records don't define, such as
q=,l=and the retiredg=, are listed by name. Verifiers ignore them, so they can be removed.
Long keys split across several TXT strings are joined before testing, so a 2048-bit key published in two chunks checks as one key.
Finding Your DKIM Selector
Auto-detect covers the selectors common email services use. For a custom one, read it from a message.
DKIM-Signature header. The s= value is your selector and d= is the domain to enter above. A message can carry several signatures, each with its own s=, and each one is worth checking.Example DKIM-Signature header
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google; ...Default DKIM selectors by email provider
| Provider | Default selector | How it's published |
|---|---|---|
| Google Workspace | google (you can choose a different prefix) | TXT record |
| Microsoft 365 | selector1 and selector2 | CNAME records pointing to Microsoft |
| Mailchimp | k2 and a second selector shown in your account | Two CNAME records |
| SendGrid | s1 and s2 | CNAME records pointing to SendGrid |
| Amazon SES (Easy DKIM) | Three random tokens per domain | Three CNAME records |
These are defaults. Your account can use other names, so the s= value in a real header is the one to trust.
Reading Your Result
What each DKIM check result means, and what to do next.
| Result | What it means | What to do |
|---|---|---|
| Valid, all tests Ok | The record is published, the key decodes, and its length meets current guidance. | Nothing in DNS. If mail still fails DKIM, see the common failures below. |
| Valid, with warnings | The key works, but something is weaker than it should be: a key under 2048 bits, t=y left on, an ed25519-only key, or ignored tags. | Follow the advice under each warning. For a short key, publish a 2048-bit key under a new selector, switch signing to it, then retire the old one. |
| Revoked | The domain withdrew this key with an empty p=. Every signature using this selector fails. | Expected for a retired key. If mail is still signed with this selector, move the sender to the active one. |
| Invalid | The record can't be used: the p= tag is missing, v= isn't DKIM1, the key type is unknown, or the p= value doesn't decode as a key. | Copy the record from your email provider again and republish it exactly as given. |
| No DKIM record found | Nothing is published under that selector. | Check the selector spelling, or use Auto-detect selectors to see which ones exist. |
| No common selectors found | The domain uses a custom selector, or it doesn't sign mail with DKIM. | Find the s= value in a message header and enter it as the selector. |
Common DKIM Failures and How to Fix Them
A record can pass every check here while mail still fails DKIM. These are the usual causes.
The key in DNS doesn't match the signing key.
Cause: Your email provider rotated its keys, but DNS still holds the old public key, so every signature fails verification.
Fix: Copy the current DKIM record from the provider's dashboard, republish it, and check it again here.
The signature points to an unpublished selector.
Cause: The s= value in your messages names a selector with no record, often after a DNS cleanup or a provider switch.
Fix: Run the check with that exact selector. If nothing is found, publish the record your provider gives for it.
The key was cut or mangled when pasted.
Cause: Long keys exceed the 255-character limit of a single TXT string, and some DNS panels truncate them or add stray quotes and spaces.
Fix: Split the key into several quoted strings, or use the CNAME setup your provider offers. A key that doesn't decode shows as "not a valid RSA key" here.
Testing mode is still on.
Cause: t=y tells receivers to treat the signature like unsigned mail, so it adds no protection (RFC 6376).
Fix: Remove t=y from the record once signing works.
The message changed after it was signed.
Cause: Mailing lists often add footers or edit the subject, which breaks the signature. Relaxed canonicalization (c=relaxed/relaxed) tolerates whitespace changes, not added text.
Fix: Nothing to change in DNS. Check the result on mail sent directly, not through a list.
DKIM passes but DMARC fails.
Cause: The signature uses your email provider's domain in d=, not yours, so it doesn't align with your From address.
Fix: Turn on custom domain authentication with the provider, then check alignment with the DMARC Checker.
What Is DKIM?
d= and s= from the DKIM-Signature header, fetches the public key from s._domainkey.d, and verifies the signature. A passing DKIM verification proves the domain in d= signed the message and the signed headers and body weren't changed in transit.DKIM is one of three DNS records that work together:
DKIM Record Tags Explained
p= is required.| Tag | Required | What it does | Default |
|---|---|---|---|
v | Recommended | Version. Must be DKIM1 and must come first when present. | DKIM1 |
k | Optional | Key type. rsa, or ed25519 under RFC 8463. | rsa |
p | Required | The base64 public key. Empty means the key is revoked. | none |
h | Optional | Hash algorithms the key may be used with. sha1 is no longer allowed for signing under RFC 8301. | all |
s | Optional | Service type: email or *. | * |
t | Optional | Flags. y marks testing mode. s requires the i= domain in the signature to equal d= exactly, with no subdomains. | no flags |
n | Optional | Notes for humans. Ignored by receivers. | empty |
DKIM Checker FAQs
Look up the TXT record at selector._domainkey.yourdomain.com. From a terminal, dig TXT selector._domainkey.yourdomain.com +short prints the raw record and nothing else. The checker above runs the same DKIM lookup and adds each DKIM test on top: the real key length, a reading of every tag, and auto-detect when you don't know the selector.
For common email services, yes. DNS has no way to list every selector a domain publishes, so auto-detect tries the names that major senders use. A custom selector only shows up when you enter it, and its name is the s= value in the DKIM-Signature header of an email the domain sent.
Send an email to a mailbox you control, open the original message, and find the Authentication-Results header. spf=pass and dkim=pass mean both worked for that message. Paste the header into the Email Header Analyzer for a readable verdict, then confirm the records behind it with the SPF Checker and this DKIM checker.
No. A valid record proves the public key is published and readable. Whether your mail server actually signs with the matching private key only shows up in a real message, as dkim=pass in the Authentication-Results header.
Revoke it by publishing the record with an empty p=. RFC 6376 treats that as an explicit statement that the key existed and is no longer valid, so any message still signed with it fails verification. Deleting the record also stops the key from verifying, but receivers only see a missing record.
The most common causes are in how the record was entered. The DNS host may have appended your domain a second time, creating selector._domainkey.example.com.example.com. The record may sit at a DNS provider that isn't the domain's active name server. Or the host name may be missing ._domainkey. Fix the host name or the provider, then run the check again.