Aggregate reporting is retrospective evidence. A dashboard can be current as a collection system while its newest observations still describe yesterday's mail. Track the clocks separately so a delayed report is not mistaken for a current sending failure, and a current failure is not hidden behind old healthy data.
Keep three timestamps
References: RFC 9990 §3.1.1.4, RFC 9990 §3.1.
Preserve the report's begin and end timestamps, the receiving system's arrival timestamp and the collector's processing timestamp. Interpret the report interval in UTC and show any display-time-zone conversion explicitly. File modification time is not a substitute for the observation window.
RFC 9990 describes periodic aggregate feedback and includes the covered date range in report metadata. It does not create a universal real-time monitoring service. A report that arrives late can still be useful evidence for its original interval.
Measure delay by reporter
For operational monitoring, calculate receipt delay from the report end to arrival and processing delay from arrival to successful import. Keep separate distributions by reporter and collection path. These are local operating metrics, not protocol guarantees. Define alert thresholds from observed behavior and the business decision that requires timely data.
Also monitor ingestion errors and the newest covered interval. A steady flow of duplicate or old files should not make the freshness display green. Mark provisional reporting windows until your documented late-arrival process closes them.
Distinguish an outage using current evidence
When users report missing password resets, inspect current sending queues, SMTP responses and controlled received messages. Do not wait for tomorrow's report to begin troubleshooting. Conversely, if current tests succeed but aggregate data is old, investigate the reporting path without declaring the sending service down.
Illustrative timeline: a report covers Monday 00:00–24:00 UTC, arrives Tuesday at 05:00 and is imported at 08:00. Receipt delay is five hours; processing delay is three hours. Neither number measures how long an individual Monday message took to arrive. These synthetic values illustrate the accounting method, not a recommended service target.
Handle late arrivals without rewriting history silently
References: RFC 9990 §3.5.4.
Retain an as-of timestamp on exported metrics and version any revised totals. Reprocessing should be idempotent so a retry does not count the same observations again. Keep original intervals rather than placing all late files into the day of arrival.
Escalate a missing expected reporter, a growing processing queue and a live sender failure as different incidents. Close each with the relevant evidence. Report freshness is meaningful only when it names which population and interval are actually available.
Publish an actionable freshness panel
Show the latest covered interval, arrival time and import time for each important reporter, plus the size and oldest age of the processing backlog. Include the last refresh of the monitoring system itself. A frozen dashboard should not appear healthy because its most recent stored status was green. Assign separate owners for receipt failures and processing failures. Before using an alert threshold, document the observation period from which its baseline was derived and what action an alert should trigger. Revisit it after collector migrations.
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 following is a locally rerun offline synthetic fixture, not a live DNS, SMTP or customer observation. Its XML input was parsed with Python's standard library, and assertions checked the resulting fields and calculations. The simulated DNS and mail stages are supplied test inputs, not evidence that a real receiver performed those operations. Full schema validation and production-source authentication are outside this small fixture; live evidence remains pending.
The supplied request is _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". These reserved example domains are assumed to be separate organizational domains in the fixture. The two synthetic authorization answers are brand.example._report._dmarc.collector.example TXT "v=DMARC1" and brand.example._report._dmarc.archive.example TXT "v=DMARC1". The local model matches both supplied authorization-owner names and their version values under RFC 9990 §4. It does not execute DNS queries or the complete authorization algorithm. A production implementation must perform the complete discovery and authorization procedure rather than assuming these domain boundaries.
The retained report has ID R1, policy domain brand.example, date_range begin 1772409600 and end 1772496000, source IP 192.0.2.10 and count 100. Its evaluated aligned DKIM result is pass and aligned SPF is fail. The raw SPF result is pass for vendor.example, illustrating why raw success is not aligned success. These fields are parsed from XML rather than inferred from a dashboard.
The fixture sets arrival to report end plus 18,000 seconds and completed import to report end plus 28,800 seconds. Executed subtraction yields five hours of receipt delay and three hours of processing delay. Both destinations and permission inputs remain the same, so the calculation can be followed from published request through parsed interval and collector timestamps. These values are test inputs, not measured latency or an SLA. RFC 9990 §3.1.1.4 supplies the UTC date-range semantics; the delay formulas are this workflow's operational definitions.
Keep the result within the tested scope
The supplied local demonstration verifies only its small synthetic parser, supplied stage inputs and calculations. No real DNS authorization, SMTP delivery, collector migration, provider participation or production database behavior was tested. Original inputs remain archived, and any live comparison needs its own protected evidence and accountable approval.