The same aggregate report can arrive twice, and different reports can cover overlapping periods. Treat these as separate problems. Preserve reporter identity, report ID, policy domain, reporting interval and payload provenance before deciding whether to count or discard data.
Read identifiers with their context
References: RFC 9990 §3.5.1, RFC 9990 §3.1.1.3.
RFC 9990 requires the Report-ID to be unique among reports to the same domain and describes how that identifier supports duplicate detection. It is not a message ID for an individual email. The reporting organization name is useful context, but a display label alone is not strong proof of origin.
Store the original attachment, a content hash, arrival time and relevant delivery provenance alongside report_metadata. Preserve the policy domain and normalized begin and end values. Treat any composite database key you choose as an ingestion design, not as a replacement for the specification's uniqueness requirement.
Distinguish the reporting period from arrival time
References: RFC 9990 §3.1.1.4.
The begin and end values describe a UTC reporting interval in seconds since the epoch. They are not the timestamps of the first and last observed messages. Delivery time can be later, and an interval can span a deployment or DNS-policy change.
Convert the interval for human display while retaining the original numbers and UTC representation. Do not silently relabel a reporter's window to match your local calendar day. An apparent daily volume change can be an interval-length or delayed-arrival issue rather than a real sending change.
Handle duplicates and overlaps separately
References: RFC 9990 §3.5.4.
Illustrative case: two deliveries have the same report identity and identical decompressed XML hash. The second can be recorded as a duplicate receipt without adding its counts again. Preserve the fact that it arrived so the processing decision is auditable.
Now suppose a second report covers a partially overlapping interval but has different counts. Aggregate data generally does not identify which individual messages overlap, so subtracting half the count because half the hours overlap is unjustified. RFC 9990 notes the uncertainty of partial overlap. Choose and document an inclusion policy, flag the resulting limitation and avoid presenting the total as deduplicated truth.
A reused report ID with changed content deserves inspection rather than automatic rejection or replacement. Keep both versions, compare period and rows, and record which evidence contributes to the displayed totals. The scenarios here are synthetic and do not establish the behavior of any real reporter.
Make ingestion decisions reversible
Maintain separate states for accepted, exact duplicate, conflicting identity, partially overlapping and invalid reports. Keep a reproducible link from each dashboard total to the included records. Do not destroy original evidence merely because it was excluded from aggregation.
Review recurring anomalies with the reporting source when an authorized channel is available. Until resolved, describe coverage honestly. A trustworthy total explains its time window, contributing reporters and duplicate policy instead of hiding those choices behind one number.
Reconcile five receipts numerically
Use this explicit synthetic ingestion policy: preserve all receipts; exclude exact normalized-payload repeats; hold both payload versions out when one reporter reuses an identity with changed content; and exclude a later partially overlapping report from this particular comparison total. Other documented policies are possible.
Receiver A sends ID 42 for policy domain brand.example, window 0–86400 and count 10: total 10. An identical second receipt adds zero: total 10. To model a cross-reporter identifier collision rather than assert that reuse complies with the uniqueness rule, receiver B sends ID 42 over the same window with count 7: include it as a different reporter, giving 17. A then sends ID 42 with count 12: hold both A versions, revising the total to 7. B sends ID 43 over window 43200–129600 with count 9: exclude and flag that partial overlap, leaving 7. Windows are synthetic elapsed epoch seconds.
The supplied local arithmetic exercise reproduces totals 10, 10, 17, 7 and 7. The final number represents included receiver observations, not unique worldwide messages. No fractional overlap is inferred, and the excluded data remains available for investigation.
Keep the exercise within scope
The examples are partial field projections, not schema-valid reports or measured traffic. Local checks use explicitly supplied authentication results and organizational relationships; they do not perform DNS discovery, SPF evaluation, cryptographic verification, report ingestion or receiver delivery tests. Preserve the original report and trusted message evidence before making a production change.