How Do I Find My DKIM Selector?
The DKIM selector is the s= value in a DKIM-Signature header. Pair it with the d= signing domain and query selector._domainkey.domain in DNS to find the public key.
DSDillon Intelligence
Direct answer
The most reliable way to find a DKIM selector is to inspect a message that was actually sent through the system you are testing. In the DKIM-Signature header, the s= tag is the selector and the d= tag is the signing domain. RFC 6376 defines the public-key lookup under selector._domainkey.signing-domain. Do not guess the selector from the provider name because organizations can use custom values and multiple selectors can exist.
DSDillon 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?
A DKIM selector is a label that tells the receiving mail server which public key to retrieve for a DKIM signature. It lets one domain operate more than one key at the same time, which is useful for key rotation, different sending platforms or separate mail systems.
The selector is not the DKIM key itself. It is part of the DNS lookup name used to find the public key that corresponds to the private key used by the sender.
Where do you see the selector in a real email?
Open the full headers or original source of a message sent through the system you want to test. Find the DKIM-Signature header and look for the s= value. Then find the d= value in the same signature. If the signature contains s=google and d=example.com, the corresponding DNS lookup is google._domainkey.example.com.
That method is stronger than guessing because it reflects the key the sending system actually used on that message.
Can a domain have more than one DKIM selector?
Yes. DKIM was designed so a domain can divide its signing namespace with selectors. A business may have one selector for employee mail, another for a marketing platform and another during key rotation. Multiple valid selectors are not automatically a problem.
The operational risk appears when nobody knows which sender uses which selector. Maintain a sender inventory so old keys can be retired deliberately instead of deleting a record that is still serving production mail.
How do you find the selector in Google Workspace?
Google Workspace lets administrators generate a DKIM record in the Admin console under Gmail authentication settings. Google's documentation says the default selector is google unless a different prefix is chosen. The generated DNS host name includes that selector before _domainkey.
If you are troubleshooting production mail, still confirm the selector in a received message. Administrative settings tell you what should be used; message headers tell you what was actually used.
What if there is no DKIM-Signature header?
Then that message was not DKIM-signed in a way visible to the receiver. Do not waste time querying random selector names. Determine which sending system produced the message and whether DKIM signing is enabled for that path.
A domain may have perfectly valid DKIM records in DNS while one application sends unsigned mail. That is why message-level testing matters.
What if the selector exists but DKIM still fails?
Check whether the public key resolves, whether the signing domain is correct, whether the sender is using the private key that matches the published public key, and whether an intermediary modified signed content in a way that invalidated the signature. The receiver's Authentication-Results header can help distinguish a missing key from a failed signature.
During key rotation, make sure the old key is not removed before all systems have stopped signing with it.
How should DKIM selectors be managed during rotation?
Use a new selector for the new key, publish the new public key, switch the sender to sign with the new private key, verify successful signatures in real received messages, and only then retire the old record after the old key is no longer in use. This creates an observable cutover instead of a blind replacement.
The exact timing depends on your sending infrastructure and DNS caching. Preserve enough overlap to verify production behavior.
Can the wrong selector cause mail to bounce or go to spam?
It can contribute to authentication failure. If the receiver cannot retrieve the public key for the selector or the signature does not validate, DKIM will not pass for that message. Whether the message is then accepted, rejected or filtered depends on the receiver's broader policy, DMARC result and reputation signals.
Do not describe DKIM failure as a guaranteed spam cause. Treat it as one piece of the receiving system's decision.
When should you ask for specialist help?
Escalate when several platforms sign for the same domain, when a migration or key rotation could interrupt production mail, when selectors are undocumented, or when DKIM passes inconsistently across different sending paths. The goal should be to map the actual signing architecture before editing DNS.
A strong review should leave you with a documented sender-to-selector map and a safe retirement plan for obsolete keys.
Can changing a DKIM selector break business email?
Yes, if the sender is still signing with a selector whose public key you removed or replaced incorrectly. Receiving servers will query the selector named in each message. If that DNS record no longer returns the matching key, DKIM verification can fail even though another selector on the domain is healthy.
Treat selector changes as production changes. Publish the new key, switch the sender, verify real received messages, and retire the old key only after the old selector is no longer being used.
What should you ask an email provider or developer about DKIM?
Ask which domain signs the message, which selector is used, where the private key is stored, who controls rotation, and whether every outbound path is covered. If the provider cannot tell you the expected d= and s= values, troubleshooting will be slower because nobody has defined the signing contract.
For a business with several systems, keep this information in an internal mail inventory so future migrations and incident response do not depend on memory.
Sources and verification
These references support the factual claims used in this guide. DSDillon separates published source material from observations that require investigation of an individual business.
Related DSDillon resources
Continue this investigation
DSDillon Email Deliverability & Authentication Remediation diagnoses the real sending path before changing DNS or production mail settings.
View remediation pricing