Why Abandoned DMARC Reporting Endpoints Are a Security Risk

When you set up DMARC, you tell receiving mail servers where to send your aggregate reports by publishing a rua=mailto: tag in your DNS record. That tag points to an email address or a domain you control. Most organizations point it at a third-party DMARC monitoring service, a personal Gmail address, or an old domain they no longer actively use.

That destination matters more than most people realize.

If the domain in your rua tag expires, someone else can re-register it. From that moment, your aggregate reports go to a stranger. This is not a theoretical risk. It has happened.

What DMARC aggregate reports actually contain

Your DMARC aggregate reports are XML files sent daily by every receiving mail server that processes mail from your domain. Each report contains:

• the sending volume per mail server IP
• which IPs passed or failed SPF and DKIM
• which failures were alignment failures versus authentication failures
• the MX and from addresses used by servers receiving your mail

This data is competitively sensitive. A competitor who receives your aggregate reports can see roughly how much email you send, which service providers you use, which ESPs route your marketing mail, and which of your IPs are sending high volumes. That is useful intelligence for someone with commercial interest in your operations.

It is also a privacy problem. Your own internal sending patterns are exposed.

The attack scenario

The attack is simple. You publish:

v=DMARC1; p=reject; rua=mailto:reports@example-dmarc.com; pct=100;

Three years later, you stop paying for example-dmarc.com. It expires. A researcher or a competitor spots it, registers it, and starts receiving your daily aggregate reports. Unless you have specifically set up receiving authentication on that address, anyone can send to it and receive your reports.

This is not a hypothetical. In 2024, research published by the Global Cyber Alliance documented multiple cases where DMARC reporting endpoints had been abandoned and their aggregate report data was flowing to untrusted parties. Separate work by Georgia Tech confirmed the same pattern across a large sample of DMARC records.

The timeline makes this worse than it sounds. DMARC aggregate reports arrive daily. A domain that expired six months ago may have been sending reports for six months without the domain owner's knowledge. You have no way to know unless you check.

How to audit your DMARC reporting endpoints

Audit every rua URI in your DMARC record. Run this in a shell:

dig TXT _dmarc.yourdomain.com +short | grep -oP 'rua=[^ ;]+'

Extract each mailto: or https: URI. For each one:

1. If it is a mailto: address, check the domain part. Is it still registered? Is it pointed at an inbox you actively monitor?

2. If it is an https: URI pointing to a third-party service, confirm the service account is still active and paid.

3. For any domain-based URI, run a WHOIS lookup on the domain. Check the expiry date. Check the registrar. If you do not recognize the registrar or the domain is within 90 days of expiry, treat it as at risk.

4. Check your DNS resolution for the domain. Does it still resolve? If not, reports are being dropped silently.

If you find a stale endpoint, update your DMARC record immediately. Remove the dead URI and replace it with an active one. Monitor the new endpoint to confirm reports arrive.

One practical way to manage this continuously: use a DMARC monitoring service that handles endpoint stability for you. DMARCFlow maintains its own reporting infrastructure, so you do not need to track domain expiry dates or worry about abandoned inboxes. You get reports consistently without the maintenance burden.

What makes a reporting endpoint trustworthy

The best reporting endpoint is one you do not have to think about. That means:

• The receiving domain is stable and actively managed
• The service has been around long enough that abandonment is unlikely
• Someone is actively receiving and reviewing the reports

A free email address on a personal domain you might abandon next year is not a reporting endpoint you can trust over a multi-year period. Neither is a DMARC analyzer you signed up for once and forgot about.

FAQ

Can someone hijack my DMARC reports by re-registering my old domain?
Yes. If your rua URI points to an expired domain, whoever re-registers that domain will start receiving your aggregate reports. They cannot send mail as your domain, but they receive your sending volume data. This has been documented in real-world cases.

How often should I check my DMARC reporting endpoints?
At least once a quarter. Check whenever you change DNS providers, change your email service, or let a domain expire. Set a calendar reminder 30 days before any domain in your DMARC record expires.

What does a DMARC aggregate report actually tell the recipient?
It shows sending volume, IP addresses, SPF and DKIM pass/fail rates, and alignment results for every server that processes mail from your domain. It does not show email content, but it reveals your sending infrastructure and volume patterns.

I set up DMARC and now I am not getting reports. Is that a problem?
It can be. Some receivers do not send reports at all, which is normal. But if you previously received reports and they stopped, your rua endpoint may have broken silently. Check your DNS record, check the receiving address, and check whether your monitoring service is still active.