DKIM selector checker

A DKIM key lives at a name derived from a selector the sender chooses freely. The selector is carried in the signature header of each message, which is how a receiver knows where to look.

DNS has no operation that lists the names under a domain. A receiver never needs one, because it always has the selector in front of it.

An external checker has no message and therefore no selector. It can only try names, which means it finds the conventional ones and misses anything custom.

So a selector named after a random string will not be found, and that is a property of DNS rather than a gap in the tool.

A list of the selector names the common mail providers and platforms use by default is queried. Most domains sign with one of them, because most domains use one of those providers.

Selectors referenced elsewhere in the domain's own published records are followed where they appear.

Each name that answers is retrieved and the key material is read to confirm it is a well-formed DKIM key record rather than an empty or revoked one.

Nothing is brute-forced. There is no generated name list, because trying names at scale against a DNS server is a different activity from auditing a domain.

That a key is published under that selector, and that it parses. This is worth confirming after a provider migration, when the old selector often remains and the new one is forgotten.

The key algorithm and size, where the record publishes them.

It does not tell you that messages are signed. A published key and an unsigned message stream is a real state, and it is what happens when signing is configured on the DNS side and never enabled on the sending side.

It does not tell you the signature validates, since validating one requires a message.

A record published with an empty key is a revocation — the selector exists and deliberately authenticates nothing.

The correct reading is that no conventional selector answered. It is not the same statement as the domain does not sign.

A domain signing under a custom selector produces exactly this result, and the report says so rather than reporting an absence as a defect.

The way to settle it is to open the raw headers of a message the domain sent and read the selector out of the signature, then query that name directly.

This is also why DKIM alone is a poor basis for a spoofing assessment, and why the exposure statement combines it with SPF and DMARC rather than standing on it.

`email.dkim.selectors` queries the known selector names and reports the keys found, along with the coverage statement about what could not be enumerated.

`email.spoofing_exposure` combines DKIM with SPF and DMARC into the overall exposure statement, which is the only one of the three that can be read on its own.

`email.usage_context` establishes whether the domain appears to send mail at all, which decides whether any of this is a finding or simply not applicable.

Selectors cannot be listed. Only conventional names are queried, so a custom selector is invisible to this and to every other external checker.

A found key does not prove messages are signed, and an absent key does not prove they are not.

No signature is validated, because validating one requires a message this scan does not have.

Key rotation is not observable from a single query: a selector answering today says nothing about the rotation schedule behind it.