A DKIM no-key diagnostic generally means the verifier could not find the required verification key for a signature. The useful starting point is the message's actual selector and signing domain. Guessing a common selector or querying the visible From domain can lead to a perfectly accurate answer to the wrong DNS question.
Preserve the original received message and its trusted authentication result. Record the observation time, because the key may have changed since delivery. Then investigate the exact signature named in the result; messages can carry several signatures with different lookup names and outcomes.
Derive the exact DNS question
Read s and d from DKIM-Signature. With s=campaign7 and d=mailer.example, the lookup is campaign7._domainkey.mailer.example. The selector is not a universal provider name, and the signing domain need not be the same as the visible From domain. RFC 6376 §3.1, RFC 6376 §3.5 and RFC 6376 §3.6.2.1 define these elements.
Query the name and record type expected by the supported configuration. Under RFC 1034 §3.6.2, if the service uses a CNAME, follow it to the verification data and capture the intermediate target. Check for DNS-editor mistakes such as a suffix appended twice, a record published in the wrong zone or a selector copied from a different tenant.
Distinguish absence from unavailability
A negative answer that establishes no corresponding key is different from a query that times out. RFC 6376 §6.1.2 requires PERMFAIL for an absent key and permits TEMPFAIL when the key query fails to respond. These are verifier processing outcomes; the exact displayed label in a diagnostic product can differ.
Capture the DNS response code and answer, not just a red indicator. Compare authoritative answers with the recursive view relevant to the failing receiver where evidence is available. A successful lookup from your laptop later does not prove that the key was reachable at the original evaluation time.
Use a three-branch diagnostic tree
First, if the message contains no DKIM-Signature, investigate signing configuration rather than a selector lookup. There is no message-specific s and d pair to retrieve. Second, if a signature exists and its key is absent, inspect publication, migration and retirement history. Third, if the key is available but the body hash or signature fails, move to content, key-match or cryptographic checks.
Illustrative case: a message names selector old7, while DNS contains only new8. Publishing new8 correctly cannot verify the old7 signature. If old7 was intentionally retired, the error may be expected for delayed or archived mail. If old7 was accidentally removed and its key is still trustworthy, restoration of the correct verification data may be an appropriate approved repair. These are diagnostic scenarios, not executed tenant tests.
Check key validity after retrieval
Finding a TXT answer does not finish verification; RFC 6376 §3.6.1 and RFC 6376 §6.1.2 define key syntax and validation. A malformed key, an empty p value indicating revocation, or incompatible key material is not a usable verification key. Under RFC 4592 §3.3.3, a wildcard TXT record can also produce an answer that is irrelevant to DKIM. Do not relabel every unusable answer as a missing selector.
Use the provider's exact current record value or a known, authorized configuration backup. Never generate a random public key to satisfy the lookup: it will not match the private key that created the signature. Avoid replacing records at a shared lookup without reviewing other senders and delayed messages.
Verify the fix with fresh evidence
After an authorized repair, inspect DNS and send new controlled mail through the affected route. Preserve the received result, signature identity and alignment assessment. If the original sample now verifies, record that as a later recheck rather than rewriting its historical receiver outcome.
Close the incident with the missing name, cause, restored dependency and prevention measure. A selector inventory and a retirement checklist reduce recurrence more effectively than repeatedly adding records whenever a checker reports red.
Preserve a bounded conclusion
For old7 versus new8, preserve the old signature’s lookup rather than copying the current selector into the incident record. An absent old7 key, a timeout and an empty-p revocation are different observations. A later successful recheck must keep its later time. No repair or signature verification was performed for the teaching scenario.