What Is a DKIM Selector? selector._domainkey Explained

A DKIM selector is a short name, chosen by the mail provider, that points receivers to the specific public key used to verify a DKIM signature. It appears in the s= tag of the DKIM-Signature header and forms the DNS name selector._domainkey.yourdomain.com where the key is published. Selectors let one domain hold several keys at once.

Quick summary

• A private key that signs mail for years is a bigger target. Rotating limits the damage if it ever leaks.
• With selectors, a provider can publish key2 under a new selector, start signing with it, and retire key1 later. Mail in transit still verifies against the old record.
• Long-lived messages in archives keep verifying as long as the old selector record remains in DNS.
• This is why you should never delete a DKIM record just because it looks unused, unless your provider tells you it is retired.
• Open the message in Gmail, choose Show original, and look for DKIM-Signature.

How the selector is used

When OquMail signs an outgoing message, it adds a DKIM-Signature header containing d=yourdomain.com (the signing domain) and s=selector (the selector). The receiving server joins the two into selector._domainkey.yourdomain.com, fetches the TXT records (short text lines in DNS used for email security) there, reads the public key, and checks the signature. If the record is missing or the key does not match, the result is DKIM fail.

Example DKIM record

The selector name is specific to your provider. The host below uses a placeholder; your OquMail dashboard shows the real selector and the full key for your domain.

Type:   TXT
Host:   oqumail._domainkey
Value:  v=DKIM1; k=rsa; p=… (the exact key is shown in your OquMail dashboard)

In the message header:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=oqumail; h=from:to:subject:date; bh=...; b=...

Why keys rotate and why selectors make it painless

• A private key that signs mail for years is a bigger target. Rotating limits the damage if it ever leaks.
• With selectors, a provider can publish key2 under a new selector, start signing with it, and retire key1 later. Mail in transit still verifies against the old record.
• Long-lived messages in archives keep verifying as long as the old selector record remains in DNS.
• This is why you should never delete a DKIM record just because it looks unused, unless your provider tells you it is retired.

How to find the selector on a real message

1. Open the message in Gmail, choose Show original, and look for DKIM-Signature.
2. Read the s= value. That is the selector. Read d= for the domain.
3. Run nslookup -type=txt selector._domainkey.domain.com to see the public key.
4. Under the Gmail summary, DKIM: PASS with signed-by domain confirms everything lined up.

Common DKIM selector mistakes

• Entering the host as oqumail._domainkey.yourdomain.com in a panel that automatically appends the domain, producing a doubled name.
• Pasting a key that was truncated at a line break, especially 2048-bit keys that exceed 255 characters and must be split into quoted chunks.
• Publishing the key under the wrong selector name so the header points at a record that does not exist.
• Leaving a Cloudflare proxy on. TXT records are never proxied, but a typo in the host is easy to miss in a crowded zone.

DKIM and OquMail setup

OquMail generates the key pair for each domain, keeps the private key on its signing servers, and shows you the selector host and TXT value to publish. The dashboard verifies the record live, so a truncated key shows as red instead of failing silently later. Every mailbox and every API send on that domain is signed with the same key, so one record covers your whole team.

Two selectors on one domain

A domain that sends through OquMail for people and through a newsletter platform for campaigns will have two DKIM records: one at the OquMail selector and one at the selector the newsletter tool assigns. Each service signs with its own private key and points at its own selector, so both verify independently and neither record needs to know about the other.

Common questions

Can I choose my own selector name?

Usually not. The provider signs with a fixed selector so its record and its signer agree. Multiple providers on one domain simply use different selectors, which is why they never collide.

Does the selector need to be secret?

No. Selectors and public keys are visible to anyone. Only the private key, which never leaves the mail provider, must stay secret.

What is the difference between the selector and the domain?

The domain (d=) is who is vouching for the message and is what DMARC aligns against. The selector (s=) only chooses which key under that domain to verify with.