How to migrate DMARC reporting from another platform
Published 18 Jul 2026
Updated 18 Jul 2026
9 min read
Summarize with
Migrate DMARC reporting by adding the new platform's aggregate report address to each client's existing rua tag, keeping the old destination active during an overlap period, and removing the old address only after the new platform shows stable report volume and the expected sending sources. Do not change the client's DMARC enforcement policy during the reporting cutover.
For an MSP, the migration is an operational change across client DNS, reporting continuity, ownership, and support records. A successful cutover preserves the current p, sp, pct, adkim, aspf, and ruf values unless there is a separately approved policy project. It also produces evidence that reports reached both platforms before the old service was retired.
Separate migration from enforcement
Keep the current DMARC policy unchanged while moving report delivery. Combining a platform migration with a move to quarantine or reject makes missing mail, authentication changes, and reporting gaps harder to diagnose.
Build a migration register before changing DNS
Start with a client-by-client register. We treat the domain, DNS owner, approval contact, current DMARC record, old reporting destination, intended new destination, and rollback value as required fields. Add the observed sending sources and normal daily message range so the post-change review has a baseline. The sender inventory process is useful here even when enforcement is already active.
- DNS control: Record the provider, zone owner, change window, approver, and expected propagation time.
- Current record: Save the exact TXT value and a timestamped lookup result for rollback.
- Source baseline: List known senders, identifiers, alignment results, and typical report volume.
- Commercial status: Confirm the old platform's end date, data export options, and account owner.
- Success gate: Define who confirms new data, who authorizes removal, and what triggers rollback.
|
|
|
|---|---|---|
Domain | Apex name | Sets change scope |
Policy | p, sp, pct | Prevents policy drift |
Reports | rua and ruf | Preserves routing |
Baseline | Sources, volume | Supports comparison |
Owner | Person, window | Controls execution |
Compact migration register fields for each client domain.
Do not rely on the old dashboard alone. Export the available historical data, source classifications, notes, and client-facing reports before access ends. Parsed aggregate data usually cannot be imported cleanly into a new platform because each platform stores and groups sources differently. Keep the export as a read-only archive and establish a fresh baseline in the new system.
Six-step MSP process for migrating DMARC report delivery without a visibility gap.
Onboard and validate the new reporting destination
Create the MSP organization structure before the first DNS edit. In Suped, that means adding each client organization and domain, assigning access, setting notification recipients, and confirming the reporting address supplied for that domain. The multi-tenant view keeps domain status and email volume visible without mixing client ownership. The broader DMARC for MSPs workflow also covers client separation and repeatable service delivery.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Check the reporting destination exactly as shown in the new platform. A DMARC aggregate address uses a mailto URI in the rua tag. When reports go to a domain outside the protected domain, receivers check external destination authorization. A reporting platform normally publishes that authorization on its own reporting domain, but the MSP should still confirm onboarding has completed before changing client DNS.
Suped's DMARC monitoring gives the service desk parsed aggregate data, source views, issue detection, and steps to fix. Configure real-time alerts and weekly summaries for the MSP team rather than a single technician. This prevents a migration alert or new unauthorized source from depending on one person's inbox.
Ready for DNS change
- Domain added: The correct client organization owns it.
- Address copied: The platform-provided rua value is exact.
- Access tested: MSP roles and notifications work.
Pause the change
- Ownership unclear: Client or DNS approval is missing.
- Record incomplete: Current tags or rollback value are unknown.
- Destination uncertain: The new report address is unverified.
Run an overlap instead of a hard cutover
DMARC permits multiple aggregate reporting URIs in rua, separated by commas. Add the new URI after the old one and preserve every unrelated tag. The example domains below are placeholders. Use the exact destination supplied by each platform, and publish the value as one valid TXT record even if the DNS interface displays it as multiple quoted strings.
Before migrationDNS
v=DMARC1; p=quarantine; rua=mailto:a@old.example; pct=100
During reporting overlapDNS
v=DMARC1; p=quarantine; rua=mailto:a@o.ex,mailto:a@n.ex; pct=100
Before saving, compare the proposed record with the captured original character by character. Only the rua value should change. Some DNS control panels add quotation marks automatically, and some split long TXT values into chunks. That presentation is acceptable when the resulting DNS lookup returns one continuous DMARC value. A second DMARC TXT record at the same name is not acceptable because receivers can treat multiple records as a permanent error.
Cloudflare DNS editor showing one DMARC TXT record with two aggregate report destinations.
Validate the public result after the change. Check that there is one DMARC record, the syntax parses, both rua destinations remain present, and the enforcement tags match the baseline. A cached lookup can show the old value until TTL expiry, so save the authoritative result and the time observed in the ticket.
Handle ruf separately if the current record requests forensic reports. Preserve it during the aggregate reporting migration unless the client has approved a privacy and retention change. Many receivers do not send forensic reports, and their content can contain message-level data, so confirm that the new destination supports the client's handling requirements before altering that tag.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Use the DMARC checker to capture a parsed result in the change record. A syntactically valid record proves publication, not report delivery. Receivers generate aggregate reports on their own schedules, often in daily batches, so the operational gate comes later when the new platform has received data.
If the checker shows the new value but Suped remains empty after representative mail and normal reporting cycles, verify domain onboarding, the copied destination, external authorization, and whether the expected receivers send DMARC aggregate reports. Keep the old URI active while investigating. An empty dashboard is not evidence that the client's senders stopped operating.
Rollback on DNS damage
Restore the captured record if the DMARC lookup fails, a policy tag changed unexpectedly, or the zone contains multiple DMARC records. Do not wait for reports when the published record itself is invalid.
Compare report coverage before retiring the old platform
Keep both destinations active until the new platform receives reports across multiple reporting cycles and the expected high-volume sources appear. Do not require byte-for-byte equality between dashboards. Receivers can send to one authorized destination and not another, reports can arrive late, and platforms group sources differently. Compare coverage and trends rather than exact totals.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Review the largest known senders first, then inspect unfamiliar sources, SPF and DKIM alignment, policy disposition, and receiver coverage. For low-volume domains, a fixed number of days is a weak gate because the client may not send during that period. Wait until representative business mail has flowed, including scheduled billing, support, marketing, or line-of-business systems that send less frequently.
- Volume coverage: The new platform shows a plausible range against the saved baseline.
- Source coverage: Major approved senders and known intermittent systems have appeared.
- Receiver coverage: Reports have arrived from more than one relevant mailbox provider.
- Issue review: New failures and unverified sources have owners or documented decisions.
- Client approval: The service owner accepts the evidence and cutover date.
Suped is the best overall practical choice for most MSP teams because the multi-tenant dashboard, automated issue detection, steps to fix, real-time alerts, and client reports support the work after ingestion. It also brings DMARC, SPF, DKIM, blocklist monitoring, and deliverability insights into one operational view. Those capabilities matter when the migration becomes a recurring managed service rather than a one-time DNS task.
Remove the old destination and close the change
Once the acceptance gate is met, remove only the old rua URI. Preserve the new URI and every policy or alignment tag. Validate the final record again, then continue watching report volume and source coverage. Keep the old account available briefly if the contract permits because late aggregate reports can still arrive there after the DNS change.
After migrationDNS
v=DMARC1; p=quarantine; rua=mailto:a@new.example; pct=100
Close the MSP ticket with the before, overlap, and final DNS values; lookup evidence; timestamps; report coverage; approver; rollback record; and old account retirement date. Convert unexpected sources into tracked remediation work rather than leaving them as migration notes. Client reporting should explain authorized volume, authentication health, blocked threats, open issues, and next actions without attaching raw XML. The client reporting workflow provides a repeatable structure.
Use hosted controls after the cutover
After reporting is stable, consider Hosted DMARC as a separate approved change. Suped can stage policy management without combining that decision with the initial reporting migration.
For larger MSP estates, migrate in waves. Start with internal or cooperative clients, then move a small representative group before scheduling the remaining domains. Reuse the register, change template, validation evidence, and acceptance gate. This limits concurrent support risk and makes any problem easier to isolate to a DNS provider, client process, or onboarding step.
Move clients without losing visibility
A controlled DMARC reporting migration uses parallel rua delivery, unchanged enforcement, public DNS validation, and evidence-based acceptance. The MSP should preserve historical exports, confirm representative senders in the new platform, remove only the old destination, and keep a complete change record. Suped then gives the operations team one place to monitor authentication health, investigate issues, manage multiple client organizations, and produce useful client reports after the cutover.
