Selector
A label that picks which key to verify against, published at <selector>._domainkey.<domain>. It lets a domain run several keys at once and rotate them one at a time.
DNS has no operation for listing what exists under a name, so no tool can enumerate a domain's DKIM selectors. This one tries sixteen documented provider defaults and says so plainly — because the alternative, reporting "no DKIM found" as though it were a fact, is simply wrong.
A label that picks which key to verify against, published at <selector>._domainkey.<domain>. It lets a domain run several keys at once and rotate them one at a time.
Open the headers of any message the domain sent and look at DKIM-Signature. The s= field is the selector. Entering it above gives a definite answer instead of a guess.
Measured here by parsing the published key, not estimated from the length of the base64 text. Under 1024 bits, RFC 8301 requires verifiers to treat the message as unsigned.
An empty p= tag is how DKIM withdraws a key. Correct for a retired selector; a problem for one still signing mail.
Testing mode left on. t=y tells receivers to treat signed and unsigned mail identically, so the signature achieves nothing. It belongs in the first hour of a rollout and is routinely forgotten afterwards.
1024-bit keys. Still accepted, but 2048 is the recommendation and several large receivers have said they intend to stop accepting 1024. The usual reason for the short key is that a 2048-bit one does not fit in a single 255-character TXT string and somebody's DNS editor refused it — splitting it across two strings is the answer, and most hosts now do it automatically.
A wildcard at *._domainkey. Every selector name then appears to exist. If the wildcard publishes an empty key it is a deliberate statement that the domain does not sign, which is reasonable. If it publishes a real key, selectors stop being useful: nothing can be rotated or revoked without invalidating every signature at once.
A key that cannot be parsed. Almost always a copy-and-paste that lost characters, or a record split in the wrong place. The signature fails for every message and nothing in your own logs says why.
DNS has no mechanism for it. You can ask "what is at this name?" but not "what names exist here?", so a DKIM checker can only try names it knows about. Anyone claiming to enumerate your selectors is either guessing from a list like ours or has seen mail from you.
In the DKIM-Signature header of any message the domain has sent — the s= field. In Gmail, Show original; in Outlook, View message source. If the domain uses several senders there will be several selectors, each in the messages that sender produced.
Not yet, and not urgently, but it is below the current recommendation and the direction of travel is clear. Rotating to 2048 is a short piece of work: generate a new key, publish it at a new selector, switch signing to it, and remove the old record once nothing uses it. Keys under 1024 bits are a different matter — RFC 8301 requires verifiers to treat those messages as unsigned.
Each system that signs mail as your domain needs its own, and each is published separately. More than one is normal. Having several also makes rotation safe, because you can bring a new key up before taking the old one down.
Not by itself. It proves a message was signed by someone holding the key, but says nothing about what address the recipient sees. DMARC requires the visible From domain to align with the signing domain and tells receivers what to do when it does not — that combination is what stops spoofing.
Getting to an enforced DMARC policy means finding every system that sends as you — the CRM, the invoicing platform, the scanner in the corner — and authorising them before you tell the world to reject the rest. We do that migration, and then the inbound side that display-name spoofing walks straight past.