A list of the most common DKIM selectors and how to use them
Published 11 Jul 2025
Updated 21 May 2026
11 min read
Summarize with
The most common DKIM selectors are selector1, selector2, google, k1, s1, s2, default, dkim, mail, email, mandrill, and smtpapi. A DKIM selector is the label that tells receivers where to find a sender's DKIM public key in DNS. The full lookup normally follows this pattern: selector dot _domainkey dot domain.
I treat selector names as hints, not proof. A selector can be anything the sender chooses, so a domain can use google without using Google, or selector1 without using Microsoft. The reliable workflow is simple: read the selector from the DKIM-Signature header, query the matching DNS name, confirm the key exists, and check whether that DKIM result matches DMARC requirements.
Common DKIM selectors by provider
This is the practical list I check first when I am looking at a domain and I do not yet have the message headers. It is not a complete internet-wide inventory because DKIM selectors are not published in a directory. They are discovered through headers, provider setup screens, DNS records, and old operational notes. A useful selector list gets you moving, but it does not replace reading the signed message.
|
|
|
|---|---|---|
selector1 |  Microsoft 365 | Check the CNAME target and enable signing. |
selector2 | Microsoft 365 | Keep it ready for rotation and fallback. |
google |  Google Workspace | Publish the TXT key from Admin console. |
default | Generic mail systems | Use only when one signer owns mail. |
dkim | Generic SaaS senders | Verify the provider's exact DNS target. |
k1 | Marketing platforms | Common short rotation selector. |
s1 | Bulk email platforms | Often paired with s2. |
s2 | Bulk email platforms | Useful for planned key rotation. |
mandrill | Mandrill | Check legacy transactional mail. |
smtpapi | SendGrid | Seen on older integrations. |
Common selector patterns and where they are often seen.
For day-to-day troubleshooting, the selector itself matters less than the source that signs with it. The same domain can have one selector for employee mail, another for invoices, another for password resets, and another for a newsletter sender. That is normal. The risk starts when nobody knows which selectors are still active, which keys are stale, and which senders authenticate but fail the DMARC domain match.
Fast selector rule
Use common selectors to start the investigation, then switch to message headers and DMARC data. Guessing selectors from DNS alone misses senders that are not currently mailing you and keys that exist but are no longer used.
Google Admin console DKIM settings showing a selector and DNS record instructions.
How selectors work in DNS
A DKIM selector is stored in the s= tag inside the DKIM signature. If a message is signed with s=google and d=example.com, the receiver checks the public key at google._domainkey.example.com. If that DNS record has the right public key and the message body and signed headers have not changed, DKIM passes.
Example DKIM TXT recordDNS
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Some providers ask for a TXT record, while others ask for a CNAME that points to a provider-controlled host. Both are valid. A TXT record puts the public key directly in your DNS zone. A CNAME delegates the selector lookup to the provider, which lets the provider rotate keys without asking you to edit the public key each time.
TXT selector
- Control: You publish the public key in your DNS zone.
- Rotation: You update DNS when the key changes.
- Risk: Long values can be pasted incorrectly.
CNAME selector
- Control: The provider hosts the public key target.
- Rotation: The provider can rotate behind the alias.
- Risk: A broken target breaks DKIM for that sender.
The important part is that the DNS owner and the sending platform agree on the exact selector name. Google commonly uses google. Microsoft 365 commonly uses selector1 and selector2. A custom application can use billing2026 if that is what your signer writes into the header.
Google commonly uses google. Microsoft 365 commonly uses selector1 and selector2. A custom application can use billing2026 if that is what your signer writes into the header.How to find the selector from an email
The most accurate way to find a DKIM selector is to open the raw message headers and inspect the DKIM-Signature field. I normally look for two tags: s= for selector and d= for signing domain. You need both. A selector without the signing domain is not enough because the same selector can exist under many domains.
Selector inside a DKIM-Signature headertext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; h=from:to:subject:date; bh=abc123...; b=def456...
- Open headers: Use the raw message view in the receiving mailbox.
- Find signature: Search for DKIM-Signature.
- Read tags: Copy the selector from s= and the domain from d=.
- Query DNS: Look up selector dot _domainkey dot signing domain.
- Confirm result: Check that DKIM passes and matches the visible From domain.
If you do not have a message yet, the fastest next step is to send a test email through the sender you are configuring. After it arrives, inspect the result with a focused DKIM checker so you can see the selector, the public key record, and the validation result in one place.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
This matters when the domain has multiple signatures. For example, a message can carry one DKIM signature from the sending platform and another from an outbound security gateway. The receiver can pass DKIM if at least one valid signature exists, but DMARC cares about the match with the visible From domain. That is why I always read the signing domain and selector together.
How to use common selectors during setup
Common selectors help most during setup and audits. They give you a shortlist of likely DNS names to check, and they help you recognize which provider signed a real message. They should not become a naming policy by themselves. A good selector name should be stable enough for operations, specific enough to avoid confusion, and easy to rotate when you replace a key.
Flowchart showing the DKIM selector setup path.
For a new sender, I do not try to invent the selector first. I start in the sender's authentication screen because the platform often generates the exact selector and DNS target. Then I publish what the platform expects. If I control the signer, such as a self-hosted mail server or custom MTA, I choose a selector with a purpose and a date or sequence.
|
|
|
|---|---|---|
mta1 | One mail host | Clear, but tied to host naming. |
k2026a | Key rotation | Easy to track by year. |
billing | App mail | Useful when app ownership is stable. |
s1 | Simple rotation | Short, but less descriptive. |
Selector names that work well for owned infrastructure.
Do not reuse one private key everywhere
A shared selector and private key across unrelated systems creates avoidable blast radius. If one system leaks the private key, every sender using that key has to rotate at the same time. Separate selectors by provider or sending system.
A selector record can exist before the first message is sent. That is fine. What you should avoid is leaving old selectors active forever after the matching private key is retired. Old public keys do not sign new mail by themselves, but stale records make audits harder and increase confusion when investigating authentication failures.
How to test selectors and catch failures
A selector test has two layers. First, check DNS: does the selector record exist, and does it contain a valid DKIM public key or a valid CNAME target? Second, check a real message: did the sender actually sign with that selector, and did the receiving system validate the signature?
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Suped's DKIM checker view is useful for the first layer because it shows the selector, the DNS record, parsed DKIM parameters, and validation checks. For the second layer, Suped's DMARC monitoring ties those authentication results to actual sending sources, so you can see whether a selector is only present in DNS or actively used in production mail.
- Missing record: The selector in the header points to a DNS name that returns no DKIM key.
- Wrong target: A CNAME points to the wrong provider host or has not propagated.
- Bad key: The public key is truncated, wrapped incorrectly, or pasted with extra characters.
- Wrong domain: The message signs with a domain that does not match the visible From domain.
- Body change: A downstream system modifies content after signing, invalidating the DKIM signature.
When I audit a domain, I pair DKIM selector checks with a broader domain health check. That catches related issues such as SPF lookup problems, missing DMARC reporting, weak DMARC policy, and DNS mistakes that do not appear when you look at only one selector.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The biggest operational mistake is treating a green DNS check as the finish line. A valid selector record only proves that a DNS name exists. It does not prove the sender uses it, that the signature survives transit, or that DMARC passes. Production DMARC reports answer those questions at scale.
Selector naming and rotation practices
Selector names should support rotation. I prefer pairs or dated sequences because they make it obvious which key is current and which key is next. For example, s1 and s2 work well for alternating keys. A dated pair such as k2026a and k2026b makes audit history clearer.
Selector rotation readiness
A simple way to judge whether a DKIM selector setup is easy to rotate.
Good
Separate keys
Each sender has its own selector and documented owner.
Watch
Shared key
Several senders share a selector but owners are known.
Fix
Unknown owner
One selector is reused widely and no owner is listed.
A clean rotation usually follows a two-selector pattern. Publish the new public key under a new selector, configure the signer to use the new selector, send test mail, monitor real DMARC results, then remove the old DNS record after the old signature has aged out of mail queues and logs. This avoids breaking in-flight mail and gives you a rollback path.
Two-selector rotation exampleDNS
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=OLDKEY..." s2._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=NEWKEY..."
The right DKIM key length depends on your DNS provider, sender support, and operational tolerance. Most teams use 2048-bit RSA keys because they have strong support and fit common DNS behavior. Larger keys need more care because DNS TXT splitting and provider limits can create errors. For a deeper key-size discussion, see recommended key length.
A practical selector policy
- Per sender: Give each platform or mail stream its own selector when you control the key.
- Document owner: Record who owns the signer and where the private key lives.
- Use pairs: Keep a next selector ready for rotation.
- Monitor reports: Confirm real mail passes DKIM and matches DMARC.
How this connects to DMARC monitoring
DKIM selectors are a setup detail. DMARC monitoring turns them into operational evidence. A domain with ten selectors can be healthy if each selector maps to an approved sender and passes the DMARC domain match. A domain with two selectors can be risky if one is attached to an unknown sender or a stale platform still sending mail.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped is built for that workflow: monitor DMARC policy, identify verified and unverified sources, surface DKIM and SPF issues, and give concrete steps to fix authentication failures. For teams managing many domains, Suped also adds MSP and multi-tenancy views, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, real-time alerts, and blocklist monitoring.
The practical value is that you can stop treating DKIM as a one-off DNS ticket. With DMARC monitoring, selector problems show up next to the sending source, volume, pass rate, and policy impact. That makes it easier to decide whether a failure is harmless testing, a misconfigured vendor, or a sender that should be blocked by policy.
Selector-only check
- Scope: Confirms one DNS record at one moment.
- Blind spot: Does not show real sending volume.
- Best use: Setup validation and focused troubleshooting.
DMARC monitoring
- Scope: Shows real authentication across sources.
- Blind spot: Needs reporting data to build history.
- Best use: Ongoing protection and policy rollout.
What to do next
Start with the common selector list, but do not stop there. The exact selector for a real message comes from the DKIM-Signature header. The exact operational risk comes from whether that signature passes, whether it matches DMARC, and whether the sending source is approved.
For a small setup, publish the selector your provider gives you, send a test message, and verify the header. For a larger setup, keep an inventory of selectors, owners, sending sources, key ages, and rotation status. Suped makes that easier by combining DMARC, SPF, DKIM, hosted authentication records, alerts, and deliverability signals in one workflow.
- First step: Find s= and d= in a real message header.
- Second step: Query selector dot _domainkey dot signing domain.
- Third step: Confirm DKIM pass and DMARC domain match.
- Fourth step: Document ownership and plan key rotation.
