What Happens When Your DMARC Reporting Domain Expires

The Global Cyber Alliance operated emailauth.org as a free DMARC reporting endpoint. Organizations pointed their DMARC DNS records at it to receive aggregate reports about email authentication results. The domain expired. Someone else registered it. Now whoever owns emailauth.org receives all the aggregate reports those 86 domains are still sending to that address. This is not a hypothetical risk scenario. It happened.

What DMARC aggregate reports actually contain

Aggregate reports are not the same as forensic reports, but they reveal plenty. A DMARC aggregate report (sent to the rua tag in your DNS record) includes: - The IP address of every mail server that delivered mail claiming to be from your domain - The volume of messages sent from each IP - Whether each message passed SPF, DKIM, and DMARC alignment checks - Forwarding chains and mailing list identifiers where detectable Someone collecting those reports for your domain learns who is sending email on your behalf, how much email you send, which partners route your mail, and where your DMARC policy is generating failures. The most practical protection is to use your own domain for reporting. DMARCFlow lets you bring your own subdomain for aggregate report collection, so the data goes to infrastructure you control rather than a third party that might change hands. That is the most direct fix for the underlying problem the gca-emailauth.org incident exposes.

Why the gca-emailauth.org incident matters

It was a trusted endpoint. GCA was not a random free service. It was a known organization offering a free reporting endpoint to lower the barrier to DMARC adoption. Organizations used it because they trusted the source. The domain was abandoned, not transferred. The GCA emailauth.org domain appears to have simply not been renewed. When a domain expires and is not renewed, it becomes available for anyone to register. There is no automatic notification to organizations sending reports there. The reports kept flowing. DMARC aggregate reports are sent automatically by receiving mail servers. The 86 domains using gca-emailauth.org had no idea the destination was no longer under GCA's control. 86 domains were affected. That is not a rounding error. Dozens of organizations whose internal email volume, sending patterns, and partner domains are now known to an unknown party.

How to check if your DMARC reporting domain is at risk

Run through these questions:

What domains are in your DMARC record? Look at the rua and ruf tags in your DMARC DNS record. Each destination domain listed there receives your aggregate or forensic reports.

v=DMARC1; p=none; rua=mailto:reports@dmarc.example.com

In this example, dmarc.example.com receives the aggregate reports. If you do not own or control that domain, you are trusting a third party with your email traffic data. Who operates the reporting domain? If you use a third-party DMARC monitoring service, find out what domain they ask you to add to your DMARC record. That domain is where your data goes. Make sure it is still registered and still operated by the company you think operates it. Are you using a subdomain you control? The safest setup is a subdomain you own, pointing to a server or service you control. For example, dmarc.yourcompany.com rather than reports.thirdpartyvendor.com.

How to protect your DMARC reporting data going forward

The fix is architectural. Instead of sending your reports to a third-party domain you do not control, route them to infrastructure you own.

Use your own subdomain for DMARC reporting. Set up a receiving endpoint on a subdomain you control. In your DMARC record:

v=DMARC1; p=none; rua=mailto:reports@dmarc.yourdomain.com

Reports go to your servers. If you use a commercial DMARC monitoring service, configure them to pull from your endpoint rather than having reports delivered to their domain directly. DMARCFlow's architecture is built around this: you bring the subdomain, DMARCFlow processes the data, you retain control.

Choose vendors with clear data retention and ownership policies. If you use a DMARC monitoring service, read their terms carefully. Some services operate shared reporting domains that many customers use. Make sure you understand who owns the data, how long they keep it, and what happens to it if the service shuts down.

Monitor your reporting endpoints. Set a recurring task to verify that the domains in your DMARC record still resolve and are still registered to the right party.

What this incident reveals about DMARC tooling choices

DMARC reporting is often treated as an afterthought. But the reporting endpoint is sensitive infrastructure. It receives data about your entire email sending ecosystem.

The gca-emailauth.org incident is a reminder that free services have limits. When the organization providing the free service loses funding, shuts down, or simply fails to renew a domain, your data goes with them. Worse, it may go to whoever registers the domain next.

For organizations that rely on DMARC reporting for security monitoring, the question is not just "do I have reports?" It is "who else has access to these reports, and will that change without my knowledge?"

FAQ

Does DMARC encryption protect my aggregate reports? No. DMARC aggregate reports are sent over ordinary SMTP, unencrypted. The recipient is determined solely by the domain in your DMARC rua record. If that domain is not under your control, whoever receives the reports can read them.

Are forensic reports more sensitive than aggregate reports? Forensic reports (sent to the ruf tag) are more detailed. They include individual message metadata and often sample content. Aggregate reports are volume summaries, but they still reveal significant patterns about your email infrastructure. Both should be treated as sensitive.

Can I use a free DMARC reporting service safely? Only if you control the domain the reports are sent to. If the service asks you to add their domain to your DMARC record, you are trusting them with your data. If they later expire, shut down, or change ownership, your data follows. Use your own domain, and have the service pull from there instead.

What should I do right now? Check your DMARC record. Find every domain listed in your rua and ruf tags. Verify those domains are registered, under your control, and not expired. If you are using a third-party domain you do not own, move to your own subdomain.