How Broken DMARC Reports Leak Your Infrastructure Map

Security InsightsTechnical Guidance

A DMARC aggregate report lists every server that has sent mail using your domain, how much it has sent, and whether that mail passed SPF and DKIM. The address those reports go to is typically set once, in the rua tag, and then never looked at again. If that address is mistyped or sits on a domain the company no longer owns, the reports go to whoever registers that domain.

This guide covers three common ways a broken reporting address ends up in a company’s DMARC record, what the reports give away, and how to check your own records. The examples in this guide are from SH Consulting’s research into mistyped and expired reporting domains. In each case, SH Consulting notified the organization, did not use the data, and either handed the domain back or set it to reject all mail. After SH Consulting has presented these examples, Ash Morin then adds what dmarcian sees from the vendor side.

How Reporting Endpoints Break

The three failures below have one thing in common: a reporting endpoint in a production DMARC record that nobody at the company can account for. And in most cases, it has nothing to do with the DMARC vendor the organization uses.

A typo in the address

DMARC vendors usually give each customer a reporting address on a subdomain. A record pointing to dmarcian looks something like this:

v=DMARC1; p=reject; rua=mailto:[email protected]

After being retyped instead of copied and pasted, the same record might look like this:

v=DMARC1; p=reject; rua=mailto:[email protected]

One period is missing before dmarcian.com, meaning the record points to agdmarcian.com, a completely separate domain from dmarcian.com. A domain like that is usually free for anyone to register. If nobody has registered it, the reports will bounce and the dashboard will go quiet. If somebody has registered it, they will receive these reports. The mistyped record still passes a syntax check because nothing in it is malformed. That means any DMARC validator currently operating will indicate that this is a valid DMARC record.

SH Consulting found agdmarcian.com and frdmarcian.com available for registration during its research, registered them, and transferred both to dmarcian. Ash explains below how dmarcian handles them.

The same thing can happen with a company’s own domain. Adva Network Security, a German security vendor, published reporting addresses at advasecurtiy.com, a misspelling of advasecurity.com. The misspelled domain, which had two letters swapped, was unregistered. SH Consulting reported the typo, then registered the domain defensively and blocked all mail to it.

An old company domain that was allowed to expire

Rebrands, mergers, and acquisitions leave old domains behind. Domain registrar accounts are often tied to an IT manager’s email address, so when that manager leaves the company, the domains expire along with them. Or the credit card on the registrar account expires without anyone realizing, because the notifications go to an email address that no longer exists at the company. Either way, nobody checks DNS for anything that still points to that name.

JE Pistons and Wiseco are clear examples of this pattern. Both brands once belonged to a parent company, specifically a motorsports division of Dover Corporation, which used doverpmi.com. After a change in ownership, this domain expired, but both brands’ DMARC records kept sending reports to it. SH Consulting registered the domain during its research, and daily reports for the two actively trading brands started to arrive. Mail was also still being sent to former employees, so the domain was set to reject all inbound mail. One of the two brands has since removed the address, while the other still sends its DMARC reports to that domain.

An address added by an outside IT provider

Not every address in a DMARC record belongs to a DMARC vendor. IT providers and spam filtering services sometimes add their own domain to a client’s record, which stays there after the service is retired.

This is what happened at Eden Park, New Zealand’s national stadium. Its DMARC record listed two reporting addresses: One belonged to a DMARC vendor and worked as expected. The other was at spamcontrol.co.nz, the domain of a spam filtering service that Fujitsu retired in June 2021. The domain expired at some point, but the address remained in Eden Park’s record years afterward. SH Consulting registered the domain during its research and received about a year of the stadium’s reports. Eden Park removed the address in August 2026, and the domain has since been transferred to Fujitsu.

Why no one notices

These mistakes can sit in DNS for years because nothing visibly breaks. Mail keeps flowing, and DMARC keeps protecting the domain. If the record also lists a second reporting endpoint, the vendor dashboard keeps filling up as well. The only way to find the problem is to read the record itself.

Another reason this happens is that many organizations have no DMARC vendor. Their record lists only their own mailbox, and the reports arrive there as XML files. These are likely to be the least-read emails a company receives, since nobody reads XML by hand to audit security. When the reports stop arriving, nobody notices, especially if they were never parsed into regular updates for the team. This is the strongest argument in favor of third-party DMARC monitoring: The responsibility falls to someone who actually understands the data.

What’s at Risk

An aggregate report comes in the form of an XML file with one row per sending IP: the address, the message count, the SPF and DKIM results, and the domains used in each check. If you read a month of these reports you’ll know which email platform, CRM, helpdesk, and billing system send for a domain. You’ll also know the volumes, the subdomains in use, and which streams fail authentication.

Most people assume aggregate reports only describe their own senders, but these reports contain more than most people expect. Some receivers, such as Microsoft, include an optional envelope_to field with the recipient’s domain. Reports that carry it also show who the company emails: customers, distributors, and partners, by domain and by volume. 

Failure reports sent to a ruf address go even further. They can include the headers of individual messages, and sometimes the content. Many large mailbox providers no longer send failure reports, but several dozen receivers still do.

For an attacker, this is a ready list of the third-party services allowed to send for a domain, and of the places where authentication is weak or missing. Each of those services represents a high-value target. If an attacker takes over the company’s account at one of these services, which are often protected solely by a password (with no SSO or MFA), the attacker can send mail that passes authentication.

When the reports include recipient domains, they are also lists of the customers, partners, and vendors the organization deals with, each of which represents an easy phishing target. The volumes, sending days, and platforms show what the company’s normal mail looks like; this makes it easier to impersonate the brand to those contacts. All of this saves an attacker the reconnaissance work.

There are two types of protection that people often rely on that do not help in this case:

• p=reject. This policy tells receivers what to do with mail that fails. It has no effect on reporting, so a domain with full enforcement leaks exactly as much as one with p=none.
  
• External destination verification. Before sending reports to another domain, a receiver checks that the domain has published a DNS record accepting them. Anyone who has registered the mistyped or expired domain controls its DNS and can publish that record in a minute.

Vendor Perspective: Ash Morin, dmarcian Director of Professional Services

From the vendor side, this problem is rare. Of all the domains dmarcian monitors, only one currently publishes a mistyped dmarcian reporting address, and the domain it points to is now ours. But one is all it takes: if someone else had registered that domain, those reports would have gone straight to them.

dmarcian will keep agdmarcian.com and frdmarcian.com registered permanently. Even after every record pointing to us is fixed, a mistake that happened once can happen again, and we’d rather keep the gap closed. If other typo domains turn up, we’ll do the same.

Owning domains only covers the typos we know about, though. No vendor can register every possible misspelling of its own name, so most of the work goes into preventing the mistake. A few years ago we introduced region-specific reporting addresses, such as ag.us.dmarcian.com, which we’ve seen customers get wrong less often. Our onboarding walks customers through publishing their record correctly, and we audit the rua and ruf addresses on our customers’ domains to confirm they point where they should.

Those audits only cover domains in our system. When a customer closes their account, they may not update their DNS record for a variety of reasons. At that point, nothing on our side is keeping track anymore. When you leave a vendor, remove their reporting address. Don’t leave it behind.

People often think DMARC data is harmless because aggregate reports carry little personal information. That misses the point. The risk isn’t in any single row. It’s the pattern. Over the past few years, I’ve worked on more than 100 DMARC deployments. Every one of them had at least one third-party service whose logins weren’t covered by MFA or SSO. These are often tools that someone set up outside IT and that nobody kept track of. Those are exactly the accounts an attacker reading your reports would go after first.

How to Audit Your Reporting Endpoints

1. List every rua and ruf address on every domain and subdomain you own. Include parked domains and any domains that inherit a shared record through a CNAME.
   
2. Confirm each domain is registered, and by whom. If you cannot name the owner and the reason the address is there, treat it as broken. SH Consulting’s free Dangling DNS Check reports unregistered domains in DMARC and SPF records.
   
3. Check vendor addresses character-by-character against the vendor’s own documentation. Start by looking for missing periods.
   
4. Remove addresses nobody reads: These include services you no longer use, former agencies or IT providers, and previous company domains.
   
5. Search your DNS before a domain expires. If any record still points to it, either fix the record before the domain expires or keep the domain registered.

Carry out this audit process at least once a year, along with whenever you change vendors, rebrand, or acquire a company.

---

Alex Shakhov, the coauthor of this piece, is the founder of SH Consulting, an email deliverability and security consultancy. His team fixes inbox placement, blocklisting and authentication problems for senders ranging from startups to multi-tenant email platforms.

We’re Here to Help
With a team of email security experts and a mission of making email and the internet more trustworthy through domain security, dmarcian is here to help assess an organization’s domain catalog and implement and manage DMARC for the long haul.

---

Want to continue the conversation? Head over to the dmarcian Forum.