DKIM checker

How DKIM lookups work

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The matching public key sits in DNS as a TXT record, and receivers fetch it to verify the signature. The catch for anyone trying to check DKIM: the record does not live at a fixed name. It lives at

{selector}._domainkey.{domain}

and the selector part is chosen by whoever set up signing. Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1, many transactional platforms use s1/s2 pairs for rotation. A healthy record looks like:

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

The p= tag carries the base64-encoded public key. That single tag is the one that matters most: present and non-empty means the key can verify signatures, empty means the key is revoked.

Two modes: exact lookup and selector probe

With a selector supplied, the checker queries that exact _domainkey name and parses what comes back: version tag, key type (rsa by default, ed25519 increasingly common), public key presence, and the t=y test-mode flag. Errors here are specific — a missing record at that name, a revoked key, a malformed version tag.

Without a selector, the checker probes a curated list of 16: default, google, selector1, selector2, k1, k2, s1, s2, dkim, mail, smtp, mandrill, mte1, mte2, everlytickey1, and zendesk1. Each hit is parsed the same way as an exact lookup. This answers “which platforms have signing keys on this domain?” in one pass — useful for auditing your own DNS after years of vendor churn, or for checking what a competitor has wired up.

Be honest with yourself about what a probe means, because we are: it proves presence, never absence. A domain signing with fm1 or a randomly generated selector shows nothing here and still has perfectly working DKIM. The definitive source is the s= tag in a real message's DKIM-Signature header.

What the checker flags

• No record at the selector — the name doesn't exist or holds no DKIM data. Check spelling first; selectors are exact.
• Empty public key — a revoked key. If mail still signs with this selector, every signature fails.
• Test mode (t=y) — verification runs, but receivers may not credit it. Remove the flag once your setup is stable.
• Wrong version tag — when v= is present it must read DKIM1, and it must come first.
• Unusual key type — anything other than rsa or ed25519 will fail verification at most receivers.

Why DKIM matters more than it used to

Since 2024, Gmail and Yahoo require bulk senders to authenticate with SPF and DKIM, and DMARC needs at least one of them to pass with alignment. DKIM is the leg that survives forwarding: an SPF pass breaks when a message is relayed through another server, while a DKIM signature travels inside the message and keeps verifying. For senders on shared ESP infrastructure, DKIM with your own domain is also what makes DMARC alignment possible at all.

A valid key is still just configuration. It says nothing about whether the platform signing your mail gets it into inboxes — that depends on the sender pools and practices of the platform itself, which is exactly what we measure with seed-list placement tests across the services we review. The test protocol is public on our methodology page.

DKIM verified? Complete the set: check your SPF record and your DMARC policy, or run the combined email authentication check to see all five mechanisms on one board.

Frequently asked questions