A missing-record answer can outlive the missing record
A new DKIM selector can exist in authoritative DNS while a recursive resolver still answers as though the key is absent. One possible explanation is negative caching: the resolver previously learned that the name or requested record type was unavailable and retained that answer. Repeatedly saving the same TXT record will not notify every cache that the situation changed.
Start by proving that the intended record is now present at the correct authority. Check the complete owner name, requested type and any alias target. Negative caching is a hypothesis to test after publication is confirmed, not a convenient explanation for a record that was created in the wrong zone or has not been served by all relevant authorities.
Identify what the earlier answer denied
NXDOMAIN indicates that a name does not exist. NODATA describes an answer with no relevant records of the requested type, rather than a dedicated DNS response code. Its usual header code is NOERROR. Inspect the authority section and alias processing to distinguish that result from a referral or an unfinished lookup. An empty answer section alone is insufficient. RFC 2308, sections 2.1–2.2.
The scope matters. Under RFC 2308's cache model, a name-error entry is associated with name and class; a no-data entry also includes the requested type. If an alias precedes the negative answer, establish which final name is missing. A customer-side selector alias can exist even when its provider-side target does not. That calls for a different owner to investigate than a missing customer record.
Preserve the earlier result if it is available. A current positive answer cannot reconstruct the TTL and authority section of a negative response obtained yesterday. Where no earlier capture exists, say that negative caching is consistent with the observations but unproven.
Calculate the lifetime from the right SOA fields
For an authoritative negative answer, RFC 2308 sets the SOA record's TTL in that response to the smaller of the SOA record's own TTL and its MINIMUM field. The cached negative lifetime then counts down. Reading SOA.MINIMUM alone as a universal negative-cache timer is incomplete. RFC 2308, sections 3–5.
In a fictional example, the zone's SOA TTL is 900 seconds and MINIMUM is 3,600. A negative response generated using those values has an initial negative lifetime of 900 seconds, not 3,600. If a resolver obtained it at 12:00, and the new selector was published at 12:03, the earlier negative entry could still affect that resolver during the remaining ordinary cache window. These invented times illustrate the calculation, not an observed incident.
At 12:05, a sampled recursive answer might show a reduced SOA TTL. Retain what it actually reports instead of replacing that value with a fresh SOA query's configured fields. Other caches may have acquired different answers at different times, and resolver policy can limit caching. A single calculation does not establish universal recovery at 12:15.
Do not confuse absence caching with failure caching
SERVFAIL and a timeout do not affirm that the record is absent. They describe failure to obtain a usable result. RFC 9520 updates the older negative-caching rules by requiring resolution-failure caching, including DNSSEC validation failures; its failure-cache duration is at least one second and no more than five minutes. This is separate from the SOA-derived NXDOMAIN/NODATA calculation. RFC 9520, sections 3.2–3.4.
Repeated failed refreshes can lead to further failure-cache entries, so that upper bound is not an outage-recovery guarantee. If a lookup returns SERVFAIL after a repair, preserve the response and investigate the resolver's diagnostics and upstream availability. Do not replace an authentication policy simply because a resolution failure was described informally as a missing record.
During authority-refresh failures, serve-stale behavior can also complicate the timeline, including stale negative data. Record whether the affected resolver is configured to serve stale answers when that information is available. Do not infer the configuration from a single output line. RFC 8767, sections 4 and 10.
Publish new names before they become dependencies
For a planned selector rotation, prepare the new public record before switching the signing service to use it. Verify the exact owner and any target with the responsible operators. Avoid repeatedly probing an uncreated production name as though success were expected; such queries can establish negative cache entries before publication.
If a preflight query is necessary, retain its time and response. Include negative-cache considerations in the launch plan rather than hiding an inconvenient preflight failure. A lower TTL on the future TXT record does not retroactively shorten an absence response already cached elsewhere. Likewise, flushing an administrator's laptop does not purge a mail provider's resolver.
Build a bounded recovery record
The proposed worksheet has one row for each endpoint and observation: UTC time, exact question, response code, relevant answer or alias, SOA owner and returned TTL, and authority or recursion role. Compare current authoritative results with the affected recursive path and a separately identified comparison resolver. Preserve the complete responses and repeat at a reasonable documented interval.
If authority lacks the record, fix publication. If authority is correct and a captured negative entry explains the recursive result, track that specific cache path. If SERVFAIL, referrals or inconsistent authorities appear, investigate those branches instead. Finally, verify a controlled message using the new selector. This article contains fictional arithmetic and a proposed workflow only. Original resolver comparisons and received-message results remain outstanding, so the catalogue's operational evidence gate is still open.