DKIM Selector Finder

What a DKIM selector is

DKIM signs outgoing mail with a private key and publishes the matching public key in DNS, so a receiver can check that the message was not altered in transit and was signed by someone with access to the domain’s key. The public key is a TXT record, and the selector is the label that says which one: a signature carrying s=google; d=example.com tells the receiver to fetch google._domainkey.example.com.

The selector exists because one domain sends mail from many systems, and each of them needs its own key pair. The name is chosen by whoever sets the signing up — a provider’s fixed default, a date, an account ID, or anything a human types into a form. RFC 6376 constrains it only to being a valid DNS label. That freedom is why finding one is a guessing game.

Why you cannot list selectors from DNS

DNS answers questions about names you already know. There is no query that returns “every record under _domainkey”; the closest thing, a zone transfer, is refused by every sane nameserver precisely because it would reveal the whole zone. So a DKIM checker cannot discover selectors. It can only try names, one query each, and report which ones answered.

That has a consequence every DKIM tool should state and most do not: a miss is not evidence. “No DKIM found” from a guessing tool means “none of the names I know”, and a domain signing perfectly through Amazon SES will read as unsigned on all of them. This page says which names it tried, so you can judge what a miss means.

How this finder works, and its limits

It queries the 273 selector names in the table below, twenty at a time, against an eight-second budget. Before trusting any answer it queries a random nonsense selector, because some domains answer every _domainkey name with the same record — a wildcard — and a tool that does not check will happily report hundreds of selectors that do not exist. Anything identical to the wildcard’s answer is discarded, and you are told it happened.

For every hit it also asks whether the name is a CNAME. Microsoft 365, SendGrid, Postmark, HubSpot and many others do not put the key in your zone; they have you point the selector at a name in theirs. The target of that CNAME is a far better guide to who signs your mail than the selector’s name, so it is what the provider column is based on when one exists. The record itself is then parsed for key type and size, the testing and strict flags, and an empty p=, which is how a key is revoked.

The limits: the list is finite, random selectors are invisible to it, a slow nameserver returns a partial result rather than none, and the lookups come from our resolver, which can differ from what a particular receiver sees. Results are cached for an hour.

Common selectors by provider

Generated from the list the finder tests (version 2026-09-09), so this table cannot drift from what actually runs. Generic names like default and dkim are tested too but not listed here, because they belong to nobody in particular.

Missing one that a provider genuinely issues? Report a missing selector — include the provider and, ideally, a domain where it resolves.

How to find your selector from an email header

Send a message from the system in question to a mailbox you control, then view the raw source. Find the DKIM-Signature: header. It is a list of tag=value pairs, and two of them matter here: d= is the signing domain and s= is the selector. Together they name the DNS record the receiver fetched. A message can carry several signatures — one from your provider, one from a forwarder — so check the d= matches your domain before trusting the s= beside it.

The same headers carry Authentication-Results, where the receiver recorded whether that signature verified and whether it aligned with the From domain. The header analyzer reads both and explains the verdict.

Fix what it finds

• A selector exists but the signature fails on arrival — 5.7.9 DKIM signature invalid covers what modifies messages in transit.
• SPF passes and DKIM fails on the same message — SPF pass, DKIM fail works through the causes in order.
• DKIM passes and SPF fails — DKIM pass, SPF fail explains why that is often not a problem and when it is.
• Which selector each provider uses, and which are unguessable — DKIM selectors by provider and why selectors cannot be listed.
• Everything at once, with the record to publish — the SPF, DKIM and DMARC checker.

Common questions

How do I find the DKIM selector for a domain?

Two ways. If you have a message the domain sent, open its headers and read the s= tag in the DKIM-Signature header — that is the selector, with certainty. If you do not, you can only guess: query <selector>._domainkey.<domain> for the names providers are known to use. That is what this finder does, with the names of every major provider and the CNAME targets they delegate to.

Can a domain have two DKIM selectors?

Yes, and most do. Every sending system needs its own key, so a company sending from Google Workspace, a marketing platform and a helpdesk has at least three selectors. Microsoft 365 publishes two on its own, selector1 and selector2, and rotates between them. Several selectors on one domain is normal; it is the one you cannot account for that deserves a look.

What does "DKIM selector is successfully verified" mean?

It is the message a provider shows once it can read the public key at the selector name you were asked to publish — nothing more. It confirms the DNS record exists and parses. It does not mean mail is being signed, that the signature aligns with your From domain, or that DMARC passes. Send a message to a mailbox you control and read the Authentication-Results header to confirm the rest.

What is an unused DKIM selector?

A selector record still published for a system that no longer signs with it — an old marketing platform, a migrated mail host. It costs nothing while it holds a valid key, but it is a key you have forgotten you hold. If the provider that owned it is gone, revoke the record by publishing it with an empty p= value, so nobody who obtains the old private key can sign as you.

Why is my DKIM selector not detected?

Usually because it is not in the list. Selectors cannot be enumerated from DNS, so a finder can only try names it knows, and some providers issue names that cannot be known: Amazon SES Easy DKIM uses random tokens, HubSpot embeds an account ID, Zoho uses a timestamp. Read the s= tag from a sent message instead, then check that exact name with the custom-selector field above. If it still fails, the record is genuinely missing or published at the wrong name.

Is a 1024-bit DKIM key still OK?

It still verifies at every major receiver, so mail will not fail because of it today. But 1024 bits is the floor, not the recommendation: Google, Microsoft and M3AAWG all advise 2048, and it is what providers now issue by default. Keys below 1024 bits are a different matter — receivers ignore them, which is the same as having no DKIM. Rotate a 1024-bit key when convenient; replace anything smaller now.