DKIM Record Checker

Server assisted New DNS & Domains

Enter a domain and the selector from a message's DKIM-Signature header (its s= tag) to fetch the public-key record from DNS. Every tag of the record is explained, the RSA key length is read from the key itself, Ed25519 keys are recognised, and revoked keys, testing mode and short keys are flagged. A key record you paste is checked in your browser.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What is DKIM?

DKIM (RFC 6376) lets the sending server sign each message with a private key, while the matching public key is published as a TXT record under _domainkey (for selector s1 of example.com: s1._domainkey.example.com). A receiver fetches the key named by the signature's s= and d= tags and checks that the signed headers and body were not changed; RFC 8301 makes verifiers refuse RSA keys shorter than 1024 bits and recommends 2048.

How to use DKIM Record Checker

  1. Find the selector: open a message the domain sent, show its original headers and read the s= and d= tags of the DKIM-Signature header.
  2. Type the d= domain and the selector, or paste the whole key name into the domain field.
  3. Press Check DKIM and read the result, the key type and length, and whether testing mode is on.
  4. Go through the tag table, the errors and the warnings; publish a corrected record and check again.
  5. To check a key record before publishing it, paste it into the third field; it is parsed in your browser.

DKIM Record Checker features

  • Looks up the public key at selector._domainkey of the domain through public DNS over HTTPS, following the CNAME a mail service may ask you to publish there
  • Every tag of the key record explained: v, k, p, t, s, h, n and any tag verifiers do not know
  • The RSA key length read from the key itself by decoding p=, with Ed25519 keys recognised
  • Revoked keys (empty p=), testing mode (t=y), keys shorter than 1024 or 2048 bits and keys published in the wrong form flagged
  • Two key records at one selector, or TXT records there that are not keys, reported
  • A key record pasted into the third field is checked in your browser before you publish it
  • A full key name such as selector1._domainkey.example.com can be typed straight into the domain field

Inputs and outputs

Inputs

  • Domain name — the d= domain of the signature; a full key name (selector._domainkey.domain) is split into selector and domain automatically.
  • Selector — the s= tag of the DKIM-Signature header; required for a live check, because DNS cannot list selectors.
  • Pasted key record (optional) — the TXT value, plain or in the quoted pieces a zone file or DNS panel shows. When it is filled in, nothing is looked up.

Outputs

  • Summary — the result, the key type, the key length in bits and whether testing mode is on.
  • Record — the name that was queried and the record found there.
  • Tags of the key record — each tag with its meaning and value; the key itself is shortened to its first characters and its length.
  • Errors, Warnings and What to do next — each finding in plain language, and the steps that follow from the result.

DKIM Record Checker example

The Google Workspace key of github.com (selector google, October 2026)

Input:

github.com · selector google

Output:

Result: Key published correctly · Key type (k=): RSA · Key length (bits): 2048 · Testing (t=y): No
Queried name: google._domainkey.github.com
Tags of the key record: v — version (DKIM1) — DKIM1 · k — key type — rsa · p — public key (base64) — MIIBIjANBgkqhkiG9w0BAQEF… (392)

How to read the DKIM Record Checker results

Key published correctly: a verifier can fetch and use the key, and it is at least 2048 bits long or an Ed25519 key. Whether a particular message passes still depends on its signature.

Usable, with warnings: the key works but something weakens it — most often a 1024-bit RSA key, t=y testing mode or an obsolete tag.

Has errors: the record cannot be used — invalid base64 in p=, a key that does not match the declared type, an RSA key under 1024 bits or broken tag syntax. Signatures made with this selector fail.

Key revoked: p= is empty, which RFC 6376 defines as a revoked key. That is normal for a retired selector and a problem only if mail is still signed with it.

No DKIM key: there is no TXT record with a key at that name. Usually the selector is wrong, the record is not published yet, or the service expects a CNAME that has not been created.

When to use DKIM Record Checker

  • Confirming that the DKIM record a mail service asked you to publish is in place before you switch signing on.
  • Finding out why messages fail DKIM: a revoked key, a mistyped selector, or a key cut short when it was pasted into the DNS panel.
  • Planning a key rotation: checking the old and the new selector, and that the new key is 2048 bits long.
  • Reviewing a key record from a provider's setup page before adding it to your zone.

Troubleshooting

  • "No DKIM key" for a selector you just added: many DNS panels append the domain to the name you type, so a record entered as selector._domainkey.example.com ends up at selector._domainkey.example.com.example.com. Enter only selector._domainkey in such panels.
  • "p= is not valid base64" or a key of the wrong length: the key was cut or broken when it was pasted. A long key must be split into quoted strings of at most 255 characters each, never broken by a line break inside one string.
  • "Key revoked" for the selector your current messages use: the service rotated its key and your DNS still holds the old one, or the CNAME it asked for is missing. Compare with the service's current DKIM settings.
  • The selector is refused: enter only the selector (for example s1), not s1._domainkey, or type the whole key name into the domain field instead.
  • The request-limit message: each check is one DNS query, but it shares a per-visitor budget with the other DNS tools; wait the seconds shown and try again.

Frequently asked questions about DKIM Record Checker

How do I find the DKIM selector of a domain?

Open a message the domain sent, show its original headers and find the DKIM-Signature header: the s= tag is the selector and d= is the signing domain. The admin page of your mail service also shows the selector it publishes. DNS offers no way to list the selectors of a domain, so the checker cannot discover them for you.

What does an empty p= tag mean?

An empty p= is how a key is revoked (RFC 6376 §3.6.1). Signatures made with that selector now fail. It is normal for an old selector after a key rotation; it is a problem only if your mail is still signed with that selector.

How long should a DKIM key be?

RFC 8301 says verifiers must refuse RSA keys shorter than 1024 bits and that signers should use at least 2048 bits. Ed25519 keys (RFC 8463) are short and strong but not yet accepted by every receiver, so publish one next to an RSA key rather than instead of it.

What does t=y in a DKIM record mean?

t=y marks the key as being tested: verifiers are asked to treat a message whose signature fails as if it were unsigned. Remove the flag once signing works, otherwise the key gives you less protection than it should.

Does a valid key record mean my mail passes DKIM?

Not by itself. The checker confirms that the public key is published and readable. A message passes only when it was signed with the matching private key and the signed headers and body were not changed on the way. Read the Authentication-Results header of a received message to see the actual result.

Technical notes

A DKIM signature (RFC 6376) names the signing domain in d= and the selector in s=. A verifier fetches the TXT record at s._domainkey.d, reads the public key from p= and checks the signature over the headers listed in the signature and the hash of the body. Selectors let one domain publish several keys at once: one per mail service, or an old and a new key during a rotation.

The key record is a tag list: v=DKIM1 (optional, but first when present), k= the key type (rsa by default, ed25519 under RFC 8463), p= the base64 key, where an empty value means revoked, and the optional t=, s=, h= and n=. The checker decodes p= and reads the RSA modulus length from its ASN.1 structure; RFC 8301 makes verifiers refuse RSA keys shorter than 1024 bits and asks signers for at least 2048, and an Ed25519 key must be the raw 32 bytes.

The result: Key published correctly when the key is readable, of a recommended size and nothing needs a warning; Usable, with warnings for a 1024-bit key, testing mode or another warning; Has errors when verifiers cannot use the key; Key revoked for an empty p=; No DKIM key when no key record exists at the name.

Limitations and methodology

The checker needs the selector. DNS cannot list the selectors of a domain, and guessing common names would find only some of them.

It checks the published key, not a signature: it cannot tell whether a given message was signed correctly or changed on the way. The Authentication-Results header added by the receiving server says that.

The key is read through Cloudflare's public resolver by the Mutqan server at the Cloudflare edge; a record published moments ago may not be visible until cached answers expire.

Security and privacy

For a live check, the domain and selector go to the Mutqan server, which asks Cloudflare's public DNS over HTTPS for that one key name; nothing is stored. A pasted key record never leaves your browser. A DKIM public key is public by design — never paste the private key anywhere.

References