Blog · Dmarc
What Happens When Your DMARC Reporting Domain Expires
When a DMARC reporting domain expires, it stops being yours and becomes available for anyone else to register. That sounds obvious. The problem is that many organizations point their DMARC aggregate reports at a domain they set up once and never think about again. When that domain lapses, someone else can pick it up and start collecting data about your email traffic.
This is not a theoretical risk. In early 2025, the Global Cyber Alliance let the domain gca-emailauth.org lapse while it was still receiving aggregate DMARC reports from 86 organizations. Anyone who registered that domain would have received a detailed breakdown of those organizations' email send volumes, source IP addresses, authentication pass rates, and DKIM/SPF alignment data.
This post explains what DMARC reporting domains are, how the expiry risk works in practice, and what you can do about it.
---
What is a DMARC reporting domain and why it matters
DMARC has two mechanisms for reporting email authentication results back to the domain owner.
RUA (Reporting URI for Aggregate) sends summarized data. These are XML or JSON files delivered on a schedule, typically daily. They include: source IP addresses sending mail on your behalf, message counts, DKIM and SPF pass/fail counts, and DMARC alignment results. They do not include message content.
RUF (Reporting URI for Forensic) sends details about individual failed messages. These are usually delivered in real time. They include: specific message headers, source IPs, and the reason for failure.
Both are pointed at domains via the rua and fruf tags in your DMARC DNS record. Example:
v=DMARC1; p=quarantine; rua=mailto:reports@example.com; fruf=mailto:forensics@example.com
Here, reports@example.com and forensics@example.com are the reporting destinations. They do not have to be the same domain as the one being protected. Many organizations use a separate subdomain specifically for receiving reports, partly because it keeps report traffic separate from user-facing mail.
That separation is the source of the expiry risk.
---
The real attack: how an expired reporting domain becomes a data breach
The attack is straightforward.
1. An organization deploys DMARC and points rua or fruf at a reporting subdomain, for example mail-reports.example.com.
2. The organization monitors DMARC reports for months or years. Eventually, whoever registered that domain lets it lapse.
3. Someone else registers the expired domain.
4. All subsequent aggregate and forensic DMARC reports for the original organization get delivered to the new registrant instead.
What does the new registrant receive? In the aggregate reports: every IP address that has ever sent mail on behalf of your domain, the volume of mail sent from each IP, your overall authentication pass rate, and your DKIM/SPF alignment performance over time. In forensic reports: details about individual messages that failed DMARC checks.
This data is useful for mapping your email infrastructure, identifying your marketing and transactional email vendors, understanding your internal email volumes, and identifying timing patterns for your sends.
It is a slow-motion data breach. The attacker does not need to compromise anything. They just need to watch their inbox.
---
Case study: the Global Cyber Alliance gca-emailauth.org incident
The Global Cyber Alliance operated a free DMARC reporting tool at gca-emailauth.org. Organizations that used the service pointed their DMARC rua records at that domain. The GCA allowed the domain to expire while the service was still active.
The result: 86 domains continued sending aggregate reports to an address they no longer controlled. Any of those reports were readable by whoever registered the domain next.
The GCA incident is notable because it involved a trusted third party, not an individual organization's negligence. Even when you delegate reporting to an established organization, the domain infrastructure underneath that service still has to be maintained.
This is why some security professionals recommend assessing the operational maturity of any free reporting service before using it for production environments. The business model of a free service does not always include reliable domain renewal management.
---
How to check if your DMARC reporting domain is at risk
Run this check for each domain you protect with DMARC.
Step 1: Look up your DMARC record. Find the rua and fruf values. They will look like mailto:reports@domain.com or a web URL.
Step 2: For each domain in those values, check whether it is registered and who owns it. Use a WHOIS lookup or a DNS availability checker. The key question is: is this domain currently registered to you or to a trusted party?
Step 3: Check the domain's renewal date. If it is close to expiry and you do not have auto-renewal enabled, it is at risk.
Step 4: Check whether the domain is covered by domain registration lock. A registered domain without lock can be transferred to another registrant without your authorization. Most registrars offer this as a low-cost add-on.
Step 5: If your reporting domain is the same as your sending domain, the risk is lower because you are already paying attention to that domain's renewal. If it is a separate domain you created specifically for reporting, audit its renewal status now.
---
How to protect your DMARC reporting infrastructure
Use domain registration lock. This prevents unauthorized transfers even if someone obtains your registrar credentials. It is the single most effective protection against domain hijacking through registrar compromise.
Enable auto-renewal with a long registration period. Registering for 10 years instead of 1 year reduces the surface area for expiry-related incidents. Set calendar reminders for 30 and 7 days before renewal regardless.
Monitor your reporting domain's WHOIS status. Several services offer domain monitoring that will alert you if a domain's registration status changes. This catches expiry and unauthorized transfer attempts before they become a problem.
Use a managed DMARC service. Managed services handle the reporting endpoint as part of their infrastructure. Instead of maintaining your own reporting domain, you receive reports through the provider's platform. The domain expiry risk is managed by the provider as part of their service operation.
This is the practical benefit DMARCFlow provides for this specific risk. When you delegate reporting to a managed platform, you remove the domain renewal burden from your own operations. DMARCFlow owns and maintains the endpoints that receive your reports, monitors their status, and ensures continuity of reporting even as the underlying infrastructure is maintained by the service.
Separate your reporting domain from production sending domains. If your reporting domain lapses, your reports simply stop arriving. That is a service disruption, not a data exposure. Design for that failure mode rather than exposing aggregate traffic data to whoever picks up the domain.
---
How DMARCFlow handles reporting domain management
DMARCFlow operates the reporting infrastructure for the domains enrolled in its service. This includes: owning and renewing the domains used for rua and fruf endpoints, maintaining the DNS records that receive and parse incoming reports, delivering processed reports through the platform dashboard, and alerting users if a reporting endpoint becomes unreachable.
When you use DMARCFlow, you do not need to maintain a separate reporting domain. The platform's infrastructure handles the expiry and renewal automatically as part of its service operation.
The key difference between self-managed and managed reporting is operational responsibility. In a self-managed setup, the domain owner must track expiry dates, ensure auto-renewal is enabled, and monitor for unauthorized transfer attempts. In a managed setup, those tasks belong to the provider. The reporting domain is one more piece of infrastructure you no longer have to remember to check.
---
FAQ
Do I need a separate domain for DMARC reporting?
No, it is not required. The rua and fruf destinations can point to any email address or domain. Many organizations use a subdomain of their primary sending domain. The advantage of a separate domain is isolation: if that domain lapses, your normal operations are not affected, only your reporting.
What happens to my DMARC data if my reporting domain expires?
If the domain is registered to you and you simply forget to renew, your reports stop being delivered. You lose visibility into your DMARC performance until you fix the DNS record. If the domain lapses and is registered by someone else, they receive all future reports until you point the DMARC record elsewhere.
How can I monitor my reporting domain expiry date?
Set renewal reminders in your calendar 60, 30, and 7 days before expiry. Use your registrar's auto-renewal feature. Some domain monitoring services will send alerts if a domain's status changes. Add your reporting domains to whatever asset tracking system you use for other critical infrastructure.
Can I use a subdomain for DMARC rua/fruf instead of a root domain?
Yes. Using a subdomain like dmarc-reports.yourdomain.com is common and keeps reporting infrastructure separate from your main domain. The same expiry rules apply. If you create a subdomain specifically for reporting, treat it with the same renewal discipline as your primary domain.
---
What to do next
If you are currently using a personal or rarely-checked domain as your DMARC reporting endpoint, audit it today. Check who owns it, when it expires, and whether it has domain lock enabled.
If you are running DMARC manually and want to remove the reporting infrastructure burden from your operations, look at managed DMARC services that handle endpoint ownership and renewal as part of their offering.