Deliverability · Practical guide
DKIM selector not found: query the name in the actual signature
Diagnose a missing DKIM key using the message’s selector and signing domain rather than guessing a provider’s default selector.
Reviewed · Examples are illustrative
Who this helps: Operators diagnosing authentication, receiving-policy and delivery failures.
Define the decision
The DNS name comes from s= and d= in the received DKIM-Signature. A valid key under another selector does not help that message. Multiple services can use different selectors for the same domain.
Work through the procedure
- Copy s= and d= from a fresh failing message.
- Query s._domainkey.d and follow any provider CNAME.
- Compare the authoritative DNS answer with the provider’s exact required record.
- Correct duplicate domain suffixes, missing records or stale signing configuration, then generate a new test.
Worked example
The following is a synthetic example for this procedure, not a customer result or performance benchmark.
Message: s=outreach2; d=example.com
Query: outreach2._domainkey.example.com
Found instead: outreach2._domainkey.example.com.example.com
Fix target: DNS editor name, followed by a fresh signed messageRead the result
A missing key and a malformed key are different problems. If DNS returns a value, inspect its type and contents before deciding the selector is absent. Keep old test messages out of the final verification sample.
Check before moving on
- Check which service generated the message.
- Follow the complete CNAME chain to the key record.
Limits and next action
Do not delete other selectors just because this one fails. They may still serve legitimate mail or signatures on messages in transit.
Source references
Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.
Related guides
- DKIM: signed message evidence and the signing domain →
- Set up DKIM and verify the signature actually being used →