DMARC Reporting Provider Shuts Down

Your DMARC reporting provider just told you the service is going away. Maybe they sent a sunset email. Maybe they got acquired and the new owner is consolidating platforms. Maybe support has gone silent for two weeks and the credit card charge last month came from a different company. Either way, the trend dashboards you have used for the last two years are about to disappear, and the question is what you do about it.

This is a continuity problem, not a security problem. The good news is the data is not actually locked inside the vendor, because the rua tag in your DNS record points at an endpoint you can repoint. The bad news is what you do not pull out before the lights go out is gone for good. The five-step playbook below works the same way whether you move to DMARCFlow or somewhere else, and DMARCFlow is built specifically to make that move boring: hosted RUA archival, a documented XML export, and a multi-value rua path so the cutover does not leave a 24-hour gap in your reports.

How do I tell my DMARC reporting provider is at risk?

A shutdown rarely comes out of nowhere. The signs usually show up months earlier.

Watch for a quiet change in the company's invoicing entity, especially when the previous vendor was sold to a larger platform and the invoice now arrives from a different legal name. Watch for plan emails that say "we are simplifying our tiers" or that quietly drop the lowest-cost plan you are on. Watch for support response times stretching from hours to days. Watch for "community" announcements that the team is "exploring options" or "evaluating feedback" without committing to a roadmap. Watch for blog posts that switch from "shipping" to "we are pausing new work".

A stable provider tends to have the opposite signals: a clear corporate parent you can look up in a Handelsregister or Companies House lookup, transparent pricing that has not changed in two years, and a public changelog that shows ongoing work. None of this is a guarantee, but the pattern is usually visible long before the shutdown email lands.

What data is at risk when your provider goes away?

There are four buckets of data, and only two of them are likely to be recoverable.

The raw RUA XML is the most valuable. It is the original aggregate report files that receiving mail servers send to your rua tag. Most hosted providers archive these by default. If the provider exposes an export feature, this is what you want first, because every other bucket is derived from it. The native format is XML, one file per report, often gzipped, and a clean export should let you re-import into any other provider that accepts standard XML. DMARCFlow exposes this exact archive export out of the box, which is one reason it is a safe landing pad during a vendor transition.

The RUF forensic data is rarer. Not every provider collects it, and not every organisation enables it. If you have it, export it. It contains per-message failure samples that RUA does not, and it is harder to find another source for once it is gone.

The dashboard history is what most users think of as "my data", but it is the least recoverable. A line chart showing SPF failure rates over 18 months is just a rendering of the underlying XML; once the vendor is gone, you usually cannot get back the exact same chart from a different provider unless you re-import the raw XML and wait for the new tool to re-aggregate it.

The alert rules and integrations are the easiest to lose and the easiest to recreate. Webhook URLs, Slack channel bindings, saved filters - they are typically stored per-customer and not exportable. Plan to recreate these in your new provider and accept that the old URLs will stop working on the day of cutover.

A 5-step migration playbook

The cutover itself is rarely the hard part. The hard part is doing it without a 24-hour gap where reports vanish. Here is the order that works.

Step 1: Export the raw RUA XML now, before anything else. Do not wait for the official "data export" feature if it does not exist yet. Open a support ticket the same day you suspect a shutdown. Most providers will give you a tarball of historical XML if you ask. Some will not respond; if you do not get a useful answer within a week, treat the data as gone.

Step 2: Stand up the new provider in parallel. Point a test subdomain at the new provider's rua endpoint, add a second rua value to your DMARC record (the standard DMARC rua tag accepts comma-separated mailto URIs, so you can run both vendors at once), and let it collect for two weeks. A line in your DMARC record looks like v=DMARC1; p=reject; rua=mailto:old@example.com,mailto:new@example.com. Receivers will send to both. This gives you a continuity window where both vendors see the same reports and you can verify the new tool is receiving what it should.

Step 3: Re-import the old XML into your new provider. A provider that accepts standard XML backfill lets you keep the trend line going back to the day your old account was created. DMARCFlow does this with a standard XML upload; other tools vary, and some will only show what they have received since your account was created. Confirm the import format before you commit to the migration - this single step decides whether your historical continuity survives the cutover.

Step 4: Swap the rua tag. Once you trust the new provider's data, replace your DMARC record so only the new endpoint remains. Do not delete the old record first; receivers retry for a few days, and a missing endpoint can generate false DMARC failures in your own reports.

Step 5: Decommission the old account last. Keep the old login active for at least 30 days after cutover. The day you need a specific XML file to debug a deliverability complaint is the day you will be glad you did not close the account too soon.

For a single domain and a clean export, this whole process takes a working afternoon for the DNS work, plus the two-week observation window. The two-week parallel collection is what most teams skip, and it is also what most teams regret skipping when they later notice a gap in the trend chart.

