Good DKIM selector names are short, public, stable, and useful when you need to debug a real sending source. Practical examples include google, selector1, selector2, s1, s2, billing, receipts, alerts, k1, k2, and 2026q2. Bad selector names are long, secret-looking, tied to a person's name, or reused by two senders that need different keys.
The selector is the label before _domainkey in DNS. If your DKIM signature says s=s1 and d=example.com, the receiver looks up s1 under the domain's DKIM DNS namespace. If you want a longer list of real-world patterns, the common selectors page is a useful companion.
What a DKIM selector name is
A DKIM selector name is a DNS label that tells the receiving mail server where to find the public key for a DKIM signature. The selector works with the signing domain. The selector is not enough on its own, and the domain is not enough on its own. The pair points to the exact TXT record the receiver needs.
I prefer selector names that tell an operator why the key exists. A selector such as billing says more than x. A selector such as s1 says it belongs to a rotation pair. A provider-issued selector such as selector1 tells you to preserve the provider's exact value.
The selector is public
Do not put secrets, internal ticket IDs, employee names, or private project names in selector names. Anyone who receives a signed message can see the selector in the message headers, and anyone can query the DNS record.
A flowchart showing how a DKIM selector points a receiver to DNS.
Practical selector name examples
The best selector name depends on who owns the signing key and how you plan to rotate it. I use these patterns most often because they are easy to remember and easy to search in email headers.
|
|
|
|
|---|---|---|---|
Provider | google, ses | Hosted senders | Shows vendor |
Rotation | s1, s2 | Key changes | Needs tracking |
Stream | billing, alerts | App mail | Can change |
Date | 2026q2 | Audit trails | Ages visibly |
Environment | prod, stage | Testing | Needs care |
Generic | default, mail | Small domains | Can collide |
Compact DKIM selector name patterns and where they fit.
- Good: Use s1 and s2 when you want a simple rotation pair that never depends on a specific vendor name.
- Good: Use billing or receipts when one application owns a DKIM key and the name helps incident response.
- Good: Use provider-supplied selectors exactly as given, because the provider's signing system expects that DNS name.
- Avoid: Do not reuse default for two different senders unless they intentionally share the same key and DNS record.
Naming rules I use
A selector name only needs to be unique inside the signing domain's DKIM namespace. It does not need to be unique across the internet. That distinction matters. s1 can exist at millions of domains without conflict, but two different keys cannot both occupy s1 for the same domain at the same time.
Keep selectors lowercase, short, and DNS-safe. Letters, numbers, and hyphens are the practical set to use. Avoid underscores in the selector itself, because _domainkey is already the required underscore label. The full topic of selector uniqueness is worth checking before you consolidate several senders under one domain.
Good selector names
- Owner: Use names such as google, ses, or billing when ownership helps debugging.
- Rotation: Use s1 and s2 when keys change on a planned schedule.
- Scope: Use prod or stage only when test mail has a separate sending domain or subdomain.
Selector names to avoid
- Secrets: Avoid API keys, private project names, and anything that looks confidential.
- People: Avoid names tied to employees, contractors, or teams that change ownership.
- Overload: Avoid one default selector for unrelated systems with separate key control.
A selector name is not a security boundary
A neat selector name helps operations, but the private key, signing system, DNS control, and DMARC policy decide whether the setup is resilient. Treat selector naming as inventory hygiene, not protection by itself.
DNS record examples
The DNS name is built by placing the selector before _domainkey, then the signing domain. The public key usually lives in a TXT record, although many hosted senders ask you to publish a CNAME that points to their managed key.
Provider named selectordns
google._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
Provider names are easy to recognize in headers. They are especially useful when one domain has multiple SaaS senders and a human needs to connect a failed DKIM result to the right admin console.
Rotation pair selectorsdns
s1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." ) s2._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." )
Rotation pairs keep old and new keys separate during a change. Publish the next selector first, move the signer to the new selector, then remove the old selector only after you no longer see signed mail referencing it.
Hosted sender CNAME selectordns
selector1._domainkey.example.com. 3600 IN CNAME dkim1.provider.net. selector2._domainkey.example.com. 3600 IN CNAME dkim2.provider.net.
Do not publish two DKIM TXT records at one selector
One selector should resolve to one DKIM key record. If two independent TXT records sit at the same selector name, receivers can fail DKIM because the result is ambiguous.
After publishing a selector, validate the exact selector and domain with the DKIM checker. This catches missing TXT records, invalid key tags, broken CNAME targets, and typo-prone selector names before you wait for aggregate reports.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Provider and sender examples
When a hosted sender gives you a selector, do not rename it for style. The selector is part of the contract between your DNS and that sender's signing service. Your naming standards apply when you control the signer, not when a provider has already generated the DNS target.
Google Admin Console DKIM setup screen showing a selector field.
Here are practical examples I would accept in production, grouped by sender type. These are patterns, not a license to guess a vendor's current setup. If a sender gives exact DNS values, publish those exact values.
|
|
|
|---|---|---|
Corporate mail | google, mx1 | Clear owner |
Microsoft-style | selector1, selector2 | Rotation pair |
Transactional | receipts, notify | Stream trace |
Marketing | news, k1 | Campaign owner |
Internal app | app1, alerts | Fast triage |
Selector examples by sender type.
A sender-specific selector also makes header review easier. If a failed message contains s=alerts, the operations path is clearer than a message signed with a generic s=default selector shared by several systems.
How selector names affect DMARC monitoring
DKIM selector names help troubleshooting, but DMARC does not pass because a selector name looks good. DMARC cares whether DKIM passes and whether the signing domain matches the visible From domain according to the DMARC domain match rules.
This is where monitoring matters. A clean selector plan tells you what each sender should use. DMARC monitoring tells you what senders actually used in production, which sources passed, which failed, and which sources need a DNS or signing change.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product is the best overall DMARC platform for this workflow because it connects the DNS layer to real mail flow. It monitors DMARC policy, SPF, DKIM, blocklist (blacklist) status, and deliverability signals in one place, then turns authentication failures into issue-specific steps. That is more useful than knowing that a selector exists while still guessing which system is sending broken mail.
For a one-off domain check, the domain health checker is the faster starting point. For ongoing operations, Suped adds real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, MSP multi-tenancy, and a practical path to policy enforcement.
Rotation examples and migration pattern
A good rotation pattern starts before a key change is urgent. The selector should make room for a second key, and the sending system should be able to switch selectors without changing the visible From domain.
Header after moving to the next selectortext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s2; h=from:to:subject:date; bh=...; b=...
- Publish: Add the new selector record, such as s2, before changing the signer.
- Switch: Update the sending system so new messages sign with the new selector.
- Watch: Review DMARC aggregate data and samples so old mail queues and delayed retries do not surprise you.
- Retire: Remove the old selector only after traffic referencing it has stopped.
If your current selector is default, the next selector does not need to be default2. It can be s2 or a provider-specific name, as long as the signer and DNS agree. If you need deeper background on key age and size choices, use the DKIM key rotation guidance in the DKIM cluster.
My default selector pattern
For systems I control, I usually start with s1 and reserve s2 for rotation. For systems owned by a provider, I keep the provider selector exactly as supplied.
The practical rule
Use selector names that an operator can understand six months later. s1 and s2 are the safest generic examples. google, selector1, and provider-issued tokens are right when a hosted sender requires them. billing, receipts, and alerts are useful when one domain has separate application mail streams.
The selector name should make the DNS record easier to manage, not more clever. Publish one valid key per selector, keep an inventory of which sender owns each selector, and use monitoring to verify that production mail matches the plan.
