Introduction

An email migration can move live mail flow successfully while DMARC reports still go to the old provider. Sending and receiving may already work on the new platform, but aggregate or forensic reports continue landing in a legacy mailbox or vendor portal because the reporting destination in the DMARC record was never updated.

Treat this as a reporting-destination problem instead of a mail-delivery failure. Start by checking the exact rua and ruf targets published in DNS, because post-migration visibility often breaks when authentication reporting still points to the previous provider even after production mail has moved.

Symptoms

  • DMARC reports still go to the old provider after email migration
  • Mail flow works on the new platform, but DMARC visibility remains tied to the previous vendor
  • Aggregate reports arrive in an old mailbox, old platform, or retired reporting service
  • Security teams lose reporting visibility after the migration even though email still works
  • One domain still reports to the old destination while another migrated domain is already correct
  • The issue started after provider switch, mailbox cutover, or DNS cleanup

Common Causes

  • The DMARC record still contains old rua or ruf destinations
  • The migration updated MX and SPF but did not update reporting endpoints
  • A third-party reporting address was left in place after the old provider was retired
  • The new provider does not own the mailbox or service that still receives the reports
  • Teams validated live mail delivery but not post-cutover reporting visibility
  • Multiple domains share similar policy templates, and only some were updated

Step-by-Step Fix

  1. Check the live DMARC record for the affected domain and record the exact rua and ruf destinations it publishes, because the real reporting target must come from DNS rather than from migration notes.
  2. Compare those report destinations with the intended post-migration monitoring mailbox or service, because DMARC visibility often remains tied to the previous provider after mail flow has already moved.
  3. Confirm whether the old reporting mailbox, vendor portal, or parser service is still active, because that reveals whether reports are merely misrouted or fully inaccessible.
  4. Review related domains or subdomains that were migrated in the same project, because DMARC reporting targets are often copied from shared templates and missed during cleanup.
  5. Update the DMARC reporting addresses at the real authoritative DNS source, because moving only mailbox hosting will not change where DMARC reports are sent.
  6. Verify the destination mailbox or service on the new side is ready to receive and process reports, because changing the record without a working target creates a second monitoring gap.
  7. Recheck the live DMARC record after propagation and confirm it now publishes the intended new reporting destination, because cached assumptions are common after DNS edits.
  8. Monitor new reporting arrivals and verify DMARC visibility now exists on the post-migration platform, because the real fix is usable reporting rather than just a corrected TXT record.
  9. Document the final DMARC reporting endpoints for each migrated domain, because authentication-reporting paths are easy to overlook during future email platform changes.