DNS Tools
EMAIL AUTHENTICATION GUIDE

DKIM Selectors Explained

A DKIM signature points to a key by two names, a domain and a selector. Understanding that one detail explains why DKIM checks need your input and how key rotation works without downtime.

How a selector fits in

When a mail system signs a message under DKIM (RFC 6376) it adds a DKIM-Signature header. Two tags in it identify the key: d= is the signing domain and s= is the selector. The verifier joins them into a DNS name of the form s._domainkey.d, queries the TXT record there, and uses the public key to check the signature.

The selector exists so that one domain can publish many keys at once. A company may have one selector for its main mail platform, another for a newsletter service, another for an application, and a new one for each key rotation. The names are arbitrary text chosen by whoever sets up signing; common ones include dates, provider names or simple labels like s1 and s2.

Why selectors cannot be enumerated

DNS answers questions about names you already know. It has no operation that lists the child labels below _domainkey, and zone transfers are generally not available to the public. A DKIM checker therefore cannot discover which selectors a domain uses. The DKIM checker queries exactly the selector you enter, and its 'not found' result applies only to that name. A guess that fails does not mean the domain has no DKIM, and a guess that succeeds does not mean it is the only selector or that any mail is currently signed with it.

This also means a report that claims to list every DKIM selector for a domain is guessing from common names. Treat such claims with caution.

Finding the selector a message used

  1. Open a message the domain really sent and choose the option to show the original source or full headers.
  2. Find the DKIM-Signature header. There may be several, one for each signing system.
  3. Read the d= and s= values. The key sits at s._domainkey.d.
  4. Compare d= with the From domain. A signature whose domain does not align with From can pass DKIM and still not count for DMARC.
  5. Enter the domain and selector into the DKIM checker, or paste the headers into the header analyzer, which extracts the claimed values.

What lives at the selector name

The record is TXT data made of tags such as v=DKIM1, k=rsa or k=ed25519, p= with the base64 public key, and optionally t=y for testing. An empty p= means the key has been revoked. Many providers do not give you a TXT value at all but ask you to create a CNAME from the selector name to a name they control, so they can rotate keys on your behalf; the DKIM checker identifies this and treats it as normal.

RSA keys of 2048 bits are the usual recommendation today, and 1024 bits is considered weak. A 2048-bit key exceeds the 255-character limit of a single DNS string, so it is published as several quoted strings in a single TXT record. Splitting it into several TXT records, or losing characters in copy and paste, makes the key unusable.

Rotating keys safely

Rotation limits the damage if a private key leaks and keeps cryptographic strength current. The safe pattern relies on selectors: publish a new key at a new selector name while the old one stays published. Switch the signing system to the new selector, send a test message and confirm that the result is dkim=pass for the new s= value. Leave the old selector published for long enough that queued and delayed mail signed with it can still be verified, then retire it by removing the record or setting an empty p=.

Overwriting the active selector with a new key is the common mistake. For a short time, messages signed with the old private key fail against the new public key, and caches keep serving one or the other. If DMARC enforcement depends on DKIM alone, those failures can lead to rejected mail. As a rollback, keep the previous record text and the previous selector configuration until the new setup is proven.

Common pitfalls

  • Testing mode (t=y) left on after rollout.
  • Two TXT records at the same selector, so verifiers may pick the wrong one.
  • Signing with a subdomain while publishing the key at the parent, or the reverse.
  • A mailing list or gateway that modifies the body or subject after signing, which breaks the signature.
  • Believing a pass in a header is proof. The header analyzer reads results as claims; only your own server's verification counts.

Frequently asked questions

Can I list all selectors for a domain?

No. DNS provides no listing of the labels under _domainkey. You need the s= value from a real message or from your provider.

How many selectors can a domain have?

As many as you need. Each is just a DNS name with its own key.

What does an empty p= do?

It revokes the key. Signatures that use that selector are intended to fail verification.

How often should I rotate keys?

There is no single rule. Many organisations rotate on a schedule or when staff or vendors with access change. Follow your provider's guidance.

Written by DNS Tools editorial · Last updated 2026-10-09