To find a DKIM key, start with a signed message. The selector is in the signature, and the signing domain tells you where to look. Guessing selector1 or default can return a valid but unused key, leaving the actual failing message unexplained.
DKIM verification connects selected message bytes to a public key published in DNS. Key publication, successful signing and successful verification are three different states. A useful investigation checks each rather than treating a DNS record as proof that outgoing mail is authenticated.
Read d and s from the message
In DKIM-Signature, d identifies the signing domain and s identifies the selector. Combine them to form the lookup name: selector._domainkey.signing-domain. Preserve the exact values from the message you are investigating.
DKIM-Signature: ... d=example.com; s=mail2026; ...
Key lookup: mail2026._domainkey.example.comThe DKIM key inspector reviews supplied key-record text. The email domain audit can query a selector you provide. Neither can know every selector a domain has ever used, because DNS does not offer a universal public list of those names.
A message may contain more than one DKIM signature. Record each signature separately, including its domain, selector and verification result. One failed signature does not necessarily mean no aligned signature passed. Conversely, a passing signature from an unrelated domain may not satisfy DMARC alignment.
Inspect the published record
A DKIM key record contains tagged information such as version, key type and public key material. The p value carries the public key data in the expected encoding. An empty p value has revocation meaning under DKIM rules; it is not an ordinary active key.
DNS provider interfaces can split long TXT values into quoted character strings. Properly returned strings form one logical value, while accidentally publishing multiple conflicting records is a different problem. Inspect the actual DNS response instead of relying only on how the control panel wraps text.
Check the key type and supported algorithm requirements against current provider guidance and applicable DKIM standards. Do not infer key strength from the number of visible characters in a screenshot. Parse the key representation with suitable tooling when you need its actual parameters.
| Stage | Evidence | Remaining question |
|---|---|---|
| Publication | DNS returns a valid key record | Does the sender use this selector? |
| Signing | Message contains DKIM-Signature | Does the signature verify? |
| Verification | Trusted receiver reports pass | Does the signing domain align with From? |
| Rotation | New messages use the new selector | Can delayed old messages still verify? |
| Retirement | Old signing has stopped | Has the planned verification overlap elapsed? |
Understand why message changes can break verification
DKIM signs selected headers and a canonicalised body. Canonicalisation defines how certain formatting differences are handled. It does not mean any content modification is acceptable. Adding a footer, changing a signed subject or rewriting body content can invalidate the relevant signature.
For a failed message, compare its route with a direct successful sample. A mailing list, security gateway or forwarding service may transform it after signing. Preserve the original message privately if you need exact verification; copying visible text into a new document loses important headers and byte structure.
The h tag lists signed header fields, and other signature parameters describe the algorithm and canonicalisation. Review them with a DKIM-aware verifier. A generic Base64 decoder can expose bytes but cannot decide whether the signature correctly covers the delivered message.
Diagnose a selector mismatch
Suppose a provider's control panel shows a valid key at mail2026._domainkey.example.com, but delivered messages still use s=mail2025. Query the old selector and inspect the provider's active signing configuration. Publishing the new key does not automatically switch every sender to it.
The organisation may have several provider accounts, regions or sending pools. One can rotate while another continues signing with the old selector. Send controlled messages through each actual workflow and record the selector from the delivered result.
If the old key was removed too soon, restore the correct verification record through the authorised provider process where appropriate, and complete the migration deliberately. Do not invent a replacement public key: it must correspond to the private key used for those signatures.
After the change, confirm a trusted receiver reports a valid signature using the new selector. Keep the old key available for the planned overlap while messages already signed with it can still be delivered or verified. The required overlap depends on your delivery and retention assumptions.
Rotate with separate publish, switch and retire steps
Generate or obtain a new key through the provider's supported process and publish its public record under a new selector. Verify authoritative DNS and allow for cached absence or earlier values. Keep private key handling inside the appropriate secure system; the DNS record contains only public material.
Switch signing to the new selector, then observe real messages. Do not retire the old public record merely because the new record exists. The switch is established by outgoing signatures and successful receiving results across all relevant senders.
Retire the old key after the documented overlap and after confirming old signing has stopped. Record selector names, dates, provider accounts and ownership. Using distinct selectors makes the transition easier to inspect than silently replacing key material under a name still used by cached or delayed messages.
Connect a passing signature to DMARC
DKIM itself can pass for a provider's signing domain. DMARC asks whether a passing signature's d domain aligns with the visible From domain under the configured mode. The selector does not determine alignment; it selects a key within the signing domain.
If mail signs with d=provider.example while From uses example.com, configure the provider's supported custom-domain signing feature. Adding a DKIM record under example.com is only part of that setup. The provider must use the corresponding domain and private key when signing.
Review multiple signatures without assuming the first one is decisive. A delivery can contain an aligned passing signature and an unrelated passing signature, or a failed old signature alongside a valid one. Preserve the receiver's per-signature evidence where available.
Separate key lookup failure from signature failure
A missing DNS key, a malformed key and a mismatched signature are different problems. DNS timeouts or validation failures add further possibilities. Keep the receiver's explanatory result and query the exact selector name before changing cryptographic settings.
Use the same signed message when reproducing a verification failure. Sending a new message can change the selector, timestamp, body and routing path. A fresh successful sample is useful evidence of current behaviour, but it does not explain why the earlier message failed.
For provider support, send the relevant headers and message identifier through the authorised channel. Do not post private signing keys, customer message bodies or unrelated recipient lists. Public key records are public, but the surrounding message can still contain sensitive information.
Keep DNS cache timing in the rotation record
Publish a new selector early enough for resolvers to stop retaining any earlier negative answer for that name. After switching, record the first delivered message using the new selector and its receiver result. Keep the old public key available according to the planned overlap. These timestamps help separate a transient lookup problem from a sender that never adopted the new configuration, especially when several provider accounts rotate at different times.
Frequently asked questions
Can I discover every selector from a domain name?
There is no standard public enumeration that reliably lists all selectors. Read selectors from real messages or the sending provider's configuration. Guessing common names can find stale or unrelated records and should not be treated as a complete DKIM audit.
Is the p value a private key?
No. It is public key material intended for publication in DNS. The matching private key remains with the signing system. Never paste a private signing key into a public DNS record or a diagnostic report; verification tools generally need public material and the message.
Why can a key exist while DKIM fails?
The sender may use another selector, the key may not match the signing private key, or the signed content may have changed. DNS retrieval can also fail at the receiver. Inspect the signature's exact domain and selector and the trusted receiver's error before deciding which layer to repair.
Does DKIM encrypt the message?
No. It provides a signature over selected message content. Recipients and intermediaries can still read ordinary unencrypted mail according to the transport and storage path. Confidentiality requires separate mechanisms; a valid DKIM signature does not hide the body or headers.
Can I remove the old key immediately after switching?
Delayed messages and other sending systems may still use it. Keep an overlap based on your delivery assumptions and confirm that all active senders switched. Removing the record too early can make otherwise intact old signatures unverifiable.
Does a valid signature guarantee the sender is trustworthy?
It connects the signed message to the domain's key under DKIM's rules. A malicious domain can sign mail correctly, and a legitimate account can be compromised. Evaluate alignment and the broader context separately instead of treating signature validity as a content-safety verdict.
What should I document after rotation?
Keep the old and new selector names, signing domains, publication and switch times, provider accounts and successful receiver results. Record when the old key can be retired and who owns that action. This prevents an incomplete rotation from becoming an unexplained failure later.