How do I stop this from happening again?

The cycle is avoidable if you treat your RUA data as something you own rather than something your vendor stores for you.

Pick a self-archival habit and keep it. A simple one works: every Monday, download the previous week's RUA XML files from your provider's archive, drop them in a folder synced to a cloud storage account you control, and let them accumulate. After a year you have a complete record that survives any vendor change. A more elaborate version uses a small script that pulls XML files automatically into S3, Backblaze, or a NAS, but the manual version is fine to start with. The point is not the storage - it is that you have a copy that does not require a vendor login to read.

Pick a vendor whose archival policy is written down. A provider that can tell you, in plain language, what happens to your data if they get acquired or shut down is a provider worth paying more for. A provider that cannot answer the question is one whose service you should not depend on for trend continuity. DMARCFlow's archive export is one example of what a written answer looks like; look for the same thing from any vendor you evaluate.

Keep your DMARC record editable. If changing the rua tag requires a support ticket, that is a vendor lock-in you cannot afford. The rua tag should be a DNS record you can edit yourself, on a domain you control, with values that point to endpoints you can swap in under an hour.

What a replacement vendor should look like

Three concrete signals separate a vendor you can plan a multi-year reporting history around from one that will leave you doing this migration again in two years.

The first is a corporate parent you can look up in a public registry. DMARCFlow is operated by Ucar Solutions UG, a German company registered in Hofheim am Taunus. You can verify that in the Handelsregister; it is not a marketing shell. A vendor that cannot tell you who their parent company is, or whose parent changes every eighteen months, is a vendor whose customers will be doing this migration on a loop.

The second is pricing that has not moved in two years. DMARCFlow's entry price has been 1 EUR per month since launch. A vendor that has raised prices twice in the last 24 months, or that has changed which features sit behind which tier, is signalling that they are still figuring out their business model. You do not want to be a customer while they figure it out.

The third is a documented archival policy. DMARCFlow exposes historical RUA XML through an archive export, so the raw data is never trapped inside the vendor. The DMARC record itself stays on your DNS, so the rua tag is yours to edit at any time without a support ticket. If a vendor cannot tell you, in writing, how you would get your raw XML out if they shut down in six months, treat that as an answer.

How DMARCFlow handles this specifically

The migration playbook above describes exactly what a DMARCFlow-to-DMARCFlow move looks like, because the steps are the same whether you move to DMARCFlow or somewhere else. The export you need is documented. The XML re-import is supported. The two-week parallel collection is supported via the standard DMARC rua multi-value syntax, no proprietary workflow required. The decommissioning window is just leaving the old account active for 30 days.

The reason DMARCFlow is a natural landing pad for this exact situation is operational rather than dramatic. Hosted in Germany under a stable parent company, with EU data residency, an archive export that gives you raw XML on demand, and a 1 EUR entry price that has not changed since launch. None of those are guarantees of permanence, but they are the kind of stable signals that point in the right direction.

If your current DMARC reporting provider is showing the warning signs above, or if you do not have a reporting provider at all, point a test subdomain at DMARCFlow, run the parallel collection for two weeks, and decide for yourself whether the trend continuity is worth the switch.

Frequently asked questions

Can I import my old RUA XML files into a new DMARC reporting tool?
Most hosted providers accept standard XML backfill. DMARCFlow does, and a handful of other tools do as well. Check the new provider's documentation before you commit to the migration, because some tools only show data they have collected themselves and there is no way to recover historical charts once you have cut over.

How long does a clean DMARC reporting cutover take?
The hands-on DNS and export work is an afternoon. The two-week parallel collection is what most teams skip, and it is also what gives you confidence that nothing falls into a gap. Plan two weeks end-to-end, not two hours.

Is there a way to get my data out of a DMARC vendor that has shut down?
Usually no. If the company is gone, the data is gone with it. This is the scenario the self-archival habit is designed to prevent, and the reason to start that habit now rather than waiting for a shutdown notice.

Should I self-host RUA collection instead?
You can run your own by pointing your rua tag at an SMTP endpoint that writes XML files to disk. There is nothing magical about hosted RUA collection. The trade-off is operational: you take on the responsibility of uptime, retention, parsing, and disk space planning. For most small teams, a hosted provider with a clear archival policy is less risky than a self-hosted setup that nobody is watching. For larger teams with strict data-residency requirements, self-hosting can be the right answer if someone has the time to maintain it.

Can I keep both vendors running indefinitely?
Yes. The DMARC rua tag accepts multiple mailto URIs separated by commas, and receiving mail servers will send to all of them. The cost is duplicate processing on the receivers' side and slightly more inbound mail volume for you, but it is a clean way to evaluate a new provider without committing to the cutover.