DMARC’s aggregate reporting was built on a simple idea: publish a rua= address in your DNS, and mailbox providers around the world will mail you a daily digest of who is sending as your domain. Most of this blog’s coverage focuses on the sending side of that equation, the domains that fake DMARC compliance to get phishing past a filter. Researcher SH Consulting just published a case that flips the problem around entirely. The vulnerability is not in who sends the mail. It is in who ends up reading the reports about it, years after the organization that chose that destination stopped paying attention.
A Domain Anyone Could Buy Was Still Everyone’s Reporting Address
The researcher registered gca-emailauth.org on November 20, 2025, after noticing the name had lapsed. The domain’s history stretched back to September 9, 2019, when it was first registered through Name.com with DNS on Cloudflare, held until 2023, then picked up again from June 2024 to 2025 by a different registrant, also on Cloudflare, before falling through to public availability. Once the researcher controlled it, they set up a mailbox and simply waited to see what arrived. What arrived were DMARC aggregate reports, addressed to [email protected], from 86 distinct domains belonging to more than twenty organizations. The list included a NYSE-listed manufacturer with roughly $4.5 billion in annual revenue, a public university, a public residential STEM high school, a regional education agency serving 35,000 children, a public school district, a county developmental disabilities board, a Saudi financial services firm, and two United States county governments. None of them had done anything wrong. Years earlier, someone at each organization had followed guidance, pointed their rua= tag at this address, and never revisited that decision.
The Wildcard Record That Made It Worse
Modern DMARC includes a safeguard for exactly this kind of arrangement, External Destination Verification, which requires the destination domain to publish a TXT record at <policy-domain>._report._dmarc.<destination-domain> confirming it consents to receive another domain’s reports. The researcher found that the previous registrant, or possibly the original one, had published a wildcard version of that record, *._report._dmarc.gca-emailauth.org, which authorizes report delivery from any domain on the internet rather than a specific, enumerated list. The 86 domains the researcher actually received mail from are simply the ones that happened to send during the observation window. EDV is supposed to confirm that a destination consents to a specific relationship. A wildcard record confirms nothing except that whoever controls the domain will take mail from anyone, which is a very different guarantee than the one the mechanism was designed to provide.
Even the Origin Story Doesn’t Hold Up
The domain name, invoking the Global Cyber Alliance’s old free DMARC setup tooling, suggested a tidy explanation: a nonprofit program wound down, its guidance kept pointing at the address, and nobody updated the documentation. The researcher checked. GCA’s Head of Engineering confirmed the domain’s historical nameservers were never part of GCA’s own Cloudflare account, meaning this was not simply an official GCA endpoint that lapsed on schedule. Where the guidance pointing organizations at this domain actually originated, and how it kept circulating for years after whoever ran it first stopped, remains unresolved. That uncertainty is itself part of the finding. An external reporting destination can outlive not just its operator’s attention, but any clear record of who the operator ever was.
What This Means for Your Program
Treat every external rua= and ruf= destination in your DMARC record as a standing trust relationship, not a one-time configuration choice. A domain you pointed reports at in 2019 is not the same relationship in 2026 unless you have checked.
Audit your DMARC record’s reporting addresses on a recurring schedule, not only when something breaks. If any destination is a third-party domain rather than one you control, confirm who currently owns it and why your organization still trusts it.
Do not assume External Destination Verification proves the destination is trustworthy. A wildcard EDV record proves only that the domain accepts mail from anyone claiming a relationship, which is nearly the opposite of the safeguard the mechanism is meant to provide.
When a vendor, consultant, or nonprofit tool recommends a third-party reporting address, document the recommendation’s source and set a reminder to revisit it. Programs end, companies get acquired, and domains lapse quietly, but the DNS record pointing your authentication telemetry at them does not update itself.
The Takeaway
DMARC aggregate reports contain a real, if narrow, picture of your organization’s own sending infrastructure, which mail servers claim to send as you and how their SPF and DKIM alignment checks out. That is exactly the kind of data an attacker, a competitor, or simply a curious researcher would want to read for free. Eighty-six domains handed that visibility to a stranger because a DNS record from years ago never got revisited, and a wildcard verification record meant the new owner did not even need to work for it. The lesson is not that DMARC reporting is broken. It is that a rua= tag is a live delegation of trust, and like any other credential, it needs to be checked on, not just set once and forgotten.
Your DMARC aggregate reports are only useful if they are going somewhere you actually control and actually read. Excello Mail hosts your reporting endpoint, keeps the data in your own account, and turns it into a clear, continuous view of every service sending as your domain, so you are never one lapsed DNS record away from handing that visibility to somebody else. Sign up for free to Excello Mail and take direct ownership of where your DMARC data goes.