Why Abandoned DMARC Reporting Domains Are a Security Risk You Cannot Ignore

What DMARC Aggregate Reports Actually Contain

When you set up DMARC for your domain, you typically configure two types of reporting addresses in your DNS record: a rua address for aggregate reports and a ruf address for forensic reports. The aggregate report is the one that matters most for ongoing monitoring. It arrives on a schedule (usually daily) and contains a structured summary of every IP address that tried to send email on behalf of your domain over that period.

The data in those reports is sensitive. Aggregate reports show every sending source your domain uses: your own mail servers, third-party email service providers, marketing automation platforms, and any vendor that sends transactional email on your behalf. They show email volume per source, pass and fail rates for SPF and DKIM checks, and the DKIM domains those sources use. They reveal your internal naming conventions, your server IP ranges, and which third parties are sending mail that claims to come from your domain.

In short, a DMARC aggregate report is a detailed map of your email infrastructure, seen from the outside. That is exactly why you want to receive them. It is also exactly why someone else might want to receive them instead of you.

How an Abandoned Reporting Domain Gets Exploited

Here is what happened in a real scenario that a security researcher documented recently: a major company's DMARC reporting address was configured on a subdomain that eventually expired. The domain was available for registration on the open market for about $10. A third party registered it, set up an email address to receive the reports, and immediately started receiving the company's DMARC aggregate reports.

The reports went to a Fortune 1000 company. They revealed internal infrastructure, third-party vendor relationships, sending patterns, and enough detail to build a targeted attack plan against the organization's email supply chain.

The attack chain is straightforward: your DMARC record points to a reporting address on a subdomain like rua._dmarc.yourdomain.com. That subdomain needs to exist, resolve correctly, and accept email. If you let the registration lapse, the domain becomes available for anyone to register. When they do, they can set up mail handling for that subdomain and start receiving your DMARC reports. Your DMARC policy and enforcement keep working. The reports just go somewhere else.

This is not theoretical. The researcher who documented this called it "the abandoned endpoint" problem. Your DMARC enforcement does not protect you from this because your DMARC record does not specify who should receive the reports. It only specifies where reports should be sent. If that destination is misconfigured or abandoned, the sender will still try to deliver the reports there.

What Attackers Can Learn from Your Aggregate Reports

Understanding what is in these reports explains why this matters. From a DMARC aggregate report, an attacker can identify:

Every sending source for your domain, including third-party services you may not even remember using. Many organizations discover unexpected sending sources in their DMARC reports: old marketing platforms, discontinued transactional email services, internal systems they assumed were not in scope.

Your email volume patterns, including which days and hours you send the most mail. This helps attackers time phishing campaigns to look like normal business communication.

SPF and DKIM alignment failures, which reveal which sending sources are misconfigured or which might be easier to impersonate. If a trusted vendor has weak DKIM configuration, that is a potential vector.

Internal domain structure and naming conventions from DKIM selector names and server naming patterns visible in reports. This reconnaissance feeds social engineering and spear-phishing campaigns.

The specific vendors and partners that send email on your behalf, which is useful for business email compromise attacks impersonating those vendors.

None of this requires compromising your domain. The attacker just needs to register a subdomain you already stopped paying for.

How to Check If Your DMARC Reporting Domain Is at Risk

Run this audit for every domain you have DMARC configured on:

1. Find your DMARC record. Look for a TXT record at _dmarc.yourdomain.com. The record will contain rua=mailto: and possibly ruf=mailto: entries pointing to email addresses on specific domains.

2. Identify the reporting domains. Extract the domain portion of eachmailto address. For example, if your record contains rua=mailto:dmarc-reports@example.com, then example.com is your reporting domain. If it is rua=mailto:dmarc@rua.example.com, then the reporting domain is rua.example.com.

3. Check the domain registration status. Use a WHOIS lookup or a domain availability checker. Look at the expiration date. If the domain expires within the next 90 days, renew it now. If it has already expired and you are still receiving reports, that is a gap you need to close.

4. Verify you control the DNS. Confirm that the reporting domain resolves correctly and that you have control over its MX and DNS records. If someone else controls that domain, they are receiving your reports.

5. Confirm reports are actually arriving. Check your DMARC report mailbox. If you have not received a report recently, either the sending system has not generated one yet or the reports are going somewhere else.

How to Protect Yourself

Register reporting domains proactively. When you set up DMARC, register the reporting subdomain for multiple years, not just one. Treat it like any other critical infrastructure asset.

Set up receiving infrastructure before publishing DMARC records. The common mistake is publishing a DMARC record that points to a reporting address you have not set up yet. Do the infrastructure first.

Use monitoring that alerts on DNS changes. If your DMARC record changes or your reporting domain stops resolving, you should know immediately, not days later when you happen to check manually.

Use a DMARC monitoring service that actively manages reporting infrastructure. The abandoned domain scenario is easy to miss without tooling: your DMARC policy still works, reports still flow, and no error message tells you that reports are going to the wrong place. DMARCFlow maintains continuous oversight of your reporting infrastructure and alerts you when something changes, including when your reporting endpoint stops receiving data. That is the difference between setting up DMARC once and actually monitoring it over time.

Why Passive Reception Is Not Enough

Receiving DMARC reports is not the same as monitoring them. Most organizations that receive DMARC reports file them without reading them. The reports arrive as XML attachments to emails, often compressed or split across multiple files. Without tooling to parse and summarize them, the data is nearly useless.

Active monitoring catches the things that passive reception misses: a new sending source appearing in your reports, an unauthorized ESP sending mail that claims to be from your domain, a configuration change that breaks DKIM alignment for a key vendor, or a reporting domain that stops delivering reports.

DMARCFlow monitors your DMARC reports continuously, alerts you when something changes, and surfaces the findings that matter. If your reporting domain goes offline, you get an alert. If a new sending source appears, you get an alert. That is the difference between passive reception and active monitoring.

FAQ

Does DMARC still work if my reporting domain expires?

Yes. Your DMARC policy and enforcement mechanism remain active. Your record tells receiving mail servers how to handle email that fails authentication. That record does not depend on your reporting domain. The only thing that stops working is report delivery. You stop seeing what is happening with your email authentication, while someone else may start.

Can someone steal my main domain by registering my expired reporting subdomain?

No. Registering a subdomain that you abandoned does not give the registrant any control over your root domain. They cannot send email as your domain, intercept your email delivery, or authenticate as your domain. What they can do is receive the reports that are sent to that subdomain. That is a intelligence gap, not a domain hijack.

How much does a DMARC reporting domain cost to register?

Typically $10 to $15 per year for a standard domain registration, similar to any other public TLD. Some hosting providers include domain registration as part of a hosting package. The cost is low; the risk of not maintaining it is not.

What do aggregate reports actually look like?

They are XML files sent via email to your configured reporting address, usually on a daily cycle. The XML contains structured data about every message that passed through a participating receiver during the reporting period. Parsing raw XML is not practical for most administrators, which is why tooling like DMARCFlow exists.