Two reports covering some of the same time are not necessarily duplicate copies. They may come from different receivers, different reporting components or a retransmission with conflicting content. Determine what is known about their identity and population before combining their counts.
Build a provenance record
References: RFC 9990 §3.1.1.3, RFC 9990 §3.5.1.
Preserve the submitted reporter name, report ID, policy domain, covered interval, attachment fingerprint and arrival details. Keep raw identity values even if the dashboard uses a normalized label. A changed display name should not erase the ability to reconstruct the original source.
If two labels appear related, seek supporting evidence such as the reporter's documented infrastructure or a verified migration. A common suffix or similar organization name is a clue, not authorization to merge every report into one identity. Version any alias mapping and record who approved it.
Compare interval overlap separately from identity
References: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Different receivers can observe traffic during the same day without their reports being duplicates. Within a verified reporting source, matching identities and content can support a duplicate decision. Different identities with overlapping windows require closer inspection, including policy changes and independent reporting components.
RFC 9990 recommends non-overlapping reporting periods, yet consumers must handle imperfect input. Its duplicate guidance explains that partial overlap does not provide a clear way to distinguish the repeated observations. Time overlap alone does not tell you the duplicate message count.
Avoid invented subtraction
Illustrative case: report A covers 00:00–12:00 and counts 600; report B covers 06:00–18:00 and counts 900. The six-hour overlap does not establish that 300, 450 or any other fixed number is duplicated. Traffic may be uneven, and the populations may differ. Subtracting half a report produces a modelled estimate, not an observed unique total.
For a reconciled metric, hold the uncertain pair for review or apply a documented whole-report inclusion rule. Preserve the alternative and explain the resulting coverage loss or possible double counting. Do not present a precise unique total if the evidence cannot support one.
Make the decision reproducible
Record why reports were treated as distinct, duplicates or unresolved overlap. Show how much volume is affected. Keep overlapping windows visible when exporting data so a downstream analyst does not accidentally sum a diagnostic view as if it were clean.
Test the importer with adjacent intervals, exact repeats, distinct reporters and partially overlapping reports. A successful alias cleanup should improve provenance, not merely make a chart smoother.
Create an overlap exception record
Capture both report references, the exact intervals, suspected source relationship and affected counts. State which reports are included in each exported view. If an analyst chooses a conservative whole-report rule, record its effect on coverage; if both are retained in a diagnostic view, warn that its sum may include repeated observations. Ask for clarification from the reporter only through an authorized support process. Until better evidence arrives, preserve the ambiguity as data rather than converting it into an unsupported duplicate estimate.
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 locally rerun arithmetic fixture supplies two reports from the same verified synthetic reporting population. A covers 00:00–12:00 and B covers 06:00–18:00. It applies a deliberately explicit rule: retain the first admitted whole report in the provisional metric and hold a later unresolved overlap. It does not estimate duplicated observations by hours.
- Service: Billing; Report A, included: 400; Report B, held: 300; Naive combined count: 700
- Service: Alerts; Report A, included: 200; Report B, held: 600; Naive combined count: 800
- Service: Total; Report A, included: 600; Report B, held: 900; Naive combined count: 1,500
Executed assertions verify included total 600 and held total 900. The unique-message total remains null. The included 600 is a policy-selected report count, not proof of complete unique volume for the combined 00:00–18:00 window. Billing and alerts are supplied synthetic service assignments, not inferred from shared infrastructure. These retained raw rows, inclusion rule and output make the metric reproducible while preserving the unresolved overlap. Different approved inclusion policies may produce different provisional totals and must be named. RFC 9990 §3.1.1.4 supplies the reporting-period guidance.
Keep the decision bounded
The local exercise checks only the supplied 400 + 200 included observations and 300 + 600 held observations. Its 600 provisional total is not an estimate of unique messages across both windows; that value remains unknown. No actual report identity was authenticated or merged.