DKIM record checker

Look up a selector's public key and decode it — so you get the real key length, not just "a record exists". Don't know your selector? Try the common ones.

Looks up <selector>._domainkey.<domain> over DNS-over-HTTPS. The key is decoded in the page — nothing is sent to us.

You need the selector, and DNS will not tell you

A DKIM key lives at <selector>._domainkey.yourdomain.com, and there is no way to list the selectors a domain uses — DNS has no directory. You either know the name or you guess it.

The reliable way to find it is a message you actually sent: open the raw source, find the DKIM-Signature header, and read the s= tag. That is the selector, and d= next to it is the signing domain. Failing that, "try common selectors" above checks the ones we have seen in the wild — google for Workspace, selector1 and selector2 for Microsoft 365, k1/k2 for Mailchimp, s1/s2 for SendGrid, and a handful more.

Every sender that signs for you has its own selector, so a domain normally has several live at once. Finding one does not mean you have found them all — see DKIM selectors explained.

What "the record exists" misses

Three failures look identical to a checker that only confirms a record is present:

  • A revoked key. An empty p= is not a broken record — it is the defined way to revoke a key (RFC 6376 §3.6.1). The record resolves perfectly and every signature it covers fails.
  • Testing mode left on. t=y tells verifiers to treat the mail as though it were unsigned, even when the signature verifies. It is meant for the first week of a rollout. It is routinely still there years later, quietly making DKIM decorative.
  • A 1024-bit key. Common, and still shipped by default by some providers. RFC 8301 requires at least 1024 bits and says signers should use 2048. This tool decodes the key rather than trusting the record, so the length it reports is the real one.

DKIM survives what SPF does not

DKIM signs the message, so the signature travels with it. Forwarding, mailing lists and "send as" all break SPF while leaving a DKIM signature intact — which is why a domain with both usually passes DMARC on DKIM, and why DKIM is the one worth getting right first.

It only counts for DMARC when the signing domain aligns with the visible From: address, though. A vendor signing with their own d= produces a valid signature that does nothing for you. Whether that is happening is a question the daily aggregate reports answer, per sender — which is what DMARC Analyzer is for. Free and open source, and self-hosted.