- DKIM selector, defined
- A DKIM selector is the label in a signature that tells the receiving server which DNS record holds the matching public key, letting one domain publish several keys at once.
The signature header carries s=selector1 and d=yourdomain.com. The receiver builds selector1._domainkey.yourdomain.com and queries it. No signature, no way to guess the name.
Several keys can live side by side, and this is what makes multiple senders workable. Microsoft 365 uses selector1 and selector2, Google uses google, and sending platforms generate their own, each isolated from the others.
The same design makes rotation painless. Publish the new selector, wait for DNS to settle, switch signing over, and leave the old record in place until the last message signed with it has been delivered.
If you inherited a domain and need the list, read a DKIM-Signature header from a message it actually sent. That header names the selector directly, which is the only reliable route.
How ZapBounce reports it
Our DKIM checker takes a domain and a selector because there is no lookup that returns the list. It reports the key found, its length, and whether the record parses as a valid key rather than a truncated paste.
From a message header to the public key in two steps
Open any message your domain sent and view the raw source, which Gmail calls Show original. Find the header that begins DKIM-Signature: and read two tags from it. Say it contains d=acme.example and s=s2048.
Those two values give you the DNS name: s2048._domainkey.acme.example. Run dig +short TXT s2048._domainkey.acme.example and you should get back something like v=DKIM1; k=rsa; p=MIIBIjANBgkq followed by a long run of characters. That p= value is the public key, and a receiving server fetches it the same way you just did.
Often you'll get a CNAME instead of a key. Many sending platforms ask you to point the selector name at a record in their own zone, so they can rotate the key without you touching DNS again. Follow the CNAME and the key is at the other end.
Three ways a selector record goes wrong
Truncation is the common one. A 2048-bit key is longer than the 255 characters a single TXT string can hold, so it has to be published as two quoted strings that the resolver joins. Some DNS control panels split it for you and some silently cut it off. A cut-off key still looks like a key, and every signature made with it fails.
An empty p= tag is a different case, because under RFC 6376 it means the key has been revoked on purpose, and receivers treat signatures that point at it as failed. You'll see this on old selectors after a rotation, and it's correct.
Wrong placement is the last of the three, and it's easy to miss. Your record belongs at selector._domainkey.yourdomain.com, and a panel that appends your domain automatically can turn that into selector._domainkey.yourdomain.com.yourdomain.com. If dig returns nothing, check for the doubled name first. Naming selectors by date, such as 2026q3, makes later rotations much easier to follow.
DKIM selector: common questions
How do I find a domain's DKIM selector?
Read the DKIM-Signature header of a message that domain sent. The s= tag names it. DNS offers no way to enumerate selectors.
Can one domain have several selectors?
Yes, and most do. Each sending platform gets its own, which is how multiple senders sign for the same domain independently.
What are the common default selectors?
selector1 and selector2 for Microsoft 365, google for Workspace, and platform-specific names elsewhere such as k1 or mandrill.