An authentication incident often contains several clocks: a report's covered interval, the report's arrival, a DNS change, an application deployment and a controlled test. Putting them on one timeline is helpful only if each event keeps its original meaning. A daily aggregate report cannot usually tell you the exact minute when each included message failed.
Establish a common time basis
References: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normalize displayed timestamps to a declared timezone while retaining original values and precision. Record clock sources and known uncertainty. Distinguish the report interval from arrival and ingestion timestamps. Late report delivery should not be plotted as a new burst of sending at the moment the attachment arrived.
Scope the investigation to an author domain and verified service where possible. Keep unclassified sources separate. Preserve reporter and report identity, message counts, source groups and evaluated identities, along with duplicate and overlap decisions. Those details determine which observations can legitimately be compared.
Add DNS evidence without rewriting history
References: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Record the approved change, intended publication time, authoritative observations and any resolver samples, including lookup time and returned TTL. A current DNS answer establishes what that lookup observed now; it is not a complete history of what every receiver saw earlier.
DNS caching matters under RFC 1034 §3.6; qualifying serve-stale behavior under RFC 8767 §4 can extend cache use beyond normal freshness. Do not claim that all receivers switched at the instant of publication or exactly one displayed TTL later. Preserve the prior configuration, change log and evidence limits. Where a report interval spans a policy change, label it as mixed or potentially mixed rather than assigning every observation to the final policy.
Add application and receiver evidence
References: RFC 5321 §4.2.5.
Place application deployments, gateway changes and signing changes beside the DNS events. Keep controlled tests as individual observations with their actual route, receiver and result. An application log may show submission or acceptance at a hop; it does not necessarily establish final delivery.
Use these evidence types to test competing explanations. A failure increase after a DNS edit might also coincide with a new template that changes signed content. Correlation narrows the investigation but does not identify the cause without further evidence.
Work through a bounded timeline
Illustrative case: a report covers 00:00 to 24:00 UTC. A policy change is recorded at 12:00, and a controlled test at 12:20 passes aligned DKIM. The report contains 80 passing and 20 failing observations, arriving the next morning at 05:00.
You can state the interval totals and the successful test at 12:20. You cannot assign all 20 failures to before noon merely because the test passed later. The next action is to obtain narrower receiver or application evidence, or run additional representative tests. The arrival at 05:00 is a collection event, not the time of the 20 failures.
Close with a causal statement of the right strength
Label conclusions as observed, corroborated or still hypothetical. Name the evidence that supports the suspected cause and any competing explanation not ruled out. If exact linkage is impossible, retain the uncertainty rather than drawing a precise failure boundary on the chart.
Save the timeline with source references, query revision, included intervals and ownership classifications. Record the next verification trigger, such as the first complete comparable reporting period after a repair. A reusable timeline should allow another analyst to reconstruct both the facts and the limits of the conclusion.
Continue the investigation
Use the aggregate-report walkthrough for the underlying fields and the alignment diagnosis guide when raw authentication success does not satisfy DMARC.
Keep the illustration within its evidence
For the fictional 80-pass/20-fail interval, keep all 20 failure times unknown. The 12:20 test is one later observation and the 05:00 arrival is a collection event. No real DNS lookup or authentication test was executed, and the timeline does not locate a proven causal cutover.