The most reliable place to find a DKIM selector is the DKIM-Signature header of the message you are investigating. Read the s= value and pair it with the d= signing domain from that same signature.
The selector identifies where verification material is published. It does not identify the visible sender or prove that the signature passed. This guide follows the evidence from a received message to the correct DNS name, then explains what the lookup can and cannot establish.
Obtain the original received message
Use a controlled message sent through the actual service to a separate recipient. Preserve the original message as received there. A forwarded screenshot or a re-saved, edited message can omit or change evidence.
Locate every DKIM-Signature header. A message can contain more than one. For each signature, record its signing domain and selector separately, then correlate the trusted receiver's verification result.
- d: signing domain.
- s: selector.
- a: signing/hash algorithm.
- h: selected signed-header list.
- bh and b: body hash and signature values, not DNS public-key records.
These fields are defined by RFC 6376 §3.5.
Do not substitute the visible From domain for d= when building the key lookup. Alignment is a later comparison between the passing signing identity and the visible From identity.
Construct and query the verification name
Under RFC 6376 §3.6.2.1, the verification name combines the two values from the same signature:
<selector>._domainkey.<signing-domain>
In this synthetic example, the signature identifies:
The synthetic signature has d=example.com and s=mail2026.
The corresponding lookup is:
dig TXT mail2026._domainkey.example.com +noall +answer
If a provider delegates key management through a CNAME, inspect that chain as well:
dig CNAME mail2026._domainkey.example.com +noall +answer
These are illustrative DNS checks, not verification of a captured real message. Use the actual signature values. Under RFC 1034 §3.6.2, for a published alias, follow the intended target and establish that the verification data is available through the chain.
Public DNS contains the verification key material or the delegation leading to it. The private signing key belongs in the authorised signing system, not in a TXT record.
Interpret the lookup alongside verification results
A public-key answer shows that a resolver can retrieve particular verification material at that time. It does not prove that a message contains a signature, that the corresponding private key was used correctly or that signed content remained intact.
If the key exists but the signature fails, investigate the complete verification result. Content changes, malformed or incompatible key data, signature coverage, time-related conditions and DNS observations can require different remedies.
If no key is found, check the exact d= and s=, the authoritative zone, the CNAME target, key-retirement history and resolver errors. Do not publish a guessed selector simply to turn a checker green.
If the original has no relevant DKIM signature, a selector search cannot manufacture signing. Check whether the actual sender is configured to sign, whether the service supports the required identity and whether a later route changed the evidence.
Handle multiple signatures and key rotation
Make a separate row for each signature and its trusted result. A service's own passing signature may be unaligned, while a customer-domain signature passes alignment. Another message may have a failed customer-domain signature and only an unrelated passing one.
For rotation, check which selector the real message used, not merely which two records are available in DNS. Preserve the relationship between configuration state, signing cutover and messages already in transit. An old selector's retirement can affect later verification of saved or delayed messages.
For Microsoft 365, use the tenant-specific setup guide. For Workspace, use the selected-domain setup guide. Neither provider's common selector pattern should replace reading the actual evidence.
Confirm signing on the actual service
If a supplier says your domain has DKIM configured, ask it to show a message sent by the relevant workflow and the domain that actually signed it. A publicly visible key is one configuration dependency, not proof of live signing.
This matters when several tools use the same visible brand. Employee mail, support tickets and receipts may have different selectors, signing domains and owners. A successful check on one cannot stand in for the rest.
Keep track of signing ownership and delegation
Keep a selector inventory tied to service, domain, key-management model and business owner. Distinguish direct control of a key from delegation to a provider. Review the delegation when a service is offboarded.
Restrict private-key access and define the response to a suspected compromise. A valid public record is not proof that key custody is sound. Similarly, a valid signature establishes a domain-level assertion over covered content; it does not approve a payment request or rule out account compromise.
The useful evidence chain is message, signature identity, key lookup, trusted verification and alignment. Keep those observations together so the next reviewer can reproduce the diagnosis.
The practical takeaway
Keep the original message, signature identities, DNS observation and trusted receiver result together. That evidence distinguishes a missing key from an unsigned message, a failed signature or a signature that passes but does not align.
Apply the distinction
With two hypothetical signatures, d=example.com/s=mail2026 and d=service.example.net/s=outbound, query mail2026._domainkey.example.com and outbound._domainkey.service.example.net separately. Never combine mail2026 with the second d. Keep each lookup time and trusted result alongside its pair. A later missing key does not erase an earlier trusted receiver observation.