There is no way to list a domain’s DKIM keys. DNS answers questions; it does not enumerate a subtree. To read a key you must already know the selector, and the only authoritative place a selector appears is in a signature on a message.
What follows from that
- An audit of “our DKIM keys” is not a DNS query. It is an inventory exercise, built from messages and from what each platform tells you it uses.
- A tool claiming to find a domain’s selectors is guessing — trying a list of common names. Useful, and never complete.
- An unused selector is not discoverable by an attacker either, which is mildly useful and not a security control.
Finding it in a message
Send yourself a message through the platform in question and read the raw source. Every mail client can show it; the header you want is the one the signer added.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=mail202609; ...
^^^^^^^^^^^^
the selectorThen query it, and you have the key the platform is actually using rather than the one its documentation describes:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."
The guessable ones
Vendors use fixed or semi-fixed selector names, so a short list finds most of what a domain uses. These are worth trying against any domain you are assessing:
google Google Workspace selector1, selector2 Microsoft 365 s1, s2 SendGrid (and others) k1, k2, k3 Mailchimp / Mandrill fm1, fm2, fm3, mesmtp Fastmail protonmail, protonmail2 Proton dkim, default, mail generic self-hosted
A hit tells you which platform sends for the domain, which is why this is also the first thing an attacker profiling a target does. It is reconnaissance, not a vulnerability — the same information is in the SPF record, in public.
Aggregate reports close the gap
DMARC aggregate reports name the d= of every signature receivers saw, including from systems you did not know were signing as you. They do not give you the selector, and they do tell you which domains to go looking at — which is more than any guessing list will.