← Free tools

DKIM record checker

Enter a domain. If you know the selector, give it. If you do not, leave it blank and this will try the default selectors of the providers most people send through.

DKIM selectors are not discoverable. Nothing in DNS lists them, which is why most DKIM checkers refuse to do anything until you supply one, and why most people give up at that step.

Once a key is found you get the thing that actually matters: its length, and whether it has quietly been revoked.

Optional. Leave it blank to try 18 common provider selectors.

Free, no account, nothing stored. It is a DNS lookup, so it costs us nothing to run.

What DKIM proves

Your mail server signs each outgoing message with a private key. The matching public key sits in DNS. A receiver fetches it, checks the signature, and now knows two things: the message was authorised by your domain, and nothing in the signed parts changed on the way.

That second half is what SPF cannot do. It is also why DKIM survives forwarding while SPF usually does not, and why a domain with solid DKIM is far more resilient than one leaning on SPF alone.

The selector problem

A DKIM key lives at selector._domainkey.yourdomain.com. The selector is chosen by whoever set up the signing, and there is no record anywhere that enumerates the ones in use. You cannot list them and you cannot brute force them at any sensible scale.

There are two reliable ways to find yours. Look at a message you have already sent, open the raw headers, and read the s= value in the DKIM-Signature line. Or check your sending provider documentation, since most use a fixed default: Google Workspace signs with google, Microsoft 365 with selector1 and selector2, Mailchimp with k1, Postmark with pm.

This checker tries eighteen of those defaults in parallel, which covers most senders. A blank result does not mean you have no DKIM, it means you are on a custom selector and the header is the only way to find it.

What can be wrong with a key that exists

An empty p= tag is a revoked key. The record is still there, and it is telling receivers to treat every signature from that selector as invalid. This happens when a provider is disconnected without the DNS being cleaned up, and it is worse than a missing record because it looks fine at a glance.

t=y is testing mode. It asks receivers to ignore failures, which is correct while you are setting up and a quiet hole in your authentication once you are live.

Key length is the last one. 1024-bit RSA still verifies everywhere and 2048 is the current recommendation. Below 1024 a receiver is entitled to ignore the signature entirely.

Two providers, two keys

Unlike SPF, DKIM has no combining problem. Each sending service gets its own selector and its own record, and they do not interfere. If you send through Google Workspace and a marketing platform, you should expect to find two keys, and this checker will list the extra selectors it saw.

Then confirm the other two records with the SPF checker and the DMARC checker. DMARC needs SPF or DKIM to be aligned before it can pass anything at all.

Common questions

How do I find my DKIM selector?

Send yourself a message, open the original or raw source, and find the DKIM-Signature header. The s= value is the selector. In Gmail this is Show original; in Outlook it is View message source.

Can a domain have more than one DKIM key?

Yes, and most sending domains do. Every service that signs on your behalf publishes its own selector, and they are independent. This is the opposite of SPF, where a second record breaks the first.

Is 1024-bit still acceptable?

It verifies everywhere today, so nothing breaks. 2048 is the recommendation and worth taking the next time you rotate. Some DNS providers historically struggled with the longer TXT value, which is the reason 1024 lingered as long as it did.

My key is there but mail still fails DKIM. Why?

Most often alignment rather than the key. The signing domain in the d= tag has to match your From domain for DMARC to accept it, and a provider signing with their own domain will pass DKIM while failing DMARC alignment. The other common cause is a mailing list or forwarder modifying the message after signing.

Should I rotate DKIM keys?

Periodically, yes, and most managed providers do it for you without asking. If you manage the key yourself, rotating annually is a reasonable habit. Publish the new selector before you switch signing to it so nothing is unsigned in between.

Does this store the domains I check?

No. The lookup runs, the answer comes back, nothing is written down and there is no account to create.

Authentication is the easy half

Wisemation finds the people worth writing to, researches each one, writes the email and the follow-ups, and sends them from your own inbox. Ten leads free, no card.

Try it free →