Adding a second rua destination can help compare collectors or preserve an independent copy. It also creates two delivery and processing paths that can disagree. Define what the second destination is supposed to prove before treating its dashboard as a backup of the first.
Understand the delivery request
References: RFC 9990 §3.5, RFC 9990 §4.
RFC 9990 section 3.5 requires a reporter to evaluate the listed URIs in order and attempt delivery to the remaining valid URIs up to its supported limit. This is not a promise that every receiver implements the same destination capacity or that every attempted delivery succeeds. Check each destination's eligibility, including external-destination authorization where applicable.
Two mailto destinations in the same valid request are not instructions to divide the report's message count between them. When equivalent reports reach both, their counts describe the same observations. Adding both collectors' totals can double-count traffic.
Prepare both collection paths
Record the exact published request, mailbox routing, destination owner and applicable authorization records. Have the owners verify attachment acceptance, mailbox capacity and parser support. Adding a third-party destination also expands who receives operational data, so approve that access and retention purpose before making the change.
Retain the existing working path during a controlled comparison if authorized. Make only the intended destination change and preserve its previous value. Do not simultaneously change enforcement policy and the parser if the goal is to understand collection differences.
Compare reports before dashboards
References: RFC 9990 §3.5.1, RFC 9990 §3.5.4.
Build a comparison keyed by reporter, policy domain, report identity and reporting interval. Retain attachment fingerprints and arrival timestamps. Check whether a missing dashboard entry was never received, was filtered, failed parsing or was excluded by a display filter.
Illustrative case: collector A shows 800 observations while collector B shows 600 for the same nominal day. Examination finds one 200-observation report in B's quarantine. The discrepancy is collection-side; it is not evidence of 200 additional messages sent through A. If the files themselves differ, preserve both and investigate rather than coercing totals to match.
Define the comparison's limits
References: RFC 9989 §5.3.8, RFC 9990 §3.5.
A successful paired arrival demonstrates those particular deliveries. It does not establish complete receiver coverage or guarantee identical future arrivals. Reports may be delayed, retried or discarded when delivery is unavailable. Different dashboard time zones and deduplication rules can also change displayed totals.
Close the migration only after a representative observation period, matched report samples and an explained exceptions list. Keep the old destination until the approved removal criteria are met. If a discrepancy remains unexplained, label the comparison incomplete rather than choosing the larger dashboard as the truth.
Keep a destination comparison register
For each destination, save the request revision, authorization check, first matched arrival, last matched interval and unresolved exceptions. Compare the same raw report set before comparing a vendor's derived categories. One collector may classify a shared source differently without having received different XML. Separate these interpretation differences from transport losses. Before removing an address, verify its contractual retention and export arrangements and obtain approval for the removal. Keep a dated export of the comparison so a later change can be distinguished from the original migration decision.
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 test models a successful 250 receipt at each destination and parses the same attachment at both. Each parser returns R1 and count 100. The comparison records two arrivals but one observation set of 100, not a combined volume of 200. This establishes the fixture's duplicate-copy arithmetic only. To replace the simulation with real evidence, retain the actual request lookup, authorization lookup, receipt IDs, protected attachment hashes and parser job outputs for each destination. If one receipt is absent, record an unobserved delivery instead of fabricating a matching copy.
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.