DKIM selectors: how they work and why checkers cannot find yours
A DKIM public key does not live at a fixed name. It lives at <selector>._domainkey.yourdomain, where the selector is an arbitrary label chosen by whoever generated the key.
Why selectors exist
One domain usually sends through several platforms, and each needs its own key. Selectors keep them apart: Google might sign with google, your marketing platform with k1, your helpdesk with zendesk1. All three keys coexist under the same domain.
They also make key rotation safe. Publish the new key under a new selector, switch signing over, and remove the old one once mail signed with it has drained. No gap where mail is unsigned.
Why no tool can list them
DNS has no way to enumerate names under a label. You cannot ask "what selectors exist for this domain" — you can only ask "does k1._domainkey.example.com exist", one guess at a time.
So every DKIM checker, including this one, probes a list of selectors that common providers are known to use. A hit proves DKIM is configured. A miss proves nothing at all: your key may sit on a custom selector that no list would guess.
DKIM-Signature header, and read the selector from the s= tag.Finding your selector from a real message
Send yourself a message and view its raw source. Look for a header like:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
d= is the signing domain and s= is the selector. For DMARC to pass on DKIM, d= must align with your From: domain — a signature with d= pointing at your provider's domain authenticates them, not you.
Key length
Use 2048-bit keys. 1024-bit is still accepted but no longer considered adequate. The one practical snag is that a 2048-bit key is too long for a single DNS TXT string, so it must be split into chunks — most DNS providers do this automatically, but a few require you to split it yourself. If a freshly published 2048-bit key fails to verify, that is the first thing to check.