Find the DKIM selector from a real message's DKIM-Signature header, construct the correct DNS name, check TXT or CNAME records, and handle multiple signatures safely.
The fastest way to find a DKIM selector is to open the raw headers of a message sent by the system you are investigating and locate a DKIM-Signature field. The selector is the value after s=, while the signing domain is the value after d=. Together they form the DNS record name selector._domainkey.signing-domain. For example, s=mail2026 and d=example.com point to mail2026._domainkey.example.com.
What a DKIM selector is
DKIM lets a sender sign selected message headers and the message body with a private key. The receiver retrieves the corresponding public key from DNS. The selector is a label chosen by the signer so multiple keys can exist under one signing domain and keys can be rotated without replacing one permanent domain-wide record.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...
^ domain ^ selector
DNS owner name:
mail2026._domainkey.example.com
Possible DNS answer:
v=DKIM1; k=rsa; p=MIIBIjANBgkqh...The visible From domain is important for DMARC alignment, but it does not determine where the DKIM key is published. Always use d= from the signature when constructing the query. A third-party sender may sign with its own domain, your domain, or both.
Method 1: find the selector in a received message
- Send a fresh message through the exact provider, account, domain, and stream you need to inspect.
- Open the original or raw message source in the receiving mailbox. A forwarded copy or pasted body does not preserve trustworthy headers.
- Find every DKIM-Signature header. Long headers are folded across lines, so inspect the complete field.
- For each signature, record d= as the signing domain and s= as the selector. Also note a= for the algorithm and any identity or timestamp tags relevant to the investigation.
- Query selector._domainkey.d-domain in DNS and compare the result with the receiver's Authentication-Results header.
DKIM-Signature: v=1; d=example.com; s=transactional-2026; ...
DKIM-Signature: v=1; d=provider.example; s=region1; ...
transactional-2026._domainkey.example.com
region1._domainkey.provider.example
Evaluate each signature separately. DMARC cares whether a passing d= domain
aligns with the visible From domain.Method 2: use the sending provider's DNS instructions
Before a system can sign with your domain, its admin console normally generates one or more DNS records. Copy the host or name exactly. Some providers show only the relative host, such as mail2026._domainkey, because the DNS console automatically appends example.com. Others show the complete record name. Confirm the DNS interface's behavior so the domain is not accidentally duplicated.
- Google Workspace administrators generate a DKIM record in the Admin console, publish the generated host and value, then start authentication after DNS is available.
- Microsoft 365 commonly provides two CNAME records whose selector names map your domain to Microsoft-managed DKIM records.
- Email service providers may use a TXT public key, a CNAME to a managed key, or multiple records for regional routing and rotation.
- Treat the provider's current generated values as authoritative for setup. Do not copy another customer's selector or public key from a tutorial.
Method 3: check a known selector in DNS
dig TXT mail2026._domainkey.example.com
dig CNAME mail2026._domainkey.example.com
# Show the answer section compactly
dig +short TXT mail2026._domainkey.example.com
dig +short CNAME mail2026._domainkey.example.comA direct TXT response can contain a DKIM key record. A CNAME can delegate the name to a provider-managed target, which must then resolve correctly. Some DNS tools follow aliases automatically and some display only the CNAME; check both the alias and its target when diagnosing a failure.
Why DNS cannot list every DKIM selector
Normal DNS lookups require an owner name. They do not provide a public directory of every label beneath _domainkey. Unless zone transfer is deliberately exposed—which it generally should not be—you cannot ask DNS to enumerate all selectors. Guessing common names such as default, google, selector1, or selector2 may find a record, but it cannot prove which selector a current mail stream uses or that no other selectors exist.
A real DKIM-Signature headerShows the selector and signing domain used on that exact message.
Current provider-generated DNS instructionsShows what should be published before the first signed message exists.
A DNS lookup for a known owner nameShows whether that specific TXT or CNAME path resolves now.
A guessed-selector scannerCan discover common labels but cannot enumerate the DNS zone or identify the active stream reliably.
Selector, domain, and public key are different
selector mail2026
signing domain example.com
DNS owner mail2026._domainkey.example.com
record type TXT or CNAME
public key p= value reached through DNS
private key held by the signer and never published
From domain domain visible to the recipient; checked for DMARC alignmentThe selector itself is not secret and is not a password. The private key is sensitive and must stay with the signing system. Publishing a public key is the purpose of DKIM DNS. If a private key is exposed, stop using it, rotate to a new selector and key pair, update senders, verify new signatures, and retire or revoke the old record according to your operating plan.
Troubleshoot a selector that does not resolve
- Rebuild the owner from the message's exact s= and d= values. Do not substitute the From or Return-Path domain.
- Check whether the DNS console appended the zone twice or interpreted a fully qualified name as a relative label.
- Query authoritative DNS as well as a public recursive resolver to distinguish publication from cache or delegation problems.
- If the owner is a CNAME, verify the target exists, the chain is valid, and no conflicting TXT record is published at the same owner.
- Allow for the record's TTL and negative caching after a previously missing lookup, but do not use propagation as a permanent explanation.
- Confirm the message is recent. An old message may reference a selector retired after key rotation.
Troubleshoot a selector that resolves but DKIM fails
Resolution only proves DNS returned something. Check the receiver's Authentication-Results for the exact signature and reason. Failures can come from a malformed key record, a mismatch between public and private keys, unsupported or invalid algorithms, canonicalization damage, modified signed headers or body content, an expired signature, or an intermediary that changed the message after signing.
A passing DKIM signature can still fail DMARC alignment if d= is unrelated to the visible From domain. Conversely, one signature can fail while another aligned signature passes. Report the result per signature before reducing it to an overall authentication conclusion.
Frequently asked questions
Is the DKIM selector always default?
No. “default” is merely one possible label. Providers choose labels such as selector1, selector2, product names, regions, or rotation dates. Read s= from a current message or use the provider's generated setup instructions.
Can I find a DKIM selector from an email address alone?
Not reliably. The address does not reveal which system will send, which d= domain that system will sign with, or which selector it will choose. Obtain a sent message or access the sending provider's domain-authentication settings.
Can two providers use different selectors on the same domain?
Yes, and they should use distinct keys and selectors. This isolates rotation and compromise, avoids one provider overwriting another's record, and makes header evidence easier to attribute.
What does an empty p= value mean?
RFC 6376 defines an empty p= value as a revoked public key. A signer should no longer produce signatures using that selector. Investigate why any current message still references it.