A useful DNS history explains both intent and observation. The change ticket says what an operator meant to publish. An authoritative answer shows what a queried server returned at a particular moment. A recursive answer shows what that resolver returned, possibly from cache. Keep all three when reconstructing an authentication incident; none alone tells the complete story.
Record the exact object and source
For every observation retain UTC time, queried owner name, type, server address, transport, response code, relevant flags, TTL and full answer. Preserve raw output or wire data as well as a normalized view. Record whether the observation came from an authoritative server, a recursive resolver or a control-panel export. RFC 1034 explains the authority and caching distinction.
For a policy change, keep the previous and intended values, approver, business reason, affected senders and rollback conditions. A later screenshot cannot prove the earlier DNS state. If history was not captured, say so. Passive observations or report metadata can provide clues but should not be presented as a complete authoritative change log.
Preserve semantics when comparing records
Normalize carefully. DNS names are case-insensitive, but an indiscriminate transformation of all TXT content can damage evidence. TXT RDATA can contain multiple character strings; presentation quoting is not the same thing as multiple independent resource records. Preserve original structure and compare the application-meaningful value separately. For SPF, multiple policy records are a semantic issue, not harmless formatting.
Separate a policy value change from a TTL change, a delegation change and a resolver cache transition. Negative responses can persist according to negative-caching rules in RFC 2308. A new authoritative value does not establish that every receiver immediately used it. Avoid deriving a universal propagation completion time from one successful lookup.
Read two observations without inventing an edit time
Suppose an authorized authoritative query at 10:00 shows an old policy. At 10:05 the same authority returns the new policy, while a recursive resolver still returns the old value with a remaining cache lifetime. Both observations can be accurate for their respective sources. Neither establishes that all other servers or receivers have the new value.
This is a hypothetical timeline, not retained packets or an executed DNS lab. If the provider audit event is unavailable, the exact mutation instant is unknown. Under the stated assumption of a single transition at the queried authority, the observations bound when that authority’s visible answer changed; they do not prove the precise publication time or global convergence. Record the missing audit event instead of filling it with a guessed timestamp.
Connect history to message evidence
When reviewing a failure, align message timestamps, DNS observations, signing selectors, queue delays and report observation intervals. RFC 9990 provides aggregate reporting context, but a report is not a transaction log for DNS edits. An authentication result describes an evaluation; it may not reveal the exact resolver cache contents that caused it.
Retain the evidence under an approved access and retention policy. Hashes help detect changed bytes, but an unsigned local manifest is not tamper-proof provenance. Keep source and collection context with the digest. Make gaps explicit, including missing vantage points or unrecorded periods. The goal is a defensible reconstruction and a safer next change, not false certainty about every receiver's view.