What Happens When Your DMARC Reporting Service Shuts Down

A trusted DMARC reporting service went dark. Domains that had pointed their rua DNS record at this endpoint suddenly had no visibility into DMARC failures. Reports stopped arriving. Their DMARC policy still published, but they were flying blind.

No warning. No notification. No obvious sign anything had changed until someone happened to check why their aggregate reports had gone quiet for weeks.

This is what happened to at least 86 domains when the Global Cyber Alliance's DMARC reporting endpoint, gca-emailauth.org, expired. Those domains had been sending DMARC reports to an address they did not own, through infrastructure they did not control. When it disappeared, they did not know.

The core problem: the rua address in your DMARC record points to someone else's server. When that server goes away, you lose visibility. Your DMARC policy keeps running, but you have no idea what it is seeing.

What the DMARC rua Address Actually Is

The rua tag in a DMARC record tells receivers where to send your aggregate reports. It looks like this:

v=DMARC1; p=quarantine; rua=mailto:reports@your-dmarc-provider.com

That address is not yours. It belongs to the service you pointed it at. When you use a third-party DMARC tool, you are renting their endpoint. If they shut down, change their domain, or let it expire, your reports go nowhere.

Three things happen at once when an endpoint is abandoned:

New reports have nowhere to go. They are discarded or bounced.
Historical reports are gone. Most services do not hand over data when they close.
You do not get told. There is no standard mechanism to notify rua addresses when a service stops accepting mail.

The DNS ownership is the critical part. If the vendor owns the hostname in your rua record and lets it expire or reassigns it, your reports start going to whoever now controls that address. Neither outcome is acceptable for security-sensitive data.

Why an Abandoned Endpoint Is a Security Problem

Without DMARC reports, you cannot see when your domain is being spoofed. That is not a minor inconvenience -- it is a visibility failure at the centre of your email security posture.

Here is what disappears when your rua endpoint goes dark:

Spoofing attempts against your domain, including phishing campaigns using your brand
Alignment failures from legitimate senders you did not know were misconfigured
Third-party services generating DMARC failures because they are using the wrong sending domain
Evidence of whether your DMARC policy is actually blocking the mail you want it to block

The risk is highest for domains running p=none. If your policy is set to none because you have not reviewed your reports yet, you are relying entirely on those reports to catch abuse. When they stop arriving, you have no way to know your domain is being used in spoofing campaigns.

The gca-emailauth.org shutdown showed this exact pattern in the real world: domains that had been quietly monitoring DMARC suddenly had no idea what their policy was seeing.

How to Check If Your DMARC Reporting Endpoint Is Abandoned

Run through these steps to assess your current risk.

Step 1: Look up your DMARC record

dig _dmarc.yourdomain.com TXT

Find the rua entry. It will look like one of these:

rua=mailto:reports@example.com rua=https://dmarc.example.com/your-account-id

Step 2: Check who owns the hostname

For a mailto address, the domain after @ is what matters. For a URL, look at the hostname. Run a whois on that domain:

whois example.com

Check the expiration date. If it has recently expired or expires soon, your endpoint is at immediate risk.

Step 3: Verify the service is still accepting reports

Try accessing the URL in your rua record. Try sending a test message to the mailto address. If nothing happens or the domain does not resolve, your reports are not going anywhere.

Step 4: Compare recent report delivery to historical patterns

If you have been receiving DMARC aggregate reports on a regular schedule, check whether the most recent ones actually arrived. If they stopped without any change to your DNS configuration, your endpoint is likely abandoned or broken.

How to Protect Yourself From Vendor Shutdown Risk

The durable fix is owning your DMARC reporting infrastructure.

Run your own DMARC reporting endpoint

Point the hostname in your rua record at infrastructure you control. This means hosting your own report receiver on a server or cloud instance you manage. When the endpoint is yours, a vendor shutting down cannot take it offline.

DMARCFlow is built for this. It receives and parses your DMARC aggregate reports, giving you a clean view of authentication failures and spoofing attempts. Running it on your own infrastructure means no third party can strand your reporting.

If you use a third-party service, know your exit path before you need it

Before you commit to a DMARC reporting vendor, write down exactly what your DNS record needs to change to if they disappear. The best time to document the migration path is when everything is working fine, not after the service has gone.

Point your rua at two endpoints if your platform supports it

Some DMARC platforms accept multiple rua addresses. Use a second endpoint on infrastructure you control as a backup. If the primary vendor goes dark, your backup keeps receiving reports.

Verify the new endpoint before removing the old one

When you migrate, update the DNS record first and confirm reports are arriving at the new destination before you stop sending to the old one. The order matters: add, confirm, then remove.

Use a dedicated subdomain for DMARC reporting

Create a subdomain like dmarc-reports.yourdomain.com and point your rua at it. This keeps your reporting infrastructure separate from your main email domain, making it easier to monitor and maintain independently.

Frequently Asked Questions

Can I change my DMARC rua address without breaking my policy?

Yes. Changing the rua address does not affect your DMARC enforcement. Your p=reject or p=quarantine setting stays active. The rua address is purely for receiving reports and has no effect on whether emails pass or fail DMARC checks.

What happens to historical DMARC reports when a vendor shuts down?

In most cases, nothing. Third-party DMARC services typically do not export or transfer historical aggregate reports when they close. Once the service is gone, the data is gone. This is one of the strongest arguments for running your own infrastructure: you do not lose history when a vendor disappears.

How do I migrate DMARC reports to a new service without losing visibility?

Update your DNS DMARC record to point the rua at your new service, then monitor your new endpoint for incoming reports. Keep the old endpoint active until you have confirmed reports are arriving at the new one. Most migrations complete without any gap if done in this order.

Is it safe to point DMARC reports at a free email service?

It is technically possible but comes with tradeoffs. Free email services can change their policies on automated report processing, may filter or discard high-volume aggregate reports, and may close the receiving address if the account is closed or inactive. For anything beyond basic monitoring, a dedicated or self-hosted solution is more reliable.

The Bottom Line

The gca-emailauth.org shutdown was not an isolated incident. It was a demonstration of what happens when you depend on infrastructure you do not own for something as critical as email security visibility. The domains affected did not know their reports had stopped until someone published what had happened to them.

The fix is straightforward in principle: own the endpoint your DMARC records point to. Run your own report receiver or use a service where you control the infrastructure. Verify reports are arriving. Document what you would do if your current vendor disappeared tomorrow.

Because they do disappear. And when they do, you will not get a warning.

DMARCFlow gives you a self-hosted way to receive and make sense of DMARC aggregate reports. If you want to stop depending on a vendor whose endpoint can vanish, that is where to start.