There was no hacking involved. I registered a domain that had expired, paid 10 dollars, and waited for the mail to arrive. And it was not just the one company. For eight months, the email authentication reports for 86 domains — a NYSE-listed manufacturer, a state university, two county governments, a Texas school district, and an Iowa education agency serving 35,000 students — arrived in a mailbox I set up in an afternoon. Sixty-five of those domains still name that mailbox in their DNS today. The reports only stopped because I turned them off, and the only thing standing between those 65 organizations and a live leak is who happens to hold the domain.
This research centers on a single domain name: gca-emailauth.org. For years it served as a DMARC reporting address, the mailbox where email providers send daily reports about who is sending mail in your name. That address appears in email authentication training published by the Global Cyber Alliance, a respected nonprofit, which directed course participants to route their reports there. At some point the domain lapsed. In November 2025 I registered it for ten dollars. Within a day, the DMARC reports of 86 domains, across more than 20 organizations, began arriving in my inbox. Fifty-six of them belonged to a single Fortune 1000 manufacturer, another 14 to a US university, and the rest to a mix of government and commercial domains.
Those reports are meant to help a domain owner spot forgery. Read another way, they map who an organization sends mail to, the infrastructure it sends from, and where that mail is forwarded. For eight months that intelligence flowed to a domain none of these organizations controlled. What follows is what the reports exposed, why even well-resourced security teams never noticed, and the two-minute check that closes it. The full technical write-up, with every DNS record, screenshot, and the complete disclosure timeline, is available here.
Two envelope_to illustrations are from separate, remediated research unrelated to gca-emailauth.org and are included only to demonstrate the data exposed by the field. The sending identity and other sender-identifying fields are redacted.
Nothing broke. No alarm went off in any of those organizations. No bounce, no error, no security alert. Their email kept flowing exactly as before. The only thing that changed is that a stranger started receiving a daily readout of who sends mail as them, who is forging them, and who they send mail to. And the only reason it stopped is that the stranger was me, and I chose to stop.
If you work in email security, you may already be discounting this. Everyone knows aggregate DMARC reports are harmless: pass-fail counts, source IPs, no message content, nothing worth stealing. That belief is exactly why the leak ran for eight months, and it does not survive contact with the actual data.
What actually happened
DMARC is the standard that fights email spoofing. Part of it sends the domain owner a daily report: every server sending mail in your name, what passed authentication, what failed, who is impersonating you. You tell DMARC where to send those reports by putting an address in your DNS. It can be an address at any domain, including one you don't own. That flexibility exists so companies can use a specialist processor. It is the whole design.
The design assumes one thing it never checks: that the domain you are sending your reports to still belongs to the people you think it does.
Nobody owns a domain outright. You rent it, and the registration can lapse. When a reporting domain lapses and someone else registers it, every organization still pointing at it starts sending that stranger their reports. Automatically, silently, and with nothing in the system to flag that anything has changed.
gca-emailauth.org expired. I registered it in November 2025, for the price of a sandwich, so that someone with worse intentions couldn't. Within a day the reports started arriving. Eight months later they were still arriving, for 86 domains across more than 20 organizations, and I had to delete the domain's own mail records to make them stop.
DMARC reports are not what your security team thinks they are
The reflex, if you do this for a living, is that aggregate DMARC data is boring and safe: some IPs, some pass and fail counts, no bodies, no subject lines, nothing sensitive. That reflex is right about the message content and wrong about everything else, and the gap between those two is where this whole story lives.
Read together, aggregate reports can expose three kinds of information that are closer to an intelligence feed than a health check. Where envelope_to is populated, they show who an organization sends mail to, broken down by volume. They show the infrastructure it sends from, one IP at a time. And where forwarding or other routing information is reported, they can show where its mail is relayed and through which servers. A relationship map, an infrastructure fingerprint, and a routing diagram, delivered daily to whatever address the DNS names. When that address is one you no longer control, so is all of it. What that looked like across the organizations here is set out further down, and it is worse than the summary makes it sound.
The victims did everything right
This is what makes it worse than an ordinary breach. Nobody was phished and nobody misconfigured anything. Every affected organization set up DMARC correctly, by doing exactly what a training slide told them to do.
The slide below came from the Global Cyber Alliance, a respected nonprofit that has done more to spread email authentication than almost anyone, and its DMARC course told students to publish a record pointing reports at this exact address. GCA had been teaching that slide for years. It appears in a recorded GCA bootcamp session from 2019, and it was still live on GCA's own website, in English and Spanish, the week I disclosed this. Anyone who took that course last month and followed it joined the list.
So the failure was not the victims'. They followed good advice from a trusted source. The advice outlived the infrastructure behind it, and nothing in the entire system — the protocol, their mail software, their security tools, their compliance checklists — noticed the day that infrastructure changed hands.
Then it got stranger. When I told GCA, their engineers went looking through the domain's history, and what they found pointed away from GCA rather than toward it. The nameservers had never matched their accounts. Their conclusion was that the reporting address in their own published curriculum had most likely belonged to a partner years ago, and that when the relationship ended and the partner let the domain lapse, nobody connected the two events, because nobody had ever written down that the dependency existed.
That is the real lesson, and it is not only GCA's. A renewal calendar protects the domains you own. It does nothing for the domain you told ten thousand people to depend on.
What the 86 domains actually leaked
Start with who you send to. Where the receiving provider fills in an optional field called envelope_to — Microsoft’s enterprise reporting does this routinely — the report names the recipient domain of your mail, broken down per sending system and by message volume.
The two examples below show what that looks like in real data. They are from separate, previously remediated research and have no connection to gca-emailauth.org or any of the 86 domains in this investigation. The first is the analytics view: the sending domain is obscured, while the envelope_to column contains recipient domains reported for its mail. The second is the underlying Microsoft aggregate report, where the same information appears directly inside the <identifiers> block.
Back in the gca-emailauth.org data, the same field reconstructed what is recognizably the North American dealer network of The Toro Company’s myturf.com fleet platform: named distributors, each with a message count that doubles as a proxy for account size, and beneath them the end customers — named golf and country clubs across six countries, hospitality groups, and municipal accounts. That is a customer map with relative account sizes attached, arriving daily at a domain the company didn’t control, reachable by anyone who registered it for ten dollars. Those recipient identities are withheld because those organizations are not parties to this research and were never asked.
Then there is how you send. Every report lists the source IP of each sending server and the message count from it, grouped by receiver and often broken out by country. Those IPs resolve to the platforms behind them, so the reports quietly describe your sending infrastructure: which ESPs you use, how many IP pools you run, how traffic distributes across them, and roughly how much you send. Sustained volume over time puts a floor under your list size and your sending scale. None of that is guessing. It is arithmetic on data the protocol hands out by design.
And there is where your mail goes after it leaves you. The reports carry the SPF and DKIM results for each stream and the receiver's override reasons, and forwarding is one of those reasons. So the data exposes forwarding relationships: that mail sent as your domain is being relayed through particular servers, and where envelope_to is populated, onward to particular domains. That is internal and partner routing, visible to whoever holds the reporting address.
Put the three together and you do not have a spam summary, you have a target package. If the reports show that a company works with one firm for event traffic control and another for facilities, an attacker knows exactly whom to impersonate, to whom, about what, in language the recipient already expects. That is the raw material of a convincing spearphishing pretext, and it was sitting in a mailbox that cost the price of a sandwich to open. A password can be reset after it leaks. There is no equivalent for a customer list, a routing map, and an infrastructure fingerprint once someone has written them down.
The organization you'd trust most was the most exposed
You would assume the badly exposed organizations are the small, under-resourced ones. That is mostly wrong.
Fifty-six of the 86 domains belong to one company, The Toro Company, a NYSE-listed manufacturer with a security team, a named CISO, a top-tier commercial DMARC vendor, and the strictest enforcement setting the protocol offers on most of its fleet. It did much of what the maturity model asks. The expired address wasn't even its main reporting destination. It was a second address, sitting quietly behind a working one.
That second address is exactly why nobody caught it. An organization with no monitoring eventually notices the silence, because empty dashboards are a signal. An organization whose reports arrive perfectly at a working processor gets no signal at all. The data is complete. Every check is green. There is nothing anywhere in the environment that looks different from a world where the leak does not exist. Their monitoring didn't fail. It worked perfectly, and reported nothing wrong, because as far as it was concerned nothing was.
There is a second twist in the same portfolio, and it undercuts the "strictest setting" story. Most of those domains inherit their policy from a single shared DNS record the company named "parked," a baseline meant for dormant domains nobody uses. The domains inheriting it are not dormant. One is myturf.com, the live platform their distributors log into every day, pushing thousands of real messages a month, all governed by a record built for things nobody touches. And myturf.com is the one domain in the whole portfolio that never enforced at all. It sits at p=none: mail forged in its name is not refused, not quarantined, just delivered.
It is also, not coincidentally, the exact domain whose reports mapped out the dealer network. A record named "parked" gets reviewed as often as the name suggests, which is why it quietly accumulated the domains that mattered most.
Most of them still haven't fixed it
I didn't just watch. Throughout the time I owned the domain, I notified the affected organizations, each by name, with the exact broken record, a command to verify it themselves, and the one-line fix. Several I contacted more than once, across different channels. The two county governments I disclosed through CISA.
As of my most recent verification sweep, 65 of the 86 domains still publish the endpoint. I have since handed the domain back to the Global Cyber Alliance, whose name is on it, and their engineers are scanning for the rest of the exposure. But that only changes who holds the domain. It does nothing for the 65 records still pointing at it, each one still trusting that whoever holds the domain is friendly. That trust is the vulnerability.
The manufacturer with 56 of them, The Toro Company, whose fix is editing essentially two DNS records, has not replied despite repeated contacts across multiple channels.
The organizations that fixed it fastest were the ones with the least money and staff to spare. Great Prairie AEA, a regional education agency in Iowa with the smallest security budget of anyone affected, serving 35,000 students, closed it in about 24 hours. The North Carolina School of Science and Mathematics, a public residential high school, found it and fixed it on their own before I ever reached them, the only organization in the whole group to catch it unprompted. The billion-dollar manufacturer with the CISO and the commercial vendor is the one still ignoring the email.
The variable was never budget or sophistication. Every one of these organizations was in the identical position: a DNS record that was correct the day it was written and wrong now. The only thing that differed was what happened after someone told them.
Great Prairie AEA fixed the leak, and is still under-protected
Great Prairie AEA deserves credit for the fastest cleanup in the group. But cleaning up the leak and being protected are two different things, and the reports show the gap.
While the endpoint was live, its reports documented sustained unauthenticated mail sent as the agency's domain: more than 2,500 messages that failed both SPF and DKIM, across 122 sending hostnames and 1,422 source IPs, reported by five independent providers. The heaviest failing streams resolved to national telecom networks across Kazakhstan, Kyrgyzstan and Uzbekistan, places an Iowa education agency has no conceivable business with. Not all of that mail is hostile. Some is the agency's own senders, never brought into alignment. The Central Asian concentration is the part that reads as impersonation, and it is the part they could not see.
Their published policy reads p=reject, which sounds like full protection. The full record is p=reject; sp=reject; pct=10, and that last tag changes what the policy does. Only about one in ten failing messages is actually refused. The rest is quarantined, delivered to the spam folder rather than blocked, into mailboxes belonging to a community that includes families of children receiving special education services, where a curious click retrieves it. The pct tag was dropped in the latest revision of the DMARC standard, but receivers still overwhelmingly honor it in practice, so a record like this looks fully locked down while enforcing on only a fraction of the mail. That setting has not moved in eight months.
They fixed the thing I told them about. The thing I couldn't tell them about, because they couldn't see it either, is still wide open. That is the shape of this entire problem in one organization.
This isn't the first time, and there's a market
I have found this exact pattern before. Cloudflare's own DMARC documentation once used a real, registrable domain in an example instead of the reserved placeholder. Organizations copied it into production, and their reports flowed to me until Cloudflare fixed the docs everywhere. The full account of that one is here. I have registered another reporting domain and watched reports pour in from strangers with no idea who had used it before.
Three independent times I have stumbled into this, which tells you it is not rare. It is unmeasured, because by design nobody is looking.
And it has a price. Lapsed domains with residual value get scooped up and resold for a few thousand dollars by people who hunt them systematically. A reporting address published by dozens of organizations is precisely the kind of asset that market notices. I registered this one for ten dollars to keep it out of those hands. I have no way of knowing whether I was the first to think of it.
The one thing to do right now
Two minutes, not a project.
dig +short TXT _dmarc.example.comFind the rua= part. Read every address in it, not just the first. For each one, ask who owns the domain after the @, and when you last checked. If there is a second address you can't account for, you have just found your version of this.
If your record points somewhere shared, follow it, and confirm every domain you own actually points where you think. The one that doesn't is the one that bites.
And don't "fix" it by deleting the reporting address. The University of Wisconsin–Stevens Point did that across all fourteen of its affected domains and is now enforcing blind, with no idea what is failing. Point the reports at a mailbox you control instead.
The check costs two minutes. The exposure it closes ran, in these cases, for years, silently and cheaply and in plain sight of monitoring that swore everything was fine.
The full list
Below is the full set of domains observed sending DMARC aggregate reports to gca-emailauth.org. The first group still names the endpoint in its DNS as of my most recent verification sweep. The second group no longer does, whether because the record was corrected, the reporting address was removed, or the domain was withdrawn from service. Fifty-five of the sixty-five domains still publishing the endpoint belong to a single company.
Still publishing the endpoint (65)
The Toro Company (55)
- Corporate and marketing: toro.us, toro.net, toro.org, toro.info, toro.mobi, toro.fr, toro.com.au, toro.com.cn, torocompany.com, torojapan.com, toromachines.com, toronew.com, toro-app.com, mytoro.com, toroinfo.com, torodealer.com, toroadvantage.com, torogroundsforsuccess.com, ttcopats.com, ecxtra.com
- Product and program microsites: myturf.com, yardcare.com, torolynx.com, toroinfinity.com, mytoronsn.com, snorisk.com, snowrator.com, flex21.com
- Homoglyph cluster: tor0.com, tor0.net, t0ro.com, t0r0.com
- Exmark: exmark.net, exmark.us, exmarkdealer.com, exmarkdealers.com, exmarkoriginalparts.com
- Ditch Witch / Charles Machine Works: ditchwitchdealer.com, myditchwitchdealer.com, ditchwitchgarage.com, theundergroundonline.com, theundergroundmagazine.com, rslining.com, citylinerusa.org
- BOSS Snowplow: bossplows.com
- Irrigation and lighting: irritrol.email, irritrolsystems.ru, rain-master.com, rainmaster.cn, rainmaster.com.cn, smrt-logic.com, smrtscape.com, lightlogicplus.com
- Hayter (UK): hayter-limited.org
- Other: toroag.ru
Other organizations (10)
- Education and public services (2): ennis.k12.tx.us, sciotodd.org
- US county governments (2): lickingcounty.gov, winnebagocountyiowa.gov
- Unclassified commercial (6): managed.sa, vivida.io, koolcats.biz, fenton.biz, azimco.onmicrosoft.com, xmxf98.com
No longer publishing the endpoint (21)
- The Toro Company (1): spectoro.com (withdrawn from service, now listed for sale)
- University of Wisconsin–Stevens Point (14): cc.uwsp.edu, admiss.uwsp.edu, give.uwsp.edu, survey.uwsp.edu, mc.uwsp.edu, sg.uwsp.edu, eforms.uwsp.edu, library.uwsp.edu, re.uwsp.edu, fr.uwsp.edu, td.uwsp.edu, al.uwsp.edu, alumni.uwsp.edu, mailchimp.uwsp.edu
- North Carolina School of Science and Mathematics (4): ncssm.edu (now redirected), alumni.ncssm.edu, nutanix.ncssm.edu, lithium.ncssm.edu (last three now resolve NXDOMAIN)
- Education and public services (1): gpaea.org
- Commercial (1): electronbeamservices.com
Totals reconcile to 86: 65 still publishing plus 21 no longer publishing. Toro accounts for 56 of the total, 55 still publishing and one withdrawn.
I run SH Consulting, an email authentication and DNS security practice. The full technical write-up of this research — every DNS record, every screenshot, the complete disclosure timeline, and the methodology so anyone can reproduce it — is published here. If you want your own DMARC records and reporting destinations checked before someone else registers them, get in touch or book a call.
