DKIM verification depends on retrieving public verification material through DNS. A signature can be cryptographically well formed yet remain unverifiable when the relevant lookup is unavailable. Investigate the DNS path and the time of the receiver's attempt before replacing keys or changing message content.
A successful lookup after an incident is useful recovery evidence, but it does not establish what happened during the failed attempt. Preserve the original authentication result, message, timestamp and any available resolver logs. The aim is to explain the observed failure without claiming visibility into a receiver's infrastructure that you do not have.
Establish the exact lookup and outcome
Read d and s from the affected DKIM-Signature and construct the selector lookup under _domainkey of d. Under RFC 6376 §3.6.2.1 and RFC 1034 §3.6.2, if the supported setup uses a CNAME, capture the chain and final verification answer. Include the response code, time, resolver and authoritative server where available.
RFC 6376 §6.1.2 distinguishes a query that fails to respond from a key record that does not exist. The former can yield TEMPFAIL and a later attempt; the latter requires a no-key PERMFAIL for that signature. RFC 8601 §2.7.1 temperror likewise describes a likely transient verification error. Do not turn all DNS-related failures into one missing-record diagnosis.
Compare views without overstating them
Check the authoritative zone and representative recursive resolvers. A difference can point to stale cached data, delegation inconsistencies or a problem reaching part of the DNS path. If a provider-managed target is involved, investigate that target as well as the customer-controlled alias.
Record evidence for potential causes rather than selecting one from the error label alone. A resolver's SERVFAIL, for example, needs further diagnosis; it is not proof that the key was deleted. DNSSEC validation (see RFC 4035 §5.5), delegation and transport problems can require the DNS operator's logs and expertise. Do not disable validation as a default fix merely to make one lookup succeed.
Follow a time-based example
Illustrative sequence: a receiver attempts to retrieve active1._domainkey.sender.example at 10:00 and reports a temporary key retrieval error. At 10:05, an administrator retrieves a valid key from a different resolver. Both observations can be true. The second establishes availability for that query at 10:05, not availability to the first receiver five minutes earlier.
By contrast, if the authoritative answer at the incident time establishes that the active selector is absent, waiting for a transient outage to clear may not solve the configuration problem. If the record is restored, negative caching under RFC 2308 §5 can also affect when other resolvers observe it. The example is a diagnostic timeline, not a measured outage or a promised recovery interval.
Check the rest of verification after recovery
Following RFC 6376 §6.1.2 and RFC 6376 §6.1.3, once key retrieval works, confirm that the returned record is usable and corresponds to the signer. A retrieved key can still be revoked, malformed or incompatible. A matching key cannot compensate for content modified after signing. Keep lookup, key validation, body-hash verification and signature verification as separate stages in the incident record.
When several signatures exist, one failed lookup does not necessarily remove every aligned authentication path. Under RFC 9989 §5.3.5, inspect the other signatures and SPF before concluding that DMARC failed. Under RFC 6376 §6.3 and RFC 9989 §5.4, receiver delivery policy is another separate decision; a transient DKIM problem does not guarantee either deferral or acceptance.
Close the outage with controlled tests
After the DNS operator's authorized repair, test the affected lookup through relevant views and send new messages through the original route. Record expected and observed results. Ask for DNS and provider incident evidence when the cause lies outside your administrative scope.
Keep an inventory of delegated selector targets and their owners so that the next alert reaches the right team. Monitor the dependency that actually failed, but describe the monitoring scope honestly: a periodic public query does not reproduce every receiver's cache, network or validation behavior. Closure should state what recovered, what evidence supports the diagnosis and what remains unobserved.
Preserve a bounded conclusion
Keep the 10:00 failure and 10:05 success as two records, each with resolver, query name, result and visibility limits. The five-minute gap is illustrative, not a recovery target. DNS TTL is a freshness interval, not a global revocation deadline: RFC 8767 §4 permits qualifying stale use. No resolver outage, recovery or mail test was measured.