DNS Tools
EMAIL AUTHENTICATION

DKIM Checker

Enter a domain and the selector from a DKIM-Signature header. The tool fetches the key record at SELECTOR._domainkey.DOMAIN and analyses it; it checks only the selector you provide.

Run DKIM key check

The s= value of a DKIM-Signature header.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What a DKIM check does

DKIM (RFC 6376) lets a sending system sign a message with a private key. The matching public key is published in DNS as a TXT record at a name made of a selector, the label _domainkey, and the signing domain, for example selector1._domainkey.example.com. Receivers read the d= and s= tags of the DKIM-Signature header to find that name and verify the signature.

This tool does the DNS half of that job. You provide the domain and the selector; it queries the name, follows a CNAME if the key is delegated to a mail provider, and analyses whatever key record it finds. It does not verify the signature on any message.

Why you must supply the selector

DKIM selectors cannot be enumerated. DNS has no mechanism for listing the labels under _domainkey, and a domain may use many selectors at once, one per service or per key rotation. The tool therefore queries exactly the selector you enter. 'No record found' means no key exists at that name; it says nothing about other selectors.

To find the right selector, open a message the domain sent, view the full headers and read the s= value in the DKIM-Signature header. The header analyzer can extract it for you.

How to read the result

The key summary shows the key type (RSA or Ed25519), the key size, whether the key is usable, whether test mode is on, whether the name is a CNAME, and how many key records sit at the name. A CNAME is informational: hosted mail services often delegate the selector so that they can rotate keys without your involvement.

An RSA key below 1024 bits is flagged at medium severity and one under 2048 bits as a strength improvement; 2048 bits is the usual current recommendation. A record with an empty p= is a revoked key, which is a legitimate way to retire a selector, but any system that still signs with it will fail verification.

Common DKIM problems

  • Truncated or re-wrapped key. The base64 value in p= was cut short or had characters changed when pasted. The tool reports the key as unusable.
  • Long values split incorrectly. A 2048-bit key exceeds 255 characters, so DNS hosts split it into several quoted strings inside one TXT record. Publishing several separate TXT records instead breaks the key.
  • Two key records at one selector. Receivers may pick either, so verification becomes unpredictable. Publish a new selector for a new key instead.
  • Test mode left on. t=y tells receivers not to treat failures as significant. It is meant for rollout only.
  • Wrong selector. Frequent when a provider has changed its selector naming. Check the header, not documentation memory.
  • Syntax faults. Duplicate tags, v= not first, an unknown k= value, s= excluding email, or h= that lists no sha256.

How to fix or rotate a key safely

Prerequisites: the exact record your signing service gives you, DNS write access, and the ability to send a test message. Operational risk: the moment a record is wrong or removed, every message signed with that selector fails DKIM. If your DMARC policy is quarantine or reject and SPF does not align, those messages may be filtered. Rollback: keep the previous value of the TXT record, and never delete an old selector until you have confirmed nothing signs with it.

  1. Publish the new key under a new selector name rather than overwriting the active one.
  2. Wait for the TTL of any previous negative answer to expire, then check the new selector with this tool.
  3. Switch the signing service to the new selector.
  4. Send a test message and confirm dkim=pass for the new s= value in Authentication-Results.
  5. Keep the old key published for a period long enough for in-flight and queued mail, then retire it with an empty p= or removal.

Limits of this check

The tool analyses the published key only. It does not check that a message was signed with the matching private key, that the signed headers cover From, or that the body hash matches. It cannot tell you which selectors a domain currently uses, and a pass here does not mean DKIM passes in the real world. A DNS failure is reported as unknown, never as a missing selector.

Frequently asked questions

Can the tool list all DKIM selectors for my domain?

No. Selectors cannot be enumerated from DNS. Read the s= tag from a real DKIM-Signature header or ask your mail provider.

What does it mean if the selector is a CNAME?

The key is hosted by another party and referenced by alias. That is normal for managed mail services; they can rotate the key without a change in your zone.

Is a 1024-bit key still acceptable?

It still verifies, and the tool flags it as an improvement item. 2048-bit RSA is the usual recommendation, though some DNS hosts need help publishing the longer value.

What does an empty p= mean?

The key is revoked. Signatures that use the selector are meant to fail. This is a valid way to retire a selector.

Why does the tool say no key was found when my provider says DKIM is on?

The selector name may differ, the record may be at another domain, or DNS may not have propagated. Check the s= and d= values in a real message.

Does DKIM alone protect my domain from spoofing?

No. DKIM proves a signing domain, not that it matches the visible From address. DMARC adds the alignment requirement.

Scope of this tool

  • Only the selector entered is queried.

Written by DNS Tools editorial · Last updated 2026-10-09