How Do I Find My DKIM Selector?
A DKIM selector is the s= value used with the d= signing domain to locate a DKIM public key. This guide explains how to find selectors from real message headers, resolve the correct DNS record, handle multiple selectors and rotations, troubleshoot failures, and avoid breaking production email during migrations.
DayneDillon Intelligence
Direct answer
The most reliable way to find a DKIM selector is to inspect a real message sent through the exact production system you want to verify. In the DKIM-Signature header, the `s=` tag is the selector and the `d=` tag is the signing domain. RFC 6376 defines the selector as the value that subdivides the signing domain's DKIM namespace. The receiver normally uses those values to query a DNS name such as `selector._domainkey.signing-domain`. Do not guess selectors from common names. A domain can have multiple active selectors for different providers or key rotations, and the selector that matters is the one actually used on the message.
DayneDillon traces the DKIM s= selector and d= signing domain from production messages and verifies the matching DNS key before changes are made.
Review email authenticationWhat is a DKIM selector in plain English?
DKIM uses public-key cryptography to let a receiving mail system verify that a message was signed by a domain and that the signed parts of the message were not altered in transit. The private key stays with the sending system. The matching public key is published in DNS.
The selector is simply a label that tells the receiver which public key to retrieve for a particular signature. RFC 6376 makes the s= selector a required part of the DKIM signature. The signing domain appears in d=. Together they identify the key namespace.
Think of the domain as a building and the selector as the room number. Knowing only the building is not enough when several keys can exist at once.
Where do you see the selector in a real email?
Open the message's full source or original headers and locate `DKIM-Signature:`. A typical signature contains many tags. You are looking for `d=example.com` and `s=selectorname`. The exact order of the tags can vary.
If several DKIM-Signature headers exist, the message has multiple signatures. That can happen when a platform signs with its own domain and the customer's domain, or when mail passes through another service that adds a signature. You need to identify which signature belongs to the domain and sending path you are investigating.
- Record the full visible From address.
- Record the `d=` signing domain.
- Record the `s=` selector.
- Check the receiver's Authentication-Results for DKIM=pass/fail.
- Check whether the aligned signature is the one DMARC relies on.
How the selector becomes a DNS query
The normal DKIM public-key name uses the selector under `_domainkey` for the signing domain. If the signature has `s=mail2026` and `d=example.com`, the lookup is typically `mail2026._domainkey.example.com`.
Some providers publish the public key directly as TXT. Others instruct the customer to create a CNAME that points to provider-managed DNS. Both models can work. Follow the actual DNS chain and confirm the final key is present and accessible.
The existence of that record proves only that a public key is published. It does not prove the sending server has the matching private key or that it is currently using the selector.
Why guessing selectors is unreliable
Common names such as `default`, `google`, `selector1`, `selector2`, `s1` and `s2` appear in many environments, but DKIM does not define a universal default selector. A DNS tool that probes a list of popular names may find nothing even while DKIM is working perfectly with a custom selector.
Conversely, a guessed selector can resolve to an old key that is no longer used. Finding a TXT record is therefore weaker evidence than reading the selector from an actual signed message.
Can one domain have several DKIM selectors?
Yes. Multiple selectors are a normal design feature. A business may have one selector for employee email, another for a CRM, another for a transactional platform and temporary old/new selectors during key rotation.
This lets platforms hold separate private keys and lets an organization rotate one key without replacing every sender at once. It also means an audit has to map selectors to sending systems rather than asking for 'the DKIM selector' as though only one can exist.
How to find the selector in Google Workspace or another provider
When a provider offers domain DKIM configuration, its admin console normally shows the DNS name or selector it expects. Use that as configuration evidence, then verify it with a real sent message. Administrative settings can be stale or a domain may have several sending platforms.
Do not assume that mail using Gmail's interface necessarily signs only with the customer's domain. Verify the actual message. The same rule applies to Microsoft 365, marketing systems, CRMs and self-hosted servers.
What if there is no DKIM-Signature header?
First confirm that the copy you are inspecting came from the sender you intended and that no intermediary stripped headers. If the production message truly has no DKIM signature, the sending system may not have DKIM enabled for that domain or may be using a path that was never configured.
Gmail's current sender guidelines require at least SPF or DKIM for all senders to personal Gmail accounts and both SPF and DKIM for senders above its high-volume threshold. Google recommends using SPF, DKIM and DMARC broadly. Missing DKIM is therefore worth investigating even if SPF currently passes.
What if the selector resolves but DKIM still fails?
Several layers can be wrong. The sender may be signing with a private key that does not match the published public key. The signature may be malformed. The message may be modified after signing. The DNS record may be truncated or syntactically invalid. The receiver may be querying a different signing domain from the one you assumed.
Compare the exact d= and s= values from the message with the DNS record and the sending platform's active key. If a gateway modifies signed headers or the message body, determine whether the selected canonicalization and signed fields tolerate the modification.
What does a revoked DKIM key look like?
RFC 6376 allows a DKIM key record to revoke a key by publishing an empty `p=` value. A verifier encountering a selector whose key has been revoked should fail verification. That is different from simply deleting a DNS record, which can produce a missing-key condition.
Do not reuse a revoked selector without understanding the implications. Key lifecycle should be deliberate and documented.
How long should an old selector remain after rotation?
There is no single universal duration because message queues and retry windows vary. The principle is to publish the new key before the sending switch, confirm messages are signed with the new selector, and leave the old public key available long enough that legitimate messages signed before the switch can still be verified if they are delayed.
Removing the old selector immediately after changing the sender can cause in-flight messages to fail verification. The safer sequence is publish → validate DNS → switch signing → verify real messages → observe → retire old key.
Why selector rotation improves security
DKIM private keys are credentials. Rotating keys limits the period during which one compromised key can be useful and lets organizations replace weaker or old cryptographic material. Providers may have their own rotation schedules and capabilities.
Gmail requires DKIM keys of at least 1024 bits for mail sent to personal Gmail accounts and recommends 2048 bits where supported. If an older environment is still using a weak key, a controlled rotation can improve both security posture and standards compliance.
Can changing a selector break business email?
It can break authentication even if mail continues to leave the server. If DNS is published incorrectly, the sender switches before DNS is ready, or the wrong private/public key pair is used, receivers can see DKIM failures. If DMARC relies on aligned DKIM, those failures can become DMARC failures.
That is why a production change should be tested with real messages after the switch. A successful DNS query is not enough.
What if the business migrated email providers?
Migrations frequently leave old selectors in DNS. That is not automatically harmful, but it can create confusion during troubleshooting. Map which platform currently sends each message stream and which selectors are still active.
Do not delete legacy selectors merely because they look old. First prove that no legitimate delayed, fallback or still-connected system signs with them. Once the sending inventory is authoritative, stale selectors can be retired according to the provider's guidance.
How to check a selector from the command line
If you know the selector and signing domain, a DNS query such as `dig TXT selector._domainkey.example.com` can show a TXT key. If the result is a CNAME, follow the target. `nslookup -type=TXT` or `host -t TXT` can serve a similar purpose on systems without dig.
The command verifies DNS visibility, not cryptographic validity of a message. Pair it with the receiver's Authentication-Results and the actual DKIM-Signature header.
What should you ask an email provider or developer?
Ask for the exact sending domain, DKIM signing domain, active selector, key length, rotation process and whether the provider signs every message stream that uses your From domain. Also ask how the provider handles subdomains, custom bounce domains and DMARC alignment.
- What `d=` domain should I expect on a real message?
- What `s=` selector is active right now?
- Is the key published as TXT or CNAME?
- What key length is in use?
- How is rotation performed?
- Will old selectors remain valid during cutover?
- Does every sending product use the same selector?
- What happens if I send from a subdomain?
When should a business get specialist help?
Specialist review is justified when several providers send for the domain, DMARC is failing, production mail is being rejected, the active selector is unclear, or the business plans to tighten DMARC enforcement. The risk is not that finding a selector is difficult; the risk is changing a live authentication environment without mapping dependencies.
DayneDillon's published Email Deliverability & Authentication Remediation starts at $1,500 and is designed around mapping the actual sending environment rather than editing isolated DNS records.
Frequently asked: can I discover every selector from DNS?
Not reliably. DNS is not required to expose an index of all selector names. Unless you know or guess the name, you may not find it. The message itself or the sender's configuration is the authoritative starting point.
Frequently asked: does a DKIM selector need to match the email provider's name?
No. The selector is an administrator/provider-chosen label within the signing domain's DKIM namespace. Its name does not determine deliverability or alignment; the signature, key and domain relationship do.
How selector mistakes happen in multi-provider environments
A business often starts with one mailbox provider and gradually adds other systems. Years later it may have employee mail, invoicing, website notifications, a CRM and a campaign platform all signing independently. The DNS zone can accumulate selectors whose names no longer reveal what system uses them.
Create a selector inventory with columns for selector, d= domain, DNS record type, provider, message stream, key length, first observed date and current status. Build it from real messages and provider configuration rather than from DNS names alone. That inventory becomes especially valuable before a migration or DMARC enforcement change.
What to do when the DKIM record is a CNAME
Some services do not ask customers to publish the public key directly. Instead, the customer publishes a CNAME under the selector that points to a hostname controlled by the provider. The provider can then manage the underlying key without asking the customer to replace a long TXT value each time.
When troubleshooting, confirm both levels: the customer's selector name resolves to the expected CNAME and the target resolves correctly. A broken CNAME, missing target or accidental proxying at a DNS/CDN provider can interrupt verification.
How DNS propagation affects selector changes
A selector change is a DNS change and is therefore affected by TTLs, resolver caching and provider propagation. Publishing the new record before switching the sender gives resolvers time to see the key. Switching first can create a period where receivers encounter signatures for a selector they cannot yet resolve.
Record the previous TTL before a planned migration. If you control the zone and have adequate lead time, a lower TTL can make cutover more responsive, but it should not be changed at the last minute with the assumption that all existing caches will immediately forget the old value.
How to validate that DKIM really passes after a change
Send a new message through each affected production path to controlled recipient accounts. Inspect the full headers at the receiver, confirm the expected new s= selector and d= domain, and read the receiver's DKIM and DMARC results. This is stronger evidence than seeing the selector in DNS.
Repeat for transactional or marketing platforms separately. A test from an employee mailbox does not prove the website's SMTP library or CRM was updated.
Selector security is also access-control security
The public selector record is safe to expose; it contains or points to the public key. The private DKIM key is sensitive and should remain on the authorized sending system. If the private key is exposed, rotate it rather than trying to hide the public DNS record.
Limit who can change DNS and provider signing settings, keep an audit trail of rotations and remove access for former administrators. Authentication reliability depends as much on operational control as on the cryptography itself.
How selector problems affect DMARC alignment
A DKIM signature can pass cryptographically and still fail to contribute to DMARC if the d= domain does not align with the visible From domain. Finding the selector is therefore only half the job. Always record the signing domain along with it.
If a vendor signs only with its own unrelated domain, the business may need the provider's custom DKIM feature so the vendor can sign with an aligned business domain. The exact setup is provider-specific and should be verified with the provider's current documentation.
A selector troubleshooting checklist
If those ten points are documented, most selector confusion disappears. What remains is usually a key mismatch, provider configuration problem or message modification issue rather than a mystery DNS value.
- Capture a real production message.
- Find every DKIM-Signature header.
- Record each d= and s= pair.
- Query the exact selector._domainkey.signing-domain.
- Follow CNAMEs if used.
- Check for an empty/revoked p= value.
- Confirm receiver reports DKIM=pass.
- Confirm the passing d= domain aligns for DMARC.
- Repeat for each sending platform.
- Document selector ownership before deleting or rotating anything.
Sources and verification
These references support the factual claims used in this guide. DayneDillon separates published source material from observations that require investigation of an individual business.
Related DayneDillon resources
Continue this investigation
DayneDillon Email Deliverability & Authentication Remediation diagnoses the real sending path before changing DNS or production mail settings.
View remediation pricing