The Hidden Risk in Your DMARC Setup: What Happens When a Reporting Endpoint Expires

In March 2025, the Global Cyber Alliance let one of its DMARC reporting domains expire. The domain, emailauth.org, had been listed as the rua destination for at least 86 domains. Someone re-registered it and began receiving their aggregate reports.

No breach notification went out. No alarm triggered. The domain simply expired, like domains do, and someone else picked it up.

This is not a hypothetical attack. It is a documented incident that reveals a structural risk in how most DMARC deployments handle reporting. And the fix is not complicated, but it requires understanding why the risk exists in the first place.

Why DMARC Aggregate Reports Are Unverified

When you set a DMARC policy with an rua tag, your receiving servers send aggregate reports to whatever hostname you specify. The protocol looks like this:

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

Your receiving infrastructure sends DMARC aggregate reports to reports@example.com without verifying that the recipient actually owns the domain in the email address. There is no authentication on the rua destination the way there is on the sending side.

This is by design. DMARC was built to work with third-party monitoring services. If you wanted to use dmarcian or EasyDMARC, you pointed your DMARC record at their domain, and they collected your reports. That is how the ecosystem works.

The problem arises when a third-party domain expires and gets re-registered by someone else. Your reports do not stop. They keep being sent. And whoever controls the domain at that moment receives them.

This is the core risk. The solution is to use a reporting endpoint under a domain you control. Tools like DMARCFlow are designed around this principle: you maintain ownership of the domain infrastructure, and the monitoring layer sits on top of that. The domain stays yours, the renewal stays yours, and no third-party expiry can hand your report data to someone else.

What an Attacker Can Do With Your Aggregate Reports

DMARC aggregate reports are not the same as message content. They do not include email bodies or subject lines. But they contain enough to map your email infrastructure:

• Every IP address that sends email on behalf of your domain
• Which messages passed or failed DMARC, SPF, and DKIM checks
• The nameservers and MX records for your domain
• Patterns in your email volume and sending patterns over time

An attacker with access to your aggregate reports can build a precise map of your email infrastructure, identify gaps in your SPF or DKIM configuration, and use that intelligence to craft emails that bypass your filters. That is reconnaissance with a purpose.

In the GCA incident, the person who re-registered emailauth.org documented what they found: 86 domains, their sending infrastructure patterns, their mail volumes, their failure rates. All without any of those organizations knowing.

How to Check If Your Reporting Endpoint Is at Risk

The question to ask is simple: does the hostname in your DMARC rua tag belong to you?

Look at your current DMARC record. If it looks anything like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@dmarc-vendor.example.com

...and dmarc-vendor.example.com is not a domain you own and pay for directly, you are relying on that vendor to keep the domain active, secure, and under their control.

If your rua tag points to a free DMARC monitoring service, the risk is the same: you do not control the domain, you cannot force a renewal, and you may not even receive a notification if the service changes hands or the domain lapses.

The Secure Solution: Use a Reporting Endpoint Under Your Own Domain

The most direct fix is to receive DMARC reports at a hostname you control. Instead of pointing your DMARC record at a third-party domain, set up a dedicated subdomain under your own infrastructure:

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

Your own IT team manages the domain renewal, controls who has access to the reports, and eliminates the third-party expiry risk entirely.

This requires some email infrastructure setup: the receiving endpoint needs to accept the reports, store them, and make them accessible for analysis. That is where dedicated DMARC monitoring tools become relevant.

How DMARCFlow Handles This

DMARCFlow is built around the principle that the domain receiving your DMARC reports should be a domain you own. Rather than asking you to point your DMARC record at a shared DMARCFlow domain, the service receives your aggregate reports at an endpoint under your own domain. You maintain control of the domain infrastructure. DMARCFlow processes the reports and provides the analysis layer, but the domain relationship stays with you.

This means your DMARC reporting endpoint does not expire because a third party forgot to renew. It does not get re-registered by someone who scooped up an expired domain. The infrastructure you rely on is the infrastructure you own.

For organizations running DMARC across multiple domains, this also simplifies management: reporting endpoints stay under your own DNS regardless of how many domains you monitor. Each domain maintains its own reporting domain, and DMARCFlow correlates the data across your portfolio.

Audit Checklist for DMARC Administrators

Run through these questions:

• What domain is listed in your DMARC rua tag? Is it a domain you own and directly renew?
• If you use a third-party DMARC monitoring service, when did you last confirm the reporting domain is still registered and under their control?
• Do you receive regular DMARC aggregate reports, or have they silently stopped arriving?
• Who in your organization would notice if your DMARC reporting domain suddenly started delivering reports to an unfamiliar address?
• Have you audited which third-party services have your DMARC reporting hostname configured?

FAQ

Can someone really register an expired DMARC reporting domain? Yes. In a documented case, the Global Cyber Alliance's emailauth.org domain expired and was re-registered by a third party who then began receiving aggregate reports from 86 domains. There is no protocol-level protection preventing this.

What information do DMARC aggregate reports contain? Aggregate reports (XML format, delivered via SMTP) include: the sending IP, the domain reportedly sending, the result of SPF/DKIM/DMARC checks, the message count, and policy disposition. They do not include email body content or headers.

How do I check if my DMARC reporting endpoint is secure? Look at your DMARC record's rua tag. If the hostname belongs to a third party you do not directly control, you are relying on their domain management practices. Contact the vendor to confirm their domain renewal process.

Is using a third-party DMARC monitoring service risky? Not inherently. The risk is specifically around domain expiry. Established services generally manage their domains carefully. The risk becomes real when smaller services shut down, get acquired, or simply forget to renew.

What is the best practice for DMARC reporting endpoints? Use a hostname under a domain you control. Keep the domain renewal cycle short enough that an oversight does not create a gap. Monitor your report delivery to catch interruptions quickly.

DMARC aggregate reports are a critical source of visibility into your email security posture. Keep the infrastructure that delivers them under your own control.