A current DNS lookup cannot prove what a receiver used earlier in a reporting window. A policy change can cross report boundaries, DNS cache states and receiver generation practices. Preserve the history before interpreting an apparent mismatch between a report and today's record.
Save the change timeline
References: RFC 8767 §4.
Record the old and new DMARC records, affected domain, approved change time, authoritative observations and relevant TTL information. Preserve related SPF and DKIM changes separately. A policy edit and a sender authentication repair may occur together but explain different aspects of the resulting reports.
Record times in UTC with the observation method. An authoritative answer at a given time establishes what that server returned then; it does not establish that every receiver immediately discarded a cached answer. Avoid an invented universal propagation deadline. Qualifying serve-stale behavior under RFC 8767 §4 can retain usable data beyond normal TTL freshness.
Read the reported policy in context
References: RFC 9990 §3.3, RFC 9989 §5.4.
RFC 9990 section 3.3 describes mixed-policy reporting during changes. A receiver may produce multiple reports for the period or a single report whose observations span policy states while its policy_published element contains one configuration. The report's one policy snapshot is not a message-by-message DNS audit.
Inspect the covered interval, reported configuration and handling information separately. A reported disposition is also not a substitute for the aligned authentication result. Receiver-local decisions can differ from the domain owner's requested handling.
Work through a transition
Illustrative case: the owner changes p=none to p=quarantine at 12:00 UTC. A report covers 00:00–24:00 and records a final published quarantine preference. It can still include earlier observations or handling associated with the previous policy. That mismatch alone is not evidence that the receiver ignored a policy it had already observed.
The correct investigation compares the change log, reporter window and available message-level samples. If policy-specific reports are separate, preserve their identity and check overlap before summing. Do not rewrite older observations to inherit the current DNS state.
Verify the actual change separately
Check the authoritative publication and representative subsequent messages through important routes. Record trusted authentication results and any receiver-specific findings. A clean later reporting interval can provide additional evidence, but neither it nor a current DNS lookup proves behavior at every receiver.
Annotate charts with configuration events and keep pre-change, transition and later intervals distinguishable. Close the change with observed results, unresolved implementation differences and recovery criteria. Historical reporting is most useful when it retains the uncertainty that existed at the time.
Keep a change evidence packet
Place the approved record diff, publication observations, test-message references and relevant report identities in one access-controlled record. Note any other changes deployed nearby, including gateway transformations or provider signing updates. Those confounders can explain an authentication shift that otherwise appears linked to the policy edit. Record the analyst's interpretation separately from the original report so a later reviewer can revisit it. Use a clear stop condition for expansion to other domains if critical routes show unexplained failures.
Continue the investigation
Use the aggregate-report walkthrough to interpret the underlying fields and the alignment diagnosis guide when a raw authentication pass does not satisfy DMARC.
Executed synthetic evidence
The supplied locally rerun synthetic field fixture represents a policy transition at interval second 43,200 from none to quarantine. The report spans second 0 through 86,400 and policy_published records domain brand.example with p=quarantine. Relative seconds make this a model, not a historical DNS record. Two supplied records are processed:
- Fixture row: Billing; Count: 90; Disposition: none; Aligned DKIM: pass; Aligned SPF: fail; Ownership evidence: Known only as a supplied fixture fact
- Fixture row: Unknown source; Count: 10; Disposition: none; Aligned DKIM: fail; Aligned SPF: fail; Ownership evidence: Unclassified
Executed arithmetic yields 100 observations, 90 aligned passes and 10 aligned failures. The field-to-decision chain is specific: date_range straddles the change, policy_published is one snapshot, and the 10 failures' none disposition does not identify when those messages were evaluated. Investigate those 10 using historical policy observations and authorized samples. Do not automatically label them pre-change or conclude that the receiver ignored quarantine. The known billing fixture needs no authentication repair on this evidence because its aligned DKIM passes, although business delivery still needs separate evidence. Real service attribution, DNS observations and receiver samples remain pending.
Keep the decision bounded
The local exercise counts 90 supplied aligned passes and 10 failures, but leaves the 10 failures’ evaluation times unknown. The model cannot infer pre-change timing or receiver noncompliance from none disposition. No DNS lookup, policy change or receiver test was performed.