Why DMARC Reporting Domains Expire Without Warning

Your DMARC aggregate reports stopped arriving. You check your DNS records. Everything looks correct. Your SPF and DKIM are passing. Your rua destination is still configured the way it has been for months. So why are the reports gone?

The most likely explanation is one most operators never think to check: the domain you are using to receive DMARC reports may have expired.

This is not a hypothetical. In 2025, the Global Cyber Alliance's DMARC reporting endpoint at gca-emailauth.org lapsed. For an unknown period, 86 domains kept sending aggregate reports to an address they no longer controlled. The organizations on the receiving end had no way to know the endpoint was dead unless they noticed the sudden silence in their inboxes.

This is a structural gap in how DMARC monitoring works. Understanding it is not optional for any team serious about email authentication.

What is a DMARC rua reporting domain?

When you publish a DMARC record, you can include a rua tag that tells receiving mail servers where to send aggregate reports:


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

The domain in that mailto URI -- in this case example.com -- is your DMARC reporting domain. Every day, participating mail servers bundle up what they observed about mail from your domain and send a compressed XML report to that address.

What the DMARC spec does not do is validate that you still control that domain. It does not check expiration dates. It does not send a warning when reports start bouncing. It does not tell you if your reporting endpoint has been dead for six weeks.

The spec assumes you own the domain and that mail will reach it. If either assumption breaks, you find out the hard way.

How the GCA endpoint expired: a real-world case study

The Global Cyber Alliance operated gca-emailauth.org as a free DMARC reporting destination for organizations that did not want to set up their own infrastructure. The service was well-intentioned and widely referenced.

When the domain expired, the mailbox behind it stopped accepting mail. Reporters sending to that address started getting delivery failures -- but the sending servers had no obligation to notify the domain owners that their reports were not being received. From the outside, everything looked fine. The DMARC record had not changed. SPF and DKIM still passed.

Security researchers later estimated that 86 domains had been sending reports to that expired endpoint across more than 20 organizations. Those organizations had no visibility into what their DMARC data showed for the duration of the outage -- and no way to know the gap existed.

This is the specific failure mode the DMARC specification does not address: silence does not mean success.

What the DMARC spec does and does not guarantee

DMARC was designed to let domain owners specify how receivers should handle mail that fails authentication and to request aggregate reports about what receivers observe. The reporting mechanism is described in RFC 7489, and it has a significant gap.

RFC 7489 discusses report delivery failures and recommends that receivers retry when delivery fails temporarily. But for a domain that simply ceases to exist -- where the MX records are gone and the address is no longer valid -- the spec offers no mechanism for alerting the domain owner.

There is no "bounce notification" sent back to the rua address if the destination no longer accepts mail. There is no periodic probe to confirm the endpoint is still live. There is no standard for what happens when the rua domain expires.

This means you can publish a perfectly valid DMARC record, have everything work correctly for years, and then lose all visibility into your email authentication posture because your reporting domain was not renewed.

How to check if your DMARC reporting domain is still valid

Run this check for every domain you monitor with DMARC:

Step 1: Find your rua destination

Look at your DMARC record's rua tag. If you publish multiple domains, check each one:


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

The domain in the mailto URI is what you need to verify.

Step 2: Check domain expiration and MX records

The fastest way to confirm your reporting domain is still alive:


dig MX _dmarc.example.com

If you get no MX records back, mail to that address will not be delivered. Also check the domain's registration status with your registrar to confirm it is not approaching expiration.

Step 3: Verify you are actually receiving reports

The only reliable signal is confirmed receipt. If you are not seeing daily aggregate reports in your inbox, something is wrong -- whether or not you have reason to think the domain expired.

Set up a test: send a DMARC report from an external source to your rua address and confirm it arrives. If it does not, your monitoring is offline.

Checklist: Is your DMARC monitoring actually working?

Use this regularly -- at least quarterly, and whenever you make changes to your email infrastructure.

[ ] I have verified the domain in my rua tag is still registered and not approaching expiration
[ ] I have confirmed MX records exist for my DMARC reporting domain
[ ] I am receiving daily aggregate reports from major receivers (Google, Microsoft, Yahoo)
[ ] I have tested that mail sent to my rua address actually arrives
[ ] I have an alert or reminder set for domain renewal dates for all reporting domains
[ ] If I use a third-party reporting service, I have confirmed they are still operational and my endpoint is active

FAQ

Can I use any domain as my DMARC reporting destination?

Yes, technically. You can use a subdomain of your main domain, a completely unrelated domain, or a third-party service. The DMARC spec places no restrictions on what the rua domain is -- only that it is a valid mailto URI. Just remember that if you do not control the domain, you are dependent on someone else's renewal discipline.

My DMARC reports stopped arriving. What should I check first?

Start with the domain in your rua tag. Run a DNS lookup on the MX records for that domain. If there are no MX records, mail will not be delivered. Also check your spam folder and confirm the address you are sending reports from is not being blocked.

What can catch this problem automatically?

A monitoring service like DMARCFlow tracks report volume over time. If your aggregate reports stop flowing in, DMARCFlow can alert you to the silence -- so you know something is wrong even if you were not watching closely. The expired domain itself still needs to be renewed with your registrar; monitoring can only tell you the reports stopped arriving.

Should I self-host my DMARC reporting instead of using a third party?

Self-hosting gives you full control over the infrastructure and eliminates dependency on a third party's uptime and renewal discipline. The tradeoff is that you need to maintain the mailbox, handle the report volume, and process the XML files yourself. For teams with the capacity, it is the more reliable option. For teams that want a managed solution, choose a provider with a track record of operational stability and verify they are still active before trusting them with your monitoring.

The core problem is not technical

The GCA endpoint failure is not a story about a bad actor or a deliberate security gap. It is a story about an organization maintaining a shared infrastructure resource that required periodic human attention to stay alive. When that attention was not paid, 86 domains lost monitoring without knowing it.

This happens more often than the industry discusses openly. Teams set up DMARC monitoring, the reporting domain sits quietly in their DNS records for years, and no one thinks to check whether the underlying domain is still registered. Then someone notices the inbox is empty and the reports have not arrived for months.

The fix is not complicated. It is an operational hygiene task: know what domains your DMARC monitoring depends on, treat their renewal dates as infrastructure events, and verify periodically that reports are actually arriving.

If you are responsible for email authentication at your organization, this is one of those tasks that is easy to forget and painful to discover you forgot.