DKIM selector finder
Every other DKIM checker asks you for the selector you came here to find. This one does not need it, and it does not need a sample email either: it queries the selector names mail providers publish by default and tells you which of them your domain answers to.
Find your selector
Enter a domain. Warden queries every selector name mail providers publish by default — Google Workspace, Microsoft 365, Mailchimp, SendGrid, Zendesk and around a hundred more — and reports which ones resolve, what key each holds, and whether it can still sign. Every record it read is shown underneath.
Why this question is hard
SPF and DMARC live at names you already know — the domain itself, and _dmarc.yourdomain. A DKIM key does not. It lives at <selector>._domainkey.yourdomain, where the selector is an arbitrary string chosen at the moment somebody configured outbound mail. DNS will answer if you name the right label and stay silent if you do not, and there is no record anywhere that lists them.
That is why the standard advice is “open an email you sent, view the source, find the DKIM-Signature header, read the s= tag”. It works, and it is the definitive answer. It is also useless when you are auditing a domain you do not send mail from — a client’s, an acquisition target’s, a subsidiary nobody has looked at in three years.
The remaining option is a dictionary: providers overwhelmingly publish documented default selector names, so querying those names answers the question for most real domains. This tool queries around a hundred of them, attributes each hit to the service that name belongs to, and shows the record it read so you can repeat the lookup yourself.
What it reports
- Which selector names resolve, each with the full TXT record and the exact dig command that produced it — so the result is checkable rather than asserted.
- What key each selector holds: RSA and its size, or Ed25519. A key under 1024 bits is flagged against RFC 8301, which permits receivers to treat it as unsigned.
- Whether a selector is published but unusable — an empty p= tag is the documented way to revoke a key, and t=y puts it in test mode, where receivers are asked to ignore a failed signature entirely.
- How many keys can currently sign as you, read as an inventory rather than a score: a key stays valid until somebody deletes the record, so a platform you stopped using can still sign in your name.
- The DMARC record alongside, including whether adkim=s requires exact alignment — because a valid signature nothing is checked against enforces nothing.
Limits stated plainly. A selector chosen by hand will not be found, and neither will one a platform mints per tenant — Postmark and Amazon SES both do this, so a domain sending through either can show no hits while signing every message correctly. A run that finds nothing means no known default resolved; it is not evidence that the domain has no DKIM. Only a signed message proves that.
Questions this raises
How do I find my DKIM selector?
There are two ways. If you have a message the domain sent, open its source and read the s= tag in the DKIM-Signature header — that is the selector, definitively. If you do not, the only option is to query the selector names providers publish by default at <selector>._domainkey.yourdomain and see which resolve. That is what this tool does, across around a hundred documented defaults.
Why can't I just look up my DKIM selector in DNS?
Because nothing in DNS enumerates them. SPF lives at a known name (the domain) and DMARC lives at a known name (_dmarc.yourdomain), but a DKIM key lives at <selector>._domainkey.yourdomain, and the selector is an arbitrary string chosen by whoever configured the sending service. DNS will answer if you name the right label and return nothing if you do not, and there is no way to ask it for a list.
What is the DKIM selector for Google Workspace and Microsoft 365?
Google Workspace uses google by default. Microsoft 365 publishes selector1 and selector2, usually as CNAMEs pointing at onmicrosoft.com names, and rotates between them. Both are in this tool's dictionary, so a domain on either platform is normally identified on the first run.
Does 'no selector found' mean the domain has no DKIM?
No, and this is the most common wrong conclusion. A dictionary probe only finds names it knows. A selector chosen by hand, or minted per tenant — Postmark and Amazon SES both do this — will not be found however many defaults are tried. No selector found means no known default resolved, nothing more. Only a signed message proves the negative.
Is it a problem to have several DKIM selectors?
Not in itself: each sending platform gets its own key, so a company using a mail provider, a marketing tool and a support desk legitimately publishes three or more. The useful reading is as an inventory. A key stays valid until somebody deletes the record, so a platform you stopped using last year can still sign mail in your name today, and nobody receives a reminder to remove it.
What do p= and t=y mean in a DKIM record?
p= carries the public key. A p= tag that is present but empty is the documented way to revoke a key: the selector still resolves, but any signature made with it fails. t=y marks the key as being in test mode, which asks receivers to treat a failed signature as though the message were unsigned — so the key is published but enforces nothing.
Does this tool scan my systems?
No. It reads public TXT records — the same DNS any receiving mail server reads to verify a signature. No mail is sent, no host is connected to, and nothing inside your systems is accessed. Warden does not access, scan or investigate anything without agreed scope and explicit written authorization.
Where this sits against your other findings
A stale DKIM key has no CVE and no CVSS score, so it does not appear on the report that drives most remediation queues — while being a live signing credential held by a service nobody on the team still uses. The same is true of the record next door: the SPF lookup checker counts the lookups against the RFC 7208 limit of 10 and totals how many IPv4 addresses your chain authorizes to send as you, which is routinely in the hundreds of thousands.
Both are single signals. The exposure check reads them together with DMARC and the headers your homepage returns, and puts the result in priority order with the evidence for each.