DKIM Selector Examples: Naming, Rotation, and Multi-Selector Setup

The DKIM selector is the small detail that lets one domain publish multiple DKIM keys — one per sending platform, plus past and current rotation versions. Most senders touch selectors only when they're setting up a new ESP and never look at the naming again, which is why most domains end up with a confusing mix of selector1, default, mail, and s1 records that nobody can remember the origin of.

This guide is the selector naming and management approach I use when setting up DKIM for a new sending stack, with real examples pulled from public DNS records of major senders.

What a DKIM selector actually does

When a receiver verifies a DKIM signature, it reads two values from the DKIM-Signature header:

• d= — the signing domain
• s= — the selector

It then queries DNS for <selector>._domainkey.<d> and expects a TXT record with the public key. So s=selector1; d=example.com triggers a lookup of selector1._domainkey.example.com.

The selector is just a label. It can be any DNS-legal string. But choosing it well matters because rotation, multi-sender setups, and troubleshooting all depend on selector readability.

Real-world DKIM selector examples

These are common selector patterns from production senders:

Provider	Selector pattern	Example
Google Workspace	google	google._domainkey.example.com
Microsoft 365	selector1, selector2	selector1._domainkey.example.com
SendGrid	s1, s2, or custom	s1._domainkey.em123.example.com
Mailgun	mx, k1, or custom	k1._domainkey.example.com
Mailchimp	k1, k2 (CNAME chain)	k1._domainkey.example.com
Klaviyo	dkim or klaviyo	dkim._domainkey.example.com
Amazon SES	random hash	abc123def456._domainkey.example.com
Postmark	<token>pm	20231101pm._domainkey.example.com
HubSpot	hs1, hs2	hs1-12345._domainkey.example.com

Some providers let you pick the selector; others (SES, Postmark) generate it for you and the value is opaque. When you can pick, do so thoughtfully.

A naming convention that scales

For domains that will use multiple senders, I recommend a <provider>-<purpose>-<version> pattern:

• sg-marketing-202605 — SendGrid for marketing, May 2026 key
• mg-transactional-202605 — Mailgun for transactional, May 2026 key
• klaviyo-202605 — Klaviyo, May 2026 key
• m365-202605 — Microsoft 365 with date-based rotation
• google-202605 — Google Workspace with date-based rotation

When you rotate keys, increment the date:

• Active: sg-marketing-202605
• New (during rollover): sg-marketing-202611
• Old (kept temporarily): sg-marketing-202511

For single-sender domains or smaller setups, simpler names are fine:

• selector1, selector2 (Microsoft style)
• s1, s2
• mail, mail2

What to avoid:

• default — gives no information about what's signing
• key1 without a versioning system — ambiguous on rotation
• Generic dkim — provides no provider context
• Repurposing a deprecated selector for a new sender — confuses retention windows

Practitioner note: The single best naming choice you can make is including a date or version in the selector. When troubleshooting why a message failed authentication 3 weeks ago, the selector tells you which key version signed it and whether that key is still in DNS.

Multi-selector setups

A domain can — and usually should — have multiple active DKIM selectors. Each sending platform should sign with its own key, published at its own selector.

Example DNS for a domain using Microsoft 365 for internal mail, SendGrid for marketing, Klaviyo for ecommerce, and Mailgun for transactional:

selector1._domainkey.example.com.        TXT  "v=DKIM1; k=rsa; p=..."  ; Microsoft 365
selector2._domainkey.example.com.        TXT  "v=DKIM1; k=rsa; p=..."  ; Microsoft 365 (rotation)
sg-marketing-202605._domainkey.example.com. TXT  "v=DKIM1; k=rsa; p=..."  ; SendGrid
klaviyo-202605._domainkey.example.com.   TXT  "v=DKIM1; k=rsa; p=..."  ; Klaviyo
mg-transactional-202605._domainkey.example.com. CNAME mg-transactional-202605._domainkey.mg.example.com.

Each sender's mail signs with its own selector. If you need to revoke or rotate one, the others are unaffected.

Practitioner note: Treat the selector list like a sender inventory. If you find a DKIM selector in DNS that you don't recognize, investigate it before deleting — it might be active. But also: every selector in your DNS that isn't actively signing should be removed within 60 days of decommissioning, because old keys are an attack surface.

CNAME vs TXT selectors

Some providers (Mailchimp, Mailgun, HubSpot, Microsoft 365) prefer CNAME records that delegate the DKIM lookup to their infrastructure. Others (SendGrid Sender Authentication, Google Workspace, your own Exchange) publish the public key directly as TXT.

Style	Pros	Cons
TXT (key inline)	Full control, key visible	You manage rotation manually
CNAME (delegated)	Provider rotates the key for you	Less control, depends on provider DNS

The CNAME vs TXT authentication piece covers the tradeoffs. For most multi-sender setups, mix both — TXT for senders you control directly, CNAME for managed ESPs that can rotate transparently.

Rotation procedure

Standard rotation for any selector:

1. Generate a new key pair (2048-bit RSA, per RFC 8301).
2. Publish the new public key at a new selector (e.g., sg-marketing-202611).
3. Wait 24 to 48 hours for DNS propagation and any cached lookups.
4. Switch the sender to sign with the new selector.
5. After 7 days (enough for in-flight mail to clear), remove the old TXT record.

See DKIM key rotation for the full procedure with verification steps.

Selector character rules

The selector portion can contain:

• Letters, digits, hyphens
• Underscores (legal but unusual outside the _domainkey prefix)

It cannot contain:

• Periods (the period separates DNS labels — use hyphens instead)
• Special characters
• Spaces

The full record path uses standard DNS label rules: each label max 63 characters, total length under 253. Most selectors stay well under these limits.

Verifying a selector

After publishing, verify with:

dig TXT sg-marketing-202605._domainkey.example.com

Or use MXToolbox's DKIM Lookup.

Then send a test message and check the receiver's Authentication-Results header for dkim=pass. If the public key is malformed or chunked incorrectly, this is where it shows up.

For ongoing visibility, monitor DKIM pass rates via DMARC aggregate reports — see common DKIM failures for what to look for.

If you're cleaning up a tangled DKIM setup with mystery selectors, untracked senders, or rotation no one has touched in years, book a consultation. DKIM hygiene is one of the most common deliverability audit findings and one of the fastest to fix.

Sources

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• Microsoft Learn — Configure DKIM for Microsoft 365
• Google Workspace Admin — Authenticate Email with DKIM
• M3AAWG DKIM Key Rotation Best Practices
• MXToolbox — DKIM Selector Lookup

---

v1.0 · May 2026