Why DKIM needs a selector, and why there's no way to look it up

DKIM public keys live at a DNS name of the form `‹selector›._domainkey.‹domain›`, which means the selector — an arbitrary label chosen by whoever configured the mail platform — is a required piece of information to even know where to look. Unlike most DNS-based email standards, there's no separate DNS record that announces "here is this domain's DKIM selector," because DKIM was designed to allow multiple simultaneous selectors (for key rotation, or multiple sending platforms each with their own key) with no requirement to publicly enumerate them. That's exactly why the auto-discover feature exists as a best-effort guess against a list of selectors real platforms commonly use by convention, rather than a real lookup — there's genuinely no protocol-level way to ask "what selectors does this domain have."

An empty p= tag is a deliberate revocation, not a broken record

DKIM key revocation is done by publishing the exact same DNS record with an empty `p=` tag rather than removing the record entirely — this is the standard, RFC-specified way to signal "this selector's key has been deliberately retired" while still leaving a record in place that clearly communicates that state to anything checking. Seeing a record that parses successfully but has an empty public key value means exactly that: someone intentionally revoked this specific selector, likely as part of key rotation to a new selector. It's meaningfully different from "no record found," which usually just means the selector guessed was never valid to begin with.