What Happens When Your DMARC Reporting Domain Expires (And How to Secure It)

In early 2026, Eden Park, the national stadium of New Zealand, discovered that its DMARC reports had been going to an expired domain for several years. Authentication reports detailing every email sent on behalf of edenpark.co.nz had been delivered to an address nobody at the organization controlled. The domain had lapsed, been re-registered by someone else, and nobody noticed.

This is not an isolated case. A 2024 investigation by the Global Cyber Alliance found 86 domains that had DMARC aggregate reports flowing to an expired reporting address - a domain registered elsewhere, outside the control of the organization generating those reports.

Your DMARC configuration probably has the same problem.

What DMARC Aggregate Reports Actually Contain

Your DMARC aggregate reports (sent to the address in your rua tag) arrive as XML files from receiving mail servers around the world. Each report covers a 24-hour window and contains:

• The IP address of every mail server that tried to send email on behalf of your domain
• Whether each attempt passed or failed SPF, DKIM, and DMARC alignment
• The hostname and organizational domain of the receiving server
• A count of how many attempts were made from each source

That data is valuable. It tells you exactly who is sending email from your domain, whether legitimate mail is passing authentication, and whether you have a spoofing problem you did not know about. It is also, as Eden Park and the GCA findings show, data that can end up in the wrong hands if you do not manage your reporting infrastructure carefully.

Why the Reporting Domain Is Different From Your From Domain

Most DMARC discussion focuses on the From domain - the address your recipients see. But the rua tag points somewhere else, and that distinction matters.

When you set a rua tag like rua=mailto:reports@example.com, you are telling receiving mail servers to send their aggregate reports to example.com. If example.com is a domain you registered for that purpose, and you forget to renew it, the reports keep flowing to whoever registers example.com next.

The From domain in your DMARC record can be completely unrelated to the domain in your rua tag. This is by design - DMARC was built to decouple authentication from reporting. It also means the security of your reporting infrastructure is a separate concern from the security of your sending domain.

The Attack Scenario Is Simpler Than You Think

Here is what an attacker does:

1. They monitor newly expired domains, or use tools that scan for DMARC reports being delivered to abandoned addresses.
2. They register the expired domain.
3. They set up an SMTP listener on that domain.
4. Aggregate reports from mail servers around the world start arriving automatically - no hacking required.
5. They parse the XML, extract the IP addresses of your sending mail servers, and build a map of your email infrastructure.

At that point they know which IPs are authorized to send mail for your domain, which third parties are sending on your behalf, and when your outbound email volume is highest. That is reconnaissance data that costs nothing to collect and is difficult to detect.

This is what happened to Eden Park. It is what the GCA found for 86 domains. The organizations did not get hacked - their visibility into their own email authentication simply leaked, quietly, to an unregistered address.

How to Audit Your DMARC Reporting Endpoints Today

Run through these steps for every domain you manage with a DMARC record.

Step 1: Extract your DMARC record

Find the DMARC record for your domain:

dig TXT _dmarc.yourdomain.com +short

Or use an online DMARC checker. Look for the rua= tag.

Step 2: Identify the reporting domain

The rua tag points to a specific domain. Parse it:

rua=mailto:reports@yourdomain.com

The reporting domain is yourdomain.com.

Step 3: Check the domain registration status

Use whois or a domain checker to see when that domain expires and who the current registrant is. If you do not recognize the registrant, or if the domain is close to expiration, that is a problem worth fixing now.

Step 4: Check whether reports are actually arriving

If you have been expecting DMARC reports and they have stopped, that is a sign your reporting endpoint may have changed state. Set up a check now: send a test email to a known inbox and see if you receive the aggregate report within 24-48 hours.

Step 5: Look for subdomain alignment gaps

If your rua tag points to a parent domain but your From domain is a subdomain, check whether that parent domain is still actively managed. Reports can be routed to a subdomain you control and the parent domain may have lapsed without you noticing.

Best Practices for DMARC Reporting Subdomains

Use a dedicated subdomain for DMARC reporting, not a personal email address or a generic domain you might abandon.

Good example: a subdomain like dmarc.yourdomain.com that you treat as infrastructure and renew for multiple years.

Bad example: a Gmail address or a personal domain you registered for a one-time project and forgot about. Personal addresses get abandoned. Domains get recycled. If either one is in your rua tag, your reports are flowing somewhere you do not control.

Treat your DMARC reporting subdomain like any other critical infrastructure: assign an owner, set renewal reminders 90 days before expiration, and avoid tying it to anything that might become someone else's problem.

If you are using a third-party DMARC monitoring service, confirm that the rua address they provide is one you control and that you have access to the underlying mailbox. If the service provides a subdomain under their own domain, make sure you understand what happens to those reports if you stop paying the bill.

What to Do If Your Reporting Domain Has Already Expired

If you discover your DMARC reporting domain has lapsed:

1. Register the domain immediately.
2. Update your DMARC record to point to the new address.
3. Check whether reports were delivered to the previous address in the past 30-90 days and whether that address is now controlled by someone else.
4. Treat any unknown access to historical reports as a potential information disclosure - the data reveals your sending infrastructure even if it is not immediately actionable by an attacker.
5. Set up a monitoring alert to detect future reporting interruptions.

Monitor Report Delivery, Not Just Configuration

The steps above are a point-in-time audit. What closes the gap between "we audited once" and "we stay secure" is monitoring whether reports are actually arriving on schedule.

A gap in report delivery is often the first and only sign that something has changed: a registrar auto-renewal failed, a third-party monitoring service changed their endpoint, or a receiving server updated its delivery behavior. Without arrival monitoring, you do not know your reporting infrastructure is broken until you need the data - and by then it may already be too late.

DMARCFlow monitors whether your aggregate reports arrive on time and alerts you when they do not. That early warning means you can fix a reporting problem before the underlying domain has time to expire and get registered by someone else. The monitoring cost is low. The value of knowing your reporting infrastructure is healthy is high.

---

FAQ

Q: Can I use a free email address for my DMARC rua tag?

You can, but you should not. Gmail addresses get deleted after disuse. Hotmail accounts get recycled. If you abandon the address, someone else can register it and receive your DMARC reports. Use a domain you control and renew actively.

Q: Do DMARC reports contain the content of my emails?

No. Aggregate reports contain metadata about authentication results - source IP addresses, SPF/DKIM/DMARC pass/fail counts, and receiving server hostnames. They do not contain email subject lines, body content, or recipient addresses.

Q: My DMARC record uses p=none. Do I still need to secure my reporting endpoint?

Yes. Even with p=none, your aggregate reports reveal your sending infrastructure - which third parties are sending on your behalf, your sending volume patterns, and which receivers are seeing failures. Whether you are enforcing policy or just monitoring, the reporting data is sensitive and should be protected.

Q: How often should I check my DMARC reporting endpoint status?

Check when you renew your domain registrations. Set automated renewals with your registrar. Add a calendar reminder 90 days before each relevant domain expires. Then add a report arrival monitor so you know within hours if reports stop flowing - not weeks.