DKIM Selector Example: How Selectors Work and What to Publish
A DKIM selector is the small label that tells a receiving server which public key to fetch. It is not the whole domain, and it is not the public-key value.
Selector anatomy
If a message contains:
DKIM-Signature: ...; d=example.com; s=s1; ...the receiver looks up:
s1._domainkey.example.comThe s= value is the selector; the d= value is the signing domain.
| Provider screen | DNS field | Example |
|---|---|---|
| Selector | Label in front of ._domainkey | s1 |
| Domain | Zone used for the signing identity | example.com |
| Host/name | Selector plus ._domainkey | s1._domainkey or full host |
| Value | Public key | v=DKIM1; k=rsa; p=... |
The DNS UI may ask for a relative host or a fully qualified host. If it automatically appends example.com, entering the full name can create a duplicated domain.
Why providers use different selectors
Selectors let multiple senders publish keys under the same domain. You might see:
- google for Google Workspace;
- s1 or s2 for a marketing provider;
- k1 for a transactional provider;
- a generated label for a dedicated sending stream.
The name itself has no security meaning. What matters is that the sender signs with the selector whose public key is published, and that the signing domain is authorized and aligned when DMARC is evaluated.
Key rotation
A provider can introduce s2 while continuing to sign with s1 during a transition:
| Phase | Message selector | DNS requirement |
|---|---|---|
| Before rotation | s1 | s1._domainkey resolves to the old public key |
| During rotation | s1 or s2 | Both selectors must resolve |
| After rotation | s2 | Keep s1 only while old messages or retries may exist |
Never delete the old selector the moment a dashboard says “rotation started.” Allow for queued, delayed, and retried mail according to the provider’s transition guidance.
Verify the selector
Query the exact host:
dig +short TXT s1._domainkey.example.comThen inspect a message from the actual stream. Confirm:
- s= matches the selector you queried;
- d= is the expected signing domain;
- the header says dkim=pass;
- the DKIM domain aligns with the visible From domain for DMARC, or aligned SPF provides the DMARC pass.
If DNS returns a key but the message uses another selector, the DNS record is not the immediate problem. Find the provider configuration or sending stream that owns the selector in the header.
Selector mistakes
| Mistake | Result | Fix |
|---|---|---|
| Publish at the root domain | Receiver cannot find the key | Add ._domainkey and the selector |
| Use the full host in a relative-name field | Domain is appended twice | Enter only the relative label |
| Copy the selector as the TXT value | No public key is available | Copy the complete provider-generated key |
| Publish two values for one selector | DNS returns an ambiguous record set | Keep one valid TXT value per selector |
| Check one selector but send with another | Dashboard and message appear inconsistent | Match the header’s s= value |
DKIM is not DMARC by itself
A passing DKIM signature proves that the signature validates. DMARC also asks whether the authenticated domain aligns with the visible From domain. For example, d=provider.example can pass DKIM while From: news@example.com fails DKIM alignment.
Google’s email sender guidelines recommend SPF, DKIM, and DMARC for sending domains. Use the selector as one part of the full authentication chain, not as an isolated green check.
FAQ
Is the selector secret?
No. It is published in DNS and appears in message headers. The private signing key is secret.
Can I choose any selector?
Only if your provider lets you. In managed sending, use the selector it generates so the private key and DNS record match.
Why does verification work in one tool but not another?
Resolvers may have cached different answers, and DNS tools may query different providers. Compare the authoritative DNS response, public resolver results, and the message header.
What should I do when a selector stops resolving?
Pause the affected stream if DKIM is required, restore the correct TXT record, and send a real test. Do not solve it by publishing an unrelated key under a different selector.
See the DKIM record example for the full TXT record setup.