A DMARC service migration can be a reporting-only change or a live authentication change. Establish which one you are making. If the service only collects aggregate reports, replacing the collector need not change SPF authorization, DKIM keys or DMARC enforcement. If it also hosts DNS or signing dependencies, those need their own exit plan. Combining all changes into one window makes failures harder to attribute.
Inventory the current report path
Record each policy domain, its exact policy record, report recipients, external authorization dependencies, collector account, export method and retention boundary. Record which team owns raw report access. Check whether a dashboard total represents raw observations, normalized rows, deduplicated reports or a proprietary interpretation. Preserve that distinction when comparing providers.
RFC 9990 defines aggregate report structure and external reporting authorization. Reports contain an observation period and reporter metadata; they are not a complete real-time ledger of every message. A missing day in a dashboard can mean a delivery, ingestion, parsing or presentation problem. Find the earliest stage at which evidence disappears before changing the sending policy.
Prepare the new destination and a bounded overlap
Confirm the new recipient can accept and process reports for the intended domains. Establish the required external destination authorization where applicable. If approved, keep old and new recipients during a bounded overlap using valid policy syntax and supported collector configuration. Approve the additional disclosure before duplicating reports to a new organization. A second recipient is not free of privacy implications merely because the records are aggregate.
Export raw examples and parser results before the old account ends. Test large or compressed inputs using the collector's documented interfaces and safeguards; do not invent an upload format. Compare policy domains, report intervals and reporter identities, then inspect discrepancies at raw-report level. Differences in processing time and deduplication can make equal-looking totals misleading.
Reconcile an explicitly bounded overlap example
Suppose old-collector keys are A, B and C while new-collector keys are B, C and D. The union contains four distinct candidate keys, with two shared, one old-only and one new-only. It does not establish four unique messages or even four unique reports until key collisions and content are reviewed. Assume these examples refer to the same reporting interval. Each key combines reporter, policy domain, interval and report ID, but that combination is not guaranteed to resolve corrected reports or identifier reuse; retain raw content hashes.
Old-only A needs delivery and ingestion investigation before complete overlap can be claimed. New-only D is not explained by a later interval in this stated case; check the old recipient’s intake and each collector’s parsing before treating it as improved coverage. These are hypothetical sets and reasoning, not a reconciliation program, actual collector observations or accepted gaps. Document the explanation or obtain an explicitly scoped decision on any unresolved coverage loss before ending access.
Finish the migration with an evidence-based exit
Do not set a universal number of overlap days. Choose the window from observed reporting cadence, important low-volume senders and contractual access expiry. Name the person who accepts any remaining coverage gap. Keep a recovery route while authorized access still exists, and make the raw export readable without the old dashboard.
When the comparison and ownership review are complete, remove the old report destination through the change process, verify the published policy and confirm the new collector continues receiving data. Remove obsolete external authorization and account access only after checking their remaining uses. Archive the baseline, intended diff, verification results and unresolved limitations. A successful dashboard login is one check, not proof of reporting continuity.