DKIM Record Checker

What DKIM is and what gets checked

DKIM attaches a cryptographic signature to every message. The private key stays on the sending server; the public key is published in DNS. The receiver looks the public key up by selector name, verifies the signature, and learns that the message really came from your domain and was not altered in transit.

This tool checks what can be checked from the outside: whether a key is published, whether it parses, its type and length, whether it has been revoked and whether testing mode was left switched on. Verifying the signature on a specific message is not possible from here, because that needs the message body and headers.

About selectors

A DKIM record lives at selector._domainkey.example.com. The selector name is chosen by the sending service and there is no universal list. DNS offers no way to ask which selectors a domain has, so you can only test a specific name.

A negative probe therefore proves nothing. When you see "none of the common selectors found", it means exactly that: no record exists under the names we tried. Only your own selector gives a definitive answer: take it from the s= tag of the DKIM-Signature header on a sent message.

Selectors used by popular services

• Google Workspace — google
• Microsoft 365 — selector1 and selector2
• Mailchimp, Klaviyo — k1
• SendGrid, Zoho — s1 and s2
• Postmark — pm
• Campaign Monitor — cm

What a record looks like

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The v tag is optional and defaults to DKIM1. k sets the key type, rsa by default. p is the public key in base64. When copying a key out of a provider's panel, make sure it does not get broken by line wraps, which is the most common reason a record exists yet signatures fail.

How to find the selector

Selectors are not listed anywhere in DNS, so the only reliable source is a message itself. Open any mail you have received from the domain, view the source, and find the DKIM-Signature header: the s= tag is the selector and d= is the domain holding the key.

With no message at hand, the checker probes a couple of dozen names used by popular services: google, selector1 and selector2 for Microsoft, k1 for Mailchimp, plus mail, dkim, s1. The sweep finds a key most of the time, but coming up empty does not prove DKIM is missing: a selector can be any string at all.

What the result means

• Key found and valid. The record parses and the length is adequate. That means the infrastructure is ready; it does not prove mail is actually being signed, because only headers from a real message show that.
• An empty p= tag. The key was revoked deliberately. Normal for an old selector after rotation, a problem if the selector is live.
• A 1024-bit key. It works but counts as weak. Gmail has treated such signatures with suspicion since 2023; reissue at 2048.
• t=y is present. Testing mode: receivers verify the signature and ignore the outcome. If the selector has been in production for a while, drop the tag.
• The record will not parse. Nearly always the value was broken by line wraps during copy-paste, or lost characters along the way.

DKIM alone does not protect the domain

A signature proves the message was not altered in transit and was sent by someone holding the private key. It tells the receiver nothing about what to do with an unsigned message, or one signed by a different domain. That decision belongs to DMARC.

Which is why the three only work as a set: DKIM signs, SPF lists the authorised servers, DMARC sets the policy and sends the reports. DKIM configured without DMARC does not stop anyone forging mail from your domain: they simply send it with no signature at all.

One selector is rarely the whole picture

Mail almost always leaves from several places: corporate mail, a sending service, a CRM, billing, the website contact form. Each signs with its own key under its own selector. Checking one tells you nothing about the rest.

The practical way to assemble the full list is not guesswork but DMARC reports. They enumerate every source that sent as your domain, with the DKIM outcome for each. Whatever shows dkim=fail or no signature at all is precisely where the key is missing or wrong.

Checking somebody else's domain

Looking up another domain's DKIM is useful in two situations. Before cold outreach: a domain with authentication in place and a strict DMARC policy usually belongs to a company that pays attention to mail, and expects the same of senders. And when examining a suspicious message: if the DKIM-Signature names a domain unrelated to the visible sender, that is worth a closer look.