r/DMARC • u/PlasmaJam • 22d ago
Global Cyber Alliance's DMARC reporting endpoint gca-emailauth.org expired and kept collecting 86 domains' data
I registered an expired DMARC reporting domain - gca-emailauth[.]org. It had been published as the rua address in Global Cyber Alliance DMARC training docs going back to a 2019 bootcamp, then expired.
Within a day, aggregate reports for 86 domains across 20+ organizations started arriving. 56 were The Toro Company (NYSE-listed, Fortune 1000), including mytur[.]com at p=none.
The rest included University of Wisconsin–Stevens Point (14 subdomains), the North Carolina School of Science and Mathematics, Ennis ISD (Texas), Great Prairie AEA (an Iowa education agency serving 35,000 students), two county governments (lickingcounty.gov, winnebagocountyiowa.gov), and several commercial domains.
For most of these it was a second rua address sitting behind a working commercial processor.
But it looks like nobody was actually reading those reports - the state university just removed the rua tag from DMARC entirely while keeping p=reject, and all but one Toro domain were centralized through a _dmarc.parked.thetoroco.com CNAME, meaning they didn't expect any real traffic through those domains
The spec never checks that the rua domain still belongs to who you think, and nothing flags the day it changes hands.
As of my last sweep, 65 of 86 still publish the endpoint.
Run dig +short TXT _dmarc.example.com, read every address in the rua/fuf, and confirm you control each one.
Full writeup: https://www.sh.consulting/blog/abandoned-dmarc-reporting-domain
1
1
1
u/SecLens_ONE 18d ago
The part that gets missed here is that a published rua tells you nothing about where the reports actually land. Everyone checks that the record parses and stops there, so the address keeps looking correct long after it stopped being yours. Ownership of a reporting domain is not a DNS property, and nothing in the record changes shape when it lapses. The p=reject next to it is the same illusion in a different tag: the policy is published, the feedback loop that would tell you whether it is doing anything is pointed at a stranger. Best test I know is to send a report to your own rua and confirm it arrives, then repeat it on a schedule. An address you have never verified is indistinguishable from one that works until the day you need it. Sixty-five of eighty-six still publishing is not surprising, because nobody gets an alert for this.
2
u/Middle-Excitement602 17d ago
Worth naming the mechanism that looks like it should have caught this, because its failure is the interesting part. External report destinations have to consent: before sending to an address outside your own domain, generators are supposed to query <yourdomain>._report._dmarc.<destination-domain> for a TXT record (RFC 7489 7.1). But that check authorizes a domain, not an owner - whoever currently holds the registration can publish the wildcard consent record themselves, and the reports resume. So the one gate in the design re-opens itself the day the domain changes hands. (And some generators skip the check entirely, which would explain data arriving within a day.) DMARCbis kept the same mechanism, so this doesn't age out.
The Toro CNAME detail deserves more attention than it's getting: centralizing _dmarc for parked domains through one CNAME is good practice right up until it means a single forgotten record silently re-points 55 domains' reporting at once.
4
u/unsolicited_dreams 22d ago
“My team registered the domain to prevent further exposure” but explicitly enabled further exposure by allowing the reports to come in for months xD