Introduction
A DKIM selector is a short label — like google, selector1, mail — that lives in the DKIM-Signature header and tells receivers where to find the public key. It's the part that lets a single domain have multiple DKIM keys for different senders, each independently rotatable.
This article covers what selectors are, why distinct selectors per sender matter, and how to manage them in production.
Why this topic matters
Without selectors, every sender on your domain would share one DKIM key. Rotation would require all senders to switch simultaneously; revocation would break everything. Selectors let you treat each sender as an independent unit — issue a key, rotate it, retire it, without affecting other senders.
For DMARC rollouts involving multiple SaaS platforms, selector hygiene is what keeps the architecture sane.
How selectors actually work
In the DKIM-Signature header:
“text DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=marketing; c=relaxed/relaxed; ... “
The s=marketing is the selector. When the receiver verifies, it queries:
“text marketing._domainkey.yourdomain.com “
Whatever TXT record lives there is the public key. The receiver uses it to verify the signature.
Why distinct selectors per sender
Three reasons:
- Independent rotation. Rotate Mailchimp's key without touching SendGrid's.
- Independent revocation. A compromised SaaS account can have its key revoked instantly without affecting other senders.
- Audit clarity. A glance at a DKIM-Signature header tells you which platform sent the message.
The default in many SaaS platforms is a selector that includes their name — mailchimp1._domainkey.yourdomain.com, s1._domainkey.yourdomain.com. These are fine, just verify each platform has its own.
Step-by-step approach
- List every sending platform that signs with your domain.
- For each, note the selector the platform provides (or generates during setup).
- Publish each public key at
<selector>._domainkey.<your-domain>. - Confirm signing. Send test messages; check the
s=value in headers.
For multi-key setups (e.g., rotation in progress), both old and new public keys can live in DNS simultaneously. Receivers use whichever selector is referenced in the incoming message.
Best practices
- Distinct selector per sender platform. Never share keys.
- Meaningful selector names where you control them.
marketing,transactional,salesoverselector1,selector2. - Rotate annually. How to rotate DKIM keys safely covers the procedure.
- Document the selector list. Map selector to sender; keep updated.
- Don't reuse selectors across rotation. New rotation = new selector name.
Recommended next step
Run dig +short TXT default._domainkey.yourdomain.com and dig +short TXT selector1._domainkey.yourdomain.com to see what's currently published. Compare against your sender list. Mismatches indicate either missing or orphaned keys.
FAQ
Can I use any name as a selector?
Yes — selectors are domain-owner-defined labels. Receivers don't care what they're called, only that the DNS lookup succeeds.
What if two platforms try to use the same selector?
The last-published key wins; the first platform's signatures will fail. Always use distinct selectors.
Why are some selectors numeric (s1, s2)?
Convention from some providers, especially for rotation patterns. Numeric selectors work fine; just track which is current.
How long can a selector name be?
In practice, keep under 50 characters. Longer selectors can hit DNS label limits.
Can I retire a selector?
Yes — delete the TXT record at <selector>._domainkey.yourdomain.com. Any future messages signed with that selector will fail verification. Use this for revocation.
Final thoughts
DKIM selectors are an under-appreciated piece of the authentication stack. They give you per-sender granularity — rotation, revocation, audit — that would otherwise require coordinated changes across every platform.
Treat selectors as first-class infrastructure. One per sender, named meaningfully, documented, rotated on schedule. That's the posture that scales.