You cannot reliably find a DKIM record for any random domain without the selector. DKIM public keys live at a selector-specific DNS name, so the selector is part of the address, not optional metadata. The DNS name is built as selector._domainkey.domain. Without the selector, you do not know which DNS name to query.
The practical answer is: get a signed email, read the s= value from the DKIM-Signature header, read the d= signing domain from the same header, then query the DNS TXT record at that combined name. If you cannot get an email sample, your options are limited to provider access, DMARC reports, MX-based inference, and educated selector guesses.
Best path: Use a real message header and query the exact selector and signing domain.
Fallback path: Try known selectors only after checking the sender, MX records, and DMARC data.
Common mistake: Entering s or s= as the selector looks up the wrong DNS name.
Why DKIM needs a selector
A domain can publish more than one DKIM key at the same time. The selector tells the receiver which key to use for a specific signature. That is why DKIM does not use one fixed TXT record at the root domain. Each selector has its own DNS name under _domainkey.
How a DKIM header maps to DNSdns
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
DNS TXT name:
selector1._domainkey.example.com
In that example, selector1 is not a tag name. It is the selector value. The lookup tool does not want s= or s=selector1. It wants the value only, such as selector1, plus the signing domain.
There is no normal DKIM directory
DNS does not provide a standard way to ask for every DKIM selector under a domain. A lookup must name the exact record. That design lets a sender rotate keys, run separate keys for separate mail streams, and remove old keys without exposing a simple selector inventory.
How to find the selector from a real email
When I have a real email, I start with the raw headers. Do not use the visible From address alone. DKIM uses the signing domain inside the DKIM-Signature header, and that domain can differ from the visible From domain.
Flowchart showing DKIM selector discovery from message header to DNS TXT lookup.
Without a message header, you are not doing a true lookup. You are trying to discover or infer the selector. That difference matters because a failed guess does not prove DKIM is missing. It only proves that one guessed selector did not return a key.
I usually work through a short candidate list, then stop once the evidence gets weak. A list of common DKIM selectors helps, but it is still guessing unless you have sender-side evidence.
Methods that work
Header evidence: A raw message gives the exact selector and signing domain.
Sender access: An admin console or DNS setup page often shows the required selector.
DMARC data: Aggregate reports can expose selectors used by live mail streams.
Methods that mislead
Blind scanning: A domain can have selectors you did not guess.
Wrong domain: Checking the visible From domain fails when DKIM signs another domain.
Literal tag use: Putting s= into a selector field creates a bad query.
Candidate
Common use
Confidence
selector1
Workspace mail
Medium
selector2
Key rotation
Medium
google
Workspace mail
Medium
default
Hosted mail
Low
k1
Bulk sender
Low
Common selector guesses are useful only as candidates, not proof.
Run the lookup once you have a candidate
Once you have a selector candidate, test it directly. Suped's DKIM checker takes the selector and domain, then shows whether the DNS record exists, whether the public key parses, and which parameters are present.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A valid DKIM DNS response usually starts with v=DKIM1 and includes a public key in the p= tag. Some senders publish a CNAME at the selector name, then point to a provider-hosted TXT record. That is normal. Follow the chain and validate the final TXT record.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Example DKIM TXT recorddns
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa;"
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
A found key is not the same as passing DKIM
A DNS record can exist while messages still fail DKIM. The sender must sign the email, the signature must survive forwarding and content changes, and the signing domain must be the domain you care about for DMARC alignment.
Use DMARC data to discover selectors over time
For a domain you own or manage, DMARC aggregate reports are a better long-term answer than selector guessing. Receivers can report the DKIM signing domain, selector, result, and source IP for real mail they processed. That turns selector discovery into evidence gathered from actual traffic.
Suped's DMARC monitoring parses those reports, groups mail by source, and highlights authentication failures with steps to fix. That is where Suped becomes the stronger practical choice for most teams: one-off DKIM lookup is useful, but ongoing DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, alerts, and blocklist (blacklist) visibility need a unified workflow.
Confidence by selector source
Use stronger evidence first, then move to weaker candidate testing.
Message header
100%
Sender admin
90%
DMARC reports
80%
MX inference
50%
Selector guessing
30%
For a broader check, run a domain health checker scan after you confirm the DKIM selector. I use that after the narrow DKIM lookup because domain authentication rarely breaks in isolation. SPF limits, DMARC policy, DNS syntax, and DKIM records often affect the same sending source.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
Common failure cases
Most failed DKIM lookups come down to one of a few mistakes. The key is to separate DNS existence from signing behavior. DNS answers whether a selector record exists. Message headers answer whether the email was signed with that selector.
Symptom
Likely cause
Next check
No record
Wrong selector
Read header
No record
Wrong domain
Use d=
CNAME only
Hosted key
Follow CNAME
Key found
No signature
Check sender
Permerror
Bad key
Validate syntax
Use the symptom to decide the next check.
Do not conclude DKIM is missing too early
Wrong selector: A failed guess does not prove the sender has no DKIM key.
Wrong domain: The lookup must use the signing domain, not always the visible From domain.
Wrong conclusion: A found key does not prove current mail is signed or aligned.
A practical guessing workflow
When guessing is the only route, keep it structured. I start with selectors that match the sending system, then test common values, then stop. Endless selector probing wastes time because there is no guarantee the selector follows a common pattern.
Find senders: Check MX records, known sending sources, and any admin access you have.
Create candidates: Test provider-like selectors, recent key names, and common defaults.
Validate records: Confirm the DNS answer is a DKIM TXT record or a CNAME that resolves to one.
Confirm with mail: Send or request a message when you need proof of current signing.
If several records exist, do not assume all are active. Old selectors often stay published during key rotation or after a sender migration. The active selector is the one used in a current DKIM-Signature header.
Views from the trenches
Best practices
Read the DKIM-Signature header first, then query the selector and signing domain.
Use DMARC reports for domains you manage, since live traffic can reveal selectors.
Treat guessed selectors as candidates only, then confirm with a current signed message.
Common pitfalls
Entering s= as the selector creates the wrong DNS query and leads to false errors.
Checking the From domain fails when the DKIM d= domain belongs to another sender.
Assuming a missing guessed record means DKIM is absent creates false diagnostics.
Expert tips
Build selector candidates from sender evidence before trying generic selector names.
Follow CNAME chains because many senders host the final DKIM key on another domain.
Keep old and new selectors during key rotation until current mail proves the change.
Marketer from Email Geeks says the selector and signing domain are both required because together they form the DKIM DNS name.
2021-07-27 - Email Geeks
Marketer from Email Geeks says the DKIM-Signature header is the cleanest source because the selector appears in the s= tag.
2021-07-27 - Email Geeks
The practical answer
To find a DKIM record, you need the selector. The reliable route is to read s= and d= from a real DKIM-Signature header, then query selector._domainkey.domain. Without a header or sender access, you are limited to educated guesses and DMARC-derived evidence.
For one-off testing, a focused DKIM lookup is enough. For owned domains and client domains, Suped's product gives the more useful operating view: it combines DKIM record checks, DMARC monitoring, SPF visibility, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist (blacklist) monitoring so selector issues are tied back to real mail flow and clear fix steps.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
