How an Expired DMARC Reporting Domain Exposed a Fortune 1000 Co

A security researcher spent $10 to register a dropped domain. Within hours, the domain started receiving DMARC aggregate reports from 86 different domains across more than 20 organizations. One of those organizations was a company on the NYSE Fortune 1000 list.

This was not a sophisticated attack. It was a lapsed domain and a few minutes of work.

The attack in plain terms

DMARC has two reporting mechanisms. Aggregate reports (sent to the domain in your rua tag) arrive periodically and show which servers attempted to deliver mail claiming to be from your domain. Forensic reports (sent to the domain in your ruf tag) arrive immediately when an authentication failure occurs.

Both report types get sent to whatever domain you specify. The DMARC specification places the responsibility on the policy publisher to use a destination domain they have the right to use. There is no protocol-level check that confirms ownership. If you point your DMARC record at reports.example.com and that domain lapses, whoever registers it next starts receiving your aggregate reports.

This is what happened here. A DMARC reporting domain expired. Someone else registered it. Authentication reports started arriving.

What the reports actually contained

Aggregate reports are not just metadata. A DMARC aggregate report for a single day can include:

The IP addresses of every server that tried to send mail claiming to be from the targeted domain
The HELO/EHLO identities those servers used
The SPF, DKIM, and DMARC results for each attempt
Which sources were authorized and which were not

Cross-referenced over time, this gives an attacker a detailed map of a companys email sending infrastructure. It shows which third-party services the company uses, which subsidiaries send through which systems, and how mail flows between internal and external servers.

In this case, the reports covered 86 domains and multiple organizations. The exposure included internal hostname patterns, MX record fingerprints, and evidence of email forwarding chains. A competitor, a threat actor, or a curious party had a detailed view of email infrastructure that is normally invisible to anyone outside the organization.

Why the DMARC spec allows this

The DMARC specification (RFC 7489) is explicit that the policy publisher is responsible for ensuring the destination domain is appropriate for receiving reports. The receiving domain does not confirm or consent to receive reports. There is no authentication between the report producer and the report destination during the DMARC protocol handshake.

Section 6.3 of RFC 7489 states that aggregate reports are sent via HTTPS GET requests to the destination domain, but the domain does not verify that the policy publisher has any legitimate relationship with it. The spec assumes that the publisher has arranged access in advance.

In practice, this means any domain can be used as a DMARC reporting destination without the domain owners knowledge or permission. The system was designed for organizations that control both their sending infrastructure and their reporting infrastructure.

How to audit your own exposure

Before assuming your DMARC setup is safe, check a few things:

1. What domains are listed in your DMARC record?

Look at the rua and ruf values in your published DMARC record. These can be any domain.


_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com,mailto:reports@thirdpartyvendor.com; ruf=mailto:forensics@yourdomain.com"

If you see a third-party vendor domain here, that vendor is acting as a report recipient on your behalf.

2. Do you control those reporting domains?

For each domain listed, verify that you own and manage the DNS for that domain. If the domain belongs to a vendor, the vendor controls the reports, not you.

3. What happens if that vendor domain lapses?

If the vendor domain expires and gets registered by someone else, that party starts receiving your reports. The vendor has no obligation to notify you if they let the domain go.

4. Do your aggregate reports actually arrive?

If you are using a third-party reporting domain, check whether those reports are still arriving. If they stopped, the domain may have already changed hands.

How to reduce your exposure

Use domains you control for DMARC reporting. If you use a third-party DMARC monitoring service, set up the service to receive reports at a subdomain you own, such as dmarc-reports.yourdomain.com. Point your vendors reporting infrastructure at your domain, not theirs. This puts you in control of who receives your data.

Isolate reporting to dedicated subdomains. Do not reuse a domain that is used for any other purpose. A reporting subdomain should have no other records and should not be used for anything that could create confusion about its ownership.

Monitor your reporting domains the same way you monitor your production domains. If a vendor provides your DMARC monitoring, ask them what happens to their reporting domain if they shut down, get acquired, or simply do not renew. Add domain expiration monitoring for any reporting domain you do not directly control.

The most reliable way to catch a reporting gap before it becomes a problem is to receive alerts when aggregate reports stop arriving. DMARCFlow tracks your reporting endpoints and notifies you when data stops flowing, which means you find out about a lapsed domain problem the same day it happens, not weeks later when someone else registers the domain.

Consider CAA records for your DMARC reporting subdomain. A Certification Authority Authorization record specifies which certificate authorities are allowed to issue certificates for a domain. Setting a CAA record for your reporting subdomain makes it harder for an attacker to obtain a valid TLS certificate for that domain, which adds friction to any attempt to collect reports over HTTPS.

Who is most at risk

Organizations with the highest exposure are those that have outsourced email authentication monitoring to vendors who use their own domain as the report destination. The moment that vendor domain lapses, the exposure transfers to whoever registers it next.

Large organizations with many subsidiary brands are particularly exposed because each brand may use a different vendor, multiplying the number of third-party reporting domains in play. If even one of those domains lapses, an attacker gains a view into that subsidiaries email infrastructure that they can use to plan impersonation attacks.

Small and medium businesses are not exempt. Free tier tools, abandoned pilot accounts, and decommissioned vendor relationships are common sources of stale reporting domains.

The broader lesson

DMARC aggregate reports are sensitive. They are internal documents by design. They tell you which servers are sending mail on behalf of your domain, and that information is exactly what an attacker needs to plan domain impersonation or spoofing campaigns.

Treat your DMARC reporting infrastructure with the same care you would treat any other system that contains a map of your internal network. When your monitoring blind spots include your own email infrastructure, you are giving attackers a head start.

Where DMARCFlow fits

The most practical way to catch a reporting gap before it becomes a data exposure problem is to receive alerts when aggregate reports stop arriving. DMARCFlow monitors your DMARC configuration continuously, tracks whether your reporting endpoints are actually receiving data, and notifies you on the first day a domain goes silent. That is the difference between knowing your monitoring is working and hoping it is.

---

FAQ

Can I tell if someone is receiving my DMARC aggregate reports without my knowledge?

Not directly through the DMARC protocol itself. If a third party is collecting your reports, you would only find out if you noticed the reporting gap, found evidence in your own logs, or were informed by the third party. Using reporting domains you control eliminates this uncertainty.

Is it common for DMARC reporting domains to expire?

It is more common than it should be. Organizations that use third-party vendors for DMARC monitoring often do not track the vendors domain expiration. When vendors shut down, get acquired, or simply fail to renew, the reporting domain becomes available. In this case, the domain was still receiving reports from 86 domains when the researcher registered it, meaning the organizations sending reports had no idea their data was going somewhere new.

Does HTTPS prevent this attack?

Not entirely. If a reporting domain lapses and an attacker registers it, the attacker can obtain a certificate for that domain and receive reports over HTTPS. The attacker receives exactly what was being sent to the previous owner. CAA records slow this down but do not eliminate the risk if the attacker is determined and the CA is permissive.

How do I check if my DMARC reports are going somewhere I do not control?

Look at your published DMARC record. Run dig _dmarc.yourdomain.com TXT and examine the rua and ruf values. For each domain listed, verify that you own or directly control that domain through your DNS registrar. If you do not recognize a domain, remove it from your DMARC record or replace it with a subdomain you control.