The Abandoned Endpoint: How an Expired DMARC Reporting Domain Exposed 86 Domains Across 20+ Organizations

This is the full technical record, published so that every claim in it can be checked. A shorter version is available for readers who do not need the evidence.

1. Summary

DMARC lets a domain owner send authentication telemetry to a mailbox at any domain, including one they do not control. That is deliberate. The protocol was designed for a world where organizations outsource report processing to specialist vendors, and the mechanism exists so a company can point its reports at a processor without handing over its DNS.

The design carries an assumption it never states: that the destination domain will stay under the control of the party the domain owner picked.

Domains are leased, not owned. Registrations lapse. When a reporting destination lapses, every DNS record still pointing at it redirects a stream of email infrastructure telemetry to whoever registers the domain next. No error is raised. No bounce is generated. Nothing in the sending organization's environment changes. The reports simply start arriving somewhere else.

gca-emailauth.org was such a destination. It appears in the published DMARC records of 86 domains belonging to more than 20 distinct organizations: a NYSE-listed manufacturer with roughly $4.5 billion in 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.

The distribution is heavily skewed. Fifty-six of the 86 domains belong to a single company, The Toro Company. The remaining 30 are spread across every other affected organization.

The domain lapsed. It was available for open registration at commodity price. SH Consulting registered it on 20 November 2025 to prevent acquisition by a third party with less benign intent, notified affected organizations through a coordinated disclosure process, removed the endpoint's mail records on 30 July 2026, and has since transferred the domain to the Global Cyber Alliance at no cost.

As of a verification sweep run on 5 August 2026, 65 of the 86 domains still publish the endpoint. Twenty-one no longer do.

Four things in this incident are worth more attention than the count.

The organizations affected did not misconfigure the reporting endpoint. They published exactly what a training slide told them to publish. That slide carries Global Cyber Alliance branding and copyright, and at the time this research was disclosed it was still being served from GCA's own website in English and Spanish. Anyone completing that course and following the slide as written would join the affected population. The problem was still adding new victims.

The endpoint was not on GCA's own infrastructure. This is the finding that reframes the incident. The nameservers on the domain's prior registrations do not match any GCA account, a firm technical fact. GCA's own tentative reconstruction is that the domain had most likely been registered and operated by a partner organization rather than by GCA itself. Either way, the reporting address in GCA's published curriculum was not running on infrastructure GCA controlled. The training materials named a reporting endpoint that the organization publishing the training materials did not control. The dependency was never theirs to maintain, and nothing in their processes surfaced that.

The reports carry more than infrastructure data. Where a receiving provider populates the optional envelope_to identifier, aggregate reports disclose recipient domains. In one affected portfolio, those recipient domains resolved to a named distributor network with volume-weighted account sizes, a customer list spanning six countries, and municipal and .gov recipients. Infrastructure exposure can be remediated. A map of who an organization corresponds with cannot be un-disclosed once it is out.

Security maturity offers no protection against this particular failure. Sixty-five percent of the affected domains belong to a company running full DMARC enforcement with a tier-one commercial processor, where this endpoint sits as a second reporting address alongside one that works correctly. Their monitoring is healthy. That is precisely why nobody noticed.

2. How DMARC aggregate reporting works

2.1 What is in an aggregate report

DMARC, originally specified in RFC 7489 and superseded by the DMARCbis series (RFC 9989, 9990, 9991) published in May 2026, is not an authentication mechanism itself. It sits on top of SPF and DKIM: it lets a domain owner tell receiving servers what to do when a message fails authentication, and it requests reporting on those authentication results. The reporting half is what matters here.

A DMARC record includes a rua= tag naming one or more mailto: destinations. Participating receivers, which include Google, Microsoft, Yahoo and several hundred others, compile a daily XML report per sending domain and deliver it to those addresses.

An aggregate report contains, per RFC 7489 section 7.2:

• Every source IP address observed sending mail bearing the domain in the RFC5322.From header
• Message volume per source, per day
• SPF evaluation results, including the domain evaluated and the alignment outcome
• DKIM evaluation results, including the signing domain and selector, and the alignment outcome
• The policy disposition actually applied by the receiver: none, quarantine, or reject
• Policy override reasons where the receiver deviated from the published policy, such as forwarding, mailing list, or local policy
• The reporting organization and reporting window

Aggregate reports do not contain message bodies or subject lines. That is worth stating plainly because it is the first thing an affected organization asks.

They can, however, contain recipient information. RFC 7489 defines envelope_to as an optional identifier within the <record><identifiers> element. Reporters are not required to populate it. A substantial number do, Microsoft's enterprise reporting in particular. Where it is populated, the report discloses the recipient domain for each evaluated message stream.

The envelope_to identifier is defined in RFC 7489 section 7.2 as an optional element of the aggregate report record. What is a routine disclosure to an organization's own processor becomes something else entirely when the destination is a domain that changed hands. The practical effect is covered in Section 7.

2.2 The external destination mechanism

RFC 7489 section 7.1 permits rua= to name a mailbox in a domain other than the one publishing the policy. To prevent a domain owner from weaponizing this, by naming a victim's mailbox and directing thousands of receivers to flood it, the destination domain must publish an authorization record:

<policy-domain>._report._dmarc.<destination-domain>  IN TXT  "v=DMARC1"

This is External Destination Verification, or EDV. It establishes that the destination consents to receive reports on behalf of the policy domain.

EDV is a consent mechanism, not an identity mechanism. It answers the question "does this destination agree to receive these reports?" It does not answer "is this destination still the party the domain owner chose?" There is no binding between the DNS record and any particular operator, and no revalidation when registrant control changes.

A wildcard EDV record, *._report._dmarc.<destination>, authorizes reports from every domain on the internet. Whoever controls the destination inherits that blanket consent.

It is also worth noting that EDV is inconsistently enforced in practice. We have observed cases where reports flow to an external destination with no EDV record present at all. The consent layer is weaker than the specification implies.

2.3 Where the trust boundary actually sits

The practical consequence is that the security of a DMARC reporting relationship is bounded by the continued registration of the destination domain, and by nothing else.

A domain owner who published rua=mailto:dmarc@vendor.example in 2018 delegated a data flow to a party they had a reason to trust. That trust is renewed automatically, indefinitely, and without notification, to every subsequent registrant of vendor.example. It persists until the domain owner edits their DNS.

Nothing in the protocol, in any mail client, in any DNS monitoring product, or in any compliance framework flags the moment that trust transfers.

3. The failure mode

The abandoned reporting endpoint pattern requires four conditions, all of which are common.

A third-party endpoint is recommended by authoritative guidance. A vendor tool, a nonprofit's setup wizard, an implementation guide, a consultant's template.

Organizations adopt it correctly. The guidance was accurate when published. The configuration was appropriate at the time.

The endpoint is sunset. The tool is retired, the vendor is acquired, the program winds down, the budget line disappears. The domain lapses.

The DNS records are never revisited. DMARC records are set-and-forget infrastructure. There is no expiry, no health check, no notification. The record from 2018 is still authoritative in 2026.

The gap between the third condition and the fourth is the vulnerability window. It can close in several ways: the domain owner may notice and edit the record, may change the record for some unrelated reason, or the party now holding the destination may drop the EDV record and cut off reporting to domains that honor it. But nothing forces any of those to happen, and none of them is guaranteed. Absent one of them, the window stays open.

Three properties make this failure mode unusually durable.

It is silent. No bounce, no error, no delivery failure. The sending organization's mail flow is completely unaffected.

It is cheap. A lapsed .org costs roughly $10 a year. There is no exploit to develop, no vulnerability to weaponize, no access to gain. You register a domain and configure a mailbox.

It is discoverable at scale. DMARC records are public by design. Passive DNS providers index them. Identifying every domain pointing at a given destination is a single query.

This is not the first time we have documented the pattern. Cloudflare's DMARC documentation used third-party-example.com rather than the IANA-reserved example.com to illustrate an external reporting destination. The domain had never been registered. We registered it, and reports arrived for dozens of organizations that had copied the example into production DNS. Cloudflare corrected the documentation across all locales. The full account is here: Cloudflare's DMARC documentation exposed an unregistered domain.

We have encountered the same structural gap in more than one independent instance, the clearest being the Cloudflare documentation case above. That the pattern recurs, arrived at independently each time, suggests it is not rare. It is unmeasured.

The economics matter, because they determine whether this is theoretical rather than actual. Lapsed domains with residual value are routinely registered and listed for resale, at prices in the low thousands, by parties who identify them systematically. A reporting destination published by dozens of organizations is exactly the kind of asset that the market notices. We have observed instances of this in adjacent research and will document them separately.

4. Discovery and scope

4.1 Initial observation

The endpoint was first observed during routine DMARC record review in the published policy of a single organization.

Three characteristics made it worth pursuing rather than treating as a one-off misconfiguration. The destination domain was unregistered at the time of discovery, meaning the reports being generated were undeliverable, and would become deliverable to any registrant. The destination name suggested a third-party service rather than an internal mailbox, which implied other adopters. And the organization was an institution unlikely to have implemented the destination independently.

The third point drove the scoping decision. A named third-party endpoint in one organization's record implies a source of guidance, and guidance has an audience.

4.2 Scope enumeration

Full-footprint enumeration was performed via passive DNS, querying for TXT records containing the destination string across the observable DNS space.

Each candidate was then confirmed against live authoritative DNS:

dig +short TXT _dmarc.<domain>

Confirmation required the rua= tag to name a mailbox at the destination domain in the currently published record. Historical-only matches were excluded.

The result was 86 domains.

Attribution turned out to be harder than enumeration. The Toro figure moved from an initial estimate of roughly 49 to a confirmed 56 during preparation of this document. Six domains initially bucketed as unrelated commercial entities resolved to Toro subsidiaries and product programs on closer inspection:

This is worth stating rather than correcting silently. Attributing a domain to its parent organization is not trivial. Acquisition chains run several layers deep, product-program microsites carry no corporate branding, and WHOIS privacy conceals registrant identity on most of them. If a researcher working the problem deliberately needed three passes to assemble the portfolio correctly, an organization attempting to inventory its own DMARC footprint faces the same difficulty, with the added handicap that nobody inside the company necessarily knows the 2015-era promotional microsite still exists.

The reliable method here is DNS-based rather than registry-based, and it is stated so the finding is reproducible. Resolve _dmarc.<domain> and check for a CNAME to parked.thetoroco.com. Anything resolving there is confirmed under Toro's DNS control regardless of what WHOIS privacy conceals. Registrant lookup via RDAP is a useful cross-check but fails on privacy-protected and distributor-registered entries.

4.3 Registration

The domain was registered by SH Consulting on 20 November 2025.

The registration was defensive. The reasoning, recorded at the time:

The domain was already publicly enumerable as a live reporting destination for 86 domains. Enumeration required no privileged access and no unusual tooling.

The domain was available to anyone, at commodity cost, with no verification of any kind.

Leaving it unregistered did not protect the affected organizations. It left the acquisition available to the next party who ran the same query.

Comparable destinations were already being acquired and resold by third parties, as documented in Section 3.

One point of consistency should be addressed before a reader raises it. In early planning for this research, the recorded decision was not to register gca-emailauth.org, in order to limit footprint. That decision was reversed when the scope turned out to be substantially larger than the initial assessment suggested, and the resale market evidence emerged. An unexplained reversal in a documented decision trail reads badly if a reader finds it unaddressed, so it is addressed here.

5. Where the endpoint came from

5.1 The Global Cyber Alliance connection

The Global Cyber Alliance is a nonprofit founded in 2015 by the Manhattan District Attorney's Office, the City of London Police, and the Center for Internet Security. It has been among the most effective advocates for email authentication adoption globally.

In November 2016 GCA launched a free DMARC Setup Tool and implementation guide suite, aimed explicitly at organizations without the budget for commercial DMARC tooling.

The program worked. It brought DMARC to organizations that would otherwise never have deployed it: county governments, school districts, regional education agencies, mid-market manufacturers. The affected population in this incident is, almost exactly, the population GCA set out to help.

Attribution here is documentary rather than inferential. GCA's DMARC training materials instruct participants to publish a DMARC record naming this endpoint. The instruction appears on slide 7 of the Week 5 Wrap-Up Session deck, in both the basic and the advanced configuration example.

Basic: v=DMARC1; p=quarantine; rua=mailto:dmarc@gca-emailauth.org; ruf=mailto:<email address>;

Complex: v=DMARC1; p=none; rua=mailto:dmarc@gca-emailauth.org; ruf=mailto:<email address>; fo=1; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=reject;

The deck carries a Global Cyber Alliance copyright notice and GCA branding on every slide. This is not a third party using a GCA-like name. It is GCA's own curriculum, distributing a specific reporting destination as the recommended value.

Every organization in Section 6 published exactly what the slide told them to publish.

5.2 The endpoint was not on GCA's own infrastructure

This is the part that changes the shape of the finding, and it only became clear during disclosure.

The natural assumption, and the one this research carried until GCA responded, was that gca-emailauth.org was a GCA-operated endpoint that lapsed when the program wound down. That assumption does not survive the registration history.

GCA's engineering team investigated the registration history and reported the following sequence. The domain was originally registered on 9 September 2019, under Name.com with DNS at Cloudflare, and held until 2023. It was registered again from 28 June 2024 until 2025, under Cloudflare. SH Consulting registered it on 20 November 2025.

The detail that matters is the mismatch. In the words of GCA's Head of Engineering, Robert Thomas:

The domain was present in our DMARC record for quite some time; however, the nameservers it had registered aren't the ones associated with our Cloudflare account.

That single fact is what separates this from an ordinary lapsed renewal. The reporting endpoint in GCA's own curriculum was running on infrastructure that GCA's own account records do not recognize. After consulting the former Director of IT Security Operations who ran the training sessions and is named in the materials, Thomas reached a tentative conclusion about whose infrastructure it was:

After speaking with our former Director of IT Security Operations, he believes this domain was registered and owned by a partner of ours, one we haven't really interacted with in a few years. This more or less lines up with the past nameservers and registrars being distinctly different from any of our own. So I suspect they let the domain lapse seemingly in June, before you picked it up in November.

The hedging in that account is worth preserving rather than smoothing over. GCA did not claim certainty, and neither do we. The reconstruction is that the domain most likely belonged to a partner organization GCA had not interacted with in several years, and that this partner, not GCA, let it lapse.

So the reporting endpoint in GCA's published training materials was, on the evidence, not running on infrastructure GCA controlled. The firm part is the nameserver mismatch. The reconstruction of whose infrastructure it was, a former partner's, is GCA's own and is offered tentatively. GCA taught a configuration that depended on a destination it did not administer, and when whoever held that destination let the registration lapse, nothing in GCA's processes connected the two events. The materials stayed up. The dependency was invisible because it was never recorded as a dependency at all.

That is a more general problem than a missed renewal. An organization can maintain its own domains carefully and still ship guidance that hardcodes a third party's. The renewal calendar covers assets you own. It does not cover assets you have told thousands of people to depend on.

There is also an unresolved gap in that history. The first registration ended in 2023 and the second began on 28 June 2024. Who controlled the domain during the intervening period, or whether it was unregistered throughout, is not established by any evidence we hold. If it was registered by a third party at any point in that window, aggregate reports for these domains were being delivered to an unknown party well before this research began. We cannot demonstrate that happened, and we are not asserting it. We note the gap because it is a real one and because a reader reconstructing the history independently will find it.

5.3 The guidance was still live

At the time of disclosure, the training decks were not archived history. They were being served from GCA's own web infrastructure, in two languages.

English: globalcyberalliance.org/wp-content/uploads/2025/05/Week-5-Wrap-Up-Session-3.pdf

Spanish: globalcyberalliance.org/wp-content/uploads/2025/05/Week-5-Wrap-Up-Session_ES_FINAL.pptx.pdf, with the slide titled "Registro de texto en el DNS para DMARC"

A French version of the same deck exists and is linked from the same resources page. It does not contain the endpoint. That is worth stating precisely, because it narrows the scope and because the alternative, claiming three instances where there are two, is exactly the kind of imprecision that undermines everything else in a document like this.

Three details in the two affected decks deserve attention.

The endpoint has been in this curriculum since 2019. The slide is not a recent artifact. The reporting address appears, filled in as rua=mailto:dmarc@gca-emailauth.org in both the Basic and Complex examples, in GCA's own recorded "DMARC Bootcamp Wrap-Up Session," published to GCA's YouTube channel and presented by their Director of Operations. The domain was first registered in September 2019, so the endpoint entered the teaching materials essentially as soon as it existed. This matters as evidence because a video cannot be quietly amended the way a hosted file can. The PDF on the website can be re-exported; the recording is a fixed, public, timestamped record of exactly what was being taught, and it shows this endpoint.

The files were re-exported as recently as 2024 and re-served in 2025. The PDF metadata on the English deck shows a conversion date in February 2024, and the files are served from a 2025/05 upload directory. So this was not a 2019 artifact left to rot in place. The material was maintained, re-exported, and re-published years after the domain behind it had first lapsed, with the dead endpoint carried forward each time.

There is a Spanish translation. Someone invested in localizing this curriculum for a wider audience. That is evidence of an active, resourced program, not a forgotten page in a resource library.

Because the materials remained uncorrected, they kept affecting the same population and could still reach new adopters. Every organization in Section 6 is a past adopter. Anyone completing the DMARC bootcamp and following slide 7 as written would have published a rua= pointing at a domain nobody in the chain controlled.

This is what made the disclosure to GCA urgent in a way the domain transfer was not. The transfer closed the existing exposure. Only correcting the materials stops new organizations joining it. GCA's response to that is covered in Section 11.

5.4 Why the adopter profile fits

The 86 affected domains are not a random sample. They cluster around the profile of an organization that would have used free DMARC tooling in the 2016 to 2019 window: no dedicated email security budget, no commercial DMARC vendor, an IT generalist implementing from a guide.

The single largest cluster is a genuine exception, and not in the direction the profile predicts. The Toro Company runs a mature, commercially tooled, fully enforced DMARC program. They are not an organization that lacked resources and followed a free guide. The endpoint reached them by a different route, and that route is the more interesting one. It is covered in Section 6.3 and Section 12.

6. Who was affected

6.1 Cluster breakdown

Status as of the verification sweep run 5 August 2026.

6.2 Notable individual exposures

The Toro Company, 56 domains. The largest single cluster at 65% of the affected population. It spans eight distinct sub-portfolios: corporate and marketing including torocompany.com, toro.us and the international ccTLD set; product and program microsites including myturf.com, torolynx.com, toroinfinity.com and snowrator.com; the Exmark brand; Ditch Witch and Charles Machine Works including the RS Lining acquisitions; BOSS Snowplow; the irrigation and lighting brands Irritrol, Rain Master, SMRT Logic and Unique Lighting; Hayter in the UK; and a homoglyph cluster.

toro.com itself is not affected.

The homoglyph cluster is four domains substituting a zero for the letter O: tor0.com, tor0.net, t0ro.com, t0r0.com. Their ownership determines which of two very different findings applies. If Toro registered them defensively, the observation is ironic but minor. If they belong to an unknown party, four homoglyph domains impersonating a NYSE-listed manufacturer and actively publishing DMARC policy is a materially more serious and separate finding.

The evidence points to the first reading. All four resolve to Toro's shared DMARC record. Three of them appear in the received report data as failing sending identities against Toro's own enforced policy, which is the signature of a defensively registered domain being spoofed by somebody else rather than attacker-owned infrastructure. That is exactly the outcome a defensive registration plus an enforced policy is designed to produce.

The same ownership question applies to the .ru and .cn entries, which are more plausibly distributor-registered than corporate-registered. irritrolsystems.ru resolves to parked.thetoroco.com, which indicates Toro either controls the DNS or supplied distributors with a standard record to deploy. Those are different answers and this document does not blur them.

Great Prairie AEA (gpaea.org). An Iowa Area Education Agency serving over 35,000 students and 2,700 teachers and administrators across 32 public school districts in southeast Iowa, along with a number of accredited non-public schools, and providing special education services to children from birth to age 21. Remediated within roughly 24 hours of notification, the fastest response in the campaign, from the organization with the fewest resources.

Scioto County Developmental Disabilities (sciotodd.org). An Ohio county board serving individuals with developmental disabilities.

Ennis ISD (ennis.k12.tx.us). A Texas public school district.

Licking County, Ohio and Winnebago County, Iowa (LickingCounty.gov, winnebagocountyiowa.gov). Two US county governments. Handling is covered in Section 10.

Managed Services Company (managed.sa). A Saudi Arabian firm within the Mohammed AL-Ojaimi Group. Notified through the group's Chairman and its CISO, whose remit is described in terms of fintech and point-of-sale security and SAMA, NCA and PDPL compliance. This is regulated financial-adjacent infrastructure in a jurisdiction with an active data protection regime, and it does not belong in an assorted commercial bucket. Severity for this entry is higher than the cluster average.

Azimco (azimco.onmicrosoft.com). An unusual entry: a Microsoft 365 tenant vanity domain published as a DMARC policy domain. Tenant naming is not secret but is not normally advertised in public DNS either.

6.3 The Toro delegation architecture

The Toro domains do not each publish an independent DMARC TXT record. Fifty-four of them delegate by CNAME to a single shared record.

The shared record resolves as:

$ dig +short TXT _dmarc.parked.thetoroco.com @1.1.1.1
v=DMARC1
 p=reject
 fo=1
 rua=mailto:dmarc_rua@emaildefense.proofpoint.com,mailto:dmarc@gca-emailauth.org
 ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com
 sp=reject
 ri=86400

That record inverts the expected story in three ways.

Toro is at p=reject with sp=reject. Full enforcement including subdomains. This is the strictest DMARC posture available and most organizations never reach it.

Their primary reporting destination is Proofpoint, at dmarc_rua@emaildefense.proofpoint.com, with forensic reporting to the matching ruf address. They pay for commercial DMARC processing from a tier-one vendor.

gca-emailauth.org is the second address in a two-address rua list. It is not Toro's primary destination. It is a second destination, appended alongside the working commercial one they actually monitor, which is why it went unnoticed.

Three consequences follow, and they matter more than any other technical detail in this document.

It destroys the resourcing narrative. The convenient version of this story is that under-resourced organizations followed free guidance and never revisited it. That version holds for the education and municipal clusters. It does not hold for 65% of the affected domains. Toro has a security program, a CISO, a commercial DMARC vendor, and full policy enforcement. They did everything the maturity model asks for, and the leak persisted through all of it.

It explains the non-response better than indifference does. Toro's DMARC monitoring works. Reports arrive at Proofpoint, dashboards populate, alerts fire, nothing is missing. There is no operational symptom anywhere in their environment. A notification about a second rua address describes a problem that is invisible from inside the system that would normally detect it. That is harder to triage than a broken one.

It makes remediation trivially cheap. For the 54 delegated domains, the fix is deleting a single string, ,mailto:dmarc@gca-emailauth.org, from one shared TXT record. Not 54 DNS changes across multiple registrars, ccTLDs and acquired-subsidiary estates. One edit, to one record, in one zone, and Proofpoint keeps receiving everything exactly as before. Nothing about their monitoring changes.

6.4 One domain is not delegated, and it is the one that matters most

myturf.com does not CNAME to the shared record. It publishes its own DMARC record directly:

$ dig +short TXT _dmarc.myturf.com
v=DMARC1; p=none; fo=1;
 rua=mailto:dmarc_rua@emaildefense.proofpoint.com,mailto:dmarc@gca-emailauth.org;
 ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com;
 sp=none; ri=86400

Two differences from the shared record are worth reading carefully.

It carries the same two-address rua list, so remediation requires a second, separate edit. The single-TXT-record fix covers 54 domains, not 55.

And it sits at p=none with sp=none, not p=reject. It is the only domain in the Toro portfolio outside the enforced policy.

myturf.com is the fleet-management platform through which distributors and grounds crews manage equipment. As Section 7 sets out, it is the domain whose reports disclosed the distributor network and customer list. That is what makes it matter here: not that it sends the most mail, but that its reports carried the most sensitive relationship data in the incident.

Complete remediation of the Toro portfolio therefore means two separate edits: correcting the shared TXT record that the 54 CNAMEs point to, and separately correcting the TXT record myturf.com publishes directly. A fix applied only to the shared record would leave myturf.com untouched. Whether Toro has a deliberate reason to hold myturf.com at p=none is not something we can see from outside; the point is only that it is governed separately and must be fixed separately.

6.5 spectoro.com, a related but distinct finding

spectoro.com is a lapsed Toro asset with an evidenced report history. Mail.Ru delivered an aggregate report for it to the endpoint on 29 November 2025, so it belongs in the affected set as a confirmed case rather than a suspected one. It continues to serve /nsn/distributortoolkit/ PDFs titled "TORO NSN COMPUTER SPECIFICATIONS", legacy Toro National Support Network distributor-portal documentation, while the domain itself is now parked and advertised for sale. As of the 5 August sweep it no longer publishes the endpoint and now carries an Afternic verification record, consistent with an active resale listing.

Its status should not be read as remediated. Nobody edited a DMARC record to close the leak. The domain was withdrawn from service and put up for sale, and the endpoint reference disappeared with it. That is why Section 11 counts it separately from the domains that were actually fixed.

This is not the reporting-endpoint finding. It is an abandoned domain still hosting distributor-facing corporate documentation and offered on the open market. Whoever acquires it inherits the documentation, the residual traffic, the inbound links from Toro's own distributor materials, and the ability to publish anything at a hostname distributors have been trained to trust.

It is noted here for completeness and because it sits in the same portfolio. It is a separate case and is not developed further in this document.

7. What the reports contained

7.1 Data available at the endpoint

Reports arriving at the endpoint carried, for each affected domain, the full RFC 7489 section 7.2 schema.

The reporting providers are not a narrow set. Microsoft enterprise reporting, Google, Yahoo, AOL, Mimecast, Cisco, Mail.Ru and mail.com all appear, delivering for affected domains across the education, municipal and commercial clusters simultaneously. In aggregate across 86 domains and a multi-month window, that constitutes:

A sending infrastructure map per organization. Every IP that transmits mail on their behalf, whether corporate MTA, ESP, CRM, ticketing system, marketing platform or payroll provider.

Vendor relationship disclosure. DKIM signing domains and selectors identify third-party senders by name. An organization's ESP, CRM, HR platform and transactional mail provider are all legible from the reports without any need to inspect message content.

Authentication posture over time. Which sources pass, which fail, and the trend.

Policy enforcement reality. What receivers actually did, as against what the published policy requested.

Spoofing telemetry. Unauthenticated mail impersonating the domain, with source IPs and volumes. The organization's own attacker activity, delivered to a third party rather than to them.

Recipient domains, wherever the reporting provider populates the optional envelope_to identifier. That is, who the organization sends mail to, broken down per sending domain and by volume.

7.2 The relationship data

The last item is the one worth dwelling on, because it inverts the usual framing of what a DMARC report exposes.

Where envelope_to is populated, the reports reconstruct the organization's correspondent list.

For the Toro portfolio, the received data resolves the recipient side of each sending stream by volume. The myturf.com fleet-management platform resolves to what is recognizably the North American distributor network: named equipment dealers, each with its own message volume, which is a usable proxy for account size. Below the dealers sit end customers. Named golf and country clubs across the United States, Norway, Sweden, Spain, Switzerland and Australia. Hospitality groups. A long tail of municipal parks departments and city domains, including .gov recipients. The smrtscape.com irrigation platform resolves the same way to its own customer set.

This is a customer list with relative account sizes attached. It is not inferable from infrastructure data, it is not public, and no organization publishing a DMARC record expects to be disclosing it.
‍
The two captures below illustrate the field using real data, but neither comes from gca-emailauth.org or from any of the 86 domains in this incident. They are from separate, previously remediated research. The first is SH Consulting’s analytics-platform rendering of the envelope_to column: the sending domain is obscured while the recipient domains remain visible. The second is the underlying Microsoft aggregate report from the same unrelated case, where the recipient domain appears directly inside the <identifiers> block. Source and sender-identifying fields are redacted.

The recipient values from the gca-emailauth.org incident are withheld. The captures above are illustrative examples from separate, previously remediated research and contain no data from any of the 86 affected domains. In the abandoned-endpoint dataset, the envelope_to values resolve to named third-party organizations, dealers, clubs, hospitality groups and municipalities that are not parties to this research and did not consent to appear in it. The full, unredacted incident-specific captures were supplied to the affected organization and are withheld from this and every public version. Showing that the field can carry a correspondent map is the finding. Publishing that map itself would reproduce the harm this section describes, so we do not.

7.3 What an adversary gains

Target selection. The vendor map identifies supply-chain entry points. Knowing an organization sends through a specific ESP tells you which vendor compromise yields authenticated mail from that domain.

Spoofing viability assessment. Reports show the effective policy. A domain at p=none, or one enforcing on only a fraction of failing mail, is a viable spoofing target, and the reports say so precisely.

Pretext construction. Sending patterns reveal which systems generate mail, at what cadence, to what volume. Invoice runs, HR notifications and customer communications are all inferable from volume patterns and signing domains, which is exactly the material required to construct a convincing business email compromise pretext.

Counter-intelligence. The organization's own spoofing telemetry, meaning who is already impersonating them, from where, and at what scale, is delivered to the party at the endpoint rather than to the defender. The defender does not know they are being spoofed. The party at the endpoint does.

This is not hypothetical, and the clearest example is also the most uncomfortable. Reports for gpaea.org, the Iowa education agency serving over 35,000 students across 32 public school districts, showed sustained unauthenticated traffic during the exposure window. Filtered to failing mail, the reports record 2,563 messages that failed both SPF and DKIM against the domain, spread across 122 sending hostnames and 1,422 distinct source IP addresses, reported by five independent providers, with DMARC compliance on that traffic sitting at zero.

The source distribution is what makes it legible. The highest-volume failing streams resolve to national telecom infrastructure across Central Asia and beyond: telecom.kz and kcell.kz in Kazakhstan, ktnet.kg and aknet.kg in Kyrgyzstan, uzpak.uz and albatros.uz in Uzbekistan, alongside .ru, .vn, .tz and .pk hosts. That is not the footprint of a marketing platform an agency forgot to authorize. It is a domain being used at scale by senders it never authorized, from networks an Iowa education agency has no plausible business relationship with.

A caveat worth stating. Not every failing stream is hostile. The same view shows legitimate senders failing too: sendgrid.net, Amazon SES, and Google infrastructure all appear, which is the ordinary signature of a sending service the agency uses but never brought into SPF or DKIM alignment. The 2,563 figure is failing mail, not confirmed malicious mail. The Central Asian telecom concentration is the part that reads as impersonation. The ESP failures are the part that reads as unfinished configuration. Both matter, and they are different problems.

GPAEA had no visibility into either. The reports documenting this traffic were being delivered to a domain they did not control, and the fact only reached them because the party receiving those reports told them. An agency serving 35,000 children was being impersonated at significant volumes, the evidence existed, but it was arriving at the wrong address.

Remediation blindness, where the endpoint was the only destination. The severity of this depends on whether an organization published a second, working reporting address alongside the endpoint. Where it did, its reports still reached a mailbox it controlled, and it retained visibility. Toro is the clearest such case, with Proofpoint alongside the endpoint. But any organization that published the endpoint as its sole rua had no visibility at all for as long as the record stood: it was publishing a reporting policy under the impression it had monitoring, and had none. We cannot reliably reconstruct, from records that have since been remediated, how many organizations were in that position, so we make no count. The point is that for a domain whose only reporting destination was this endpoint, DMARC provided no monitoring whatsoever while the record stood.

7.4 Severity

Aggregate reports contain no message bodies and no subject lines, and any honest severity assessment should say so first.

Infrastructure and authentication data: moderate. Source IPs, vendor identification, policy posture, failure trends. Useful to an attacker, not catastrophic, and recoverable.

Relationship data: high, and not recoverable. A distributor network with volume-weighted account sizes, a named customer list spanning multiple countries, and municipal and government recipients. Unlike a leaked credential, this cannot be rotated. Once the correspondent map is out, it stays out.

Diverse and sensitive data, aggregated across 86 domains and 20+ organizations: high. A curated view of a specific institutional population, machine-parseable, delivered daily, at roughly $10 per year.

There is also a point about who carries this risk. The organizations affected are disproportionately those that adopted free tooling because they could not afford commercial alternatives. The exposure tracks the resource gap the tooling was created to close.

8. What the received data shows

The received data does not only describe what an attacker could do. It documents the actual state of these domains during the exposure window.

Report flow continued throughout the disclosure period. This is a single aggregate report, delivered by Microsoft to dmarc@gca-emailauth.org for toro.com.au, covering the 26 to 27 July 2026 window and received on 28 July. By that date, some weeks had passed since the notification and follow-up to Toro, and reports were still arriving.

The portfolio-level view covers 28 June to 27 July 2026.

One detail about the window is worth noting for interpretation, not for blame. It falls entirely after the first notification to Toro and almost entirely after the follow-up. So this is not a snapshot of the exposure before anyone was notified; it is a month of report flow from the recent, post-notification period, which is what makes it evidence that the condition was ongoing rather than historical at the time of writing.

8.1 The "parked" record is not on parked domains

This is the mechanism of the entire Toro exposure, and it is visible in one screen.

The shared record every delegated Toro domain points at is named _dmarc.parked.thetoroco.com. The name states the intent: a baseline policy for dormant assets, set once and reasonably left alone. The domains inheriting it are not dormant.

myturf.com sent 3,754 authenticated messages in 30 days. smrtscape.com, the irrigation platform, sent 1,126. mytoronsn.com, the National Support Network portal, sent 160.

These are live, customer-facing business systems governed by a record built for domains nobody uses.

This is how production platforms ended up governed by a record built for dormant domains. Nobody made a deliberate decision to route myturf.com reporting to gca-emailauth.org. The domains were pointed at a shared baseline record at some point, that baseline carried the endpoint, and the baseline was never re-examined because a record named for parked domains does not invite review, even as the platforms under it grew into live production systems.

The general pattern is worth stating plainly. A policy record inherits the review cadence of its name, not of the domains actually using it. Anything labelled parked, legacy, default or baseline gets audited least, and precisely because it is the convenient default, tends to accumulate the most domains.

8.2 Scale and concentration of failures

Across the portfolio over 30 days: 5,412 messages evaluated, 94.1% compliance, and 318 failing messages spanning 32 distinct sending domains from 182 distinct source IP addresses, reported by eight independent providers.

Broken out by domain:

The distribution is extremely top-heavy. torogroundsforsuccess.com alone accounts for 205 of 318 failures, which is 64% of everything observed. yardcare.com adds 20. Everything else is in single or low double digits.

Resolved by sending host, the concentration is sharper still:

The dominant streams route through a single bulk relay provider across 76 and 57 source IPs respectively. This matters for the country chart on the portfolio dashboard. Canada's 216 failures, which is 68% of the total and roughly seven times the United States figure of 31, are nearly all this one relay.

Geographic attribution from DMARC source IPs describes hosting and relay providers, not adversaries. Any organization drawing threat-origin conclusions from the country column of a DMARC dashboard is reading provider footprint. It is worth stating explicitly, because an incomplete reading produces a headline about Canadian attack infrastructure that the data does not support.

8.3 The long tail looks like genuine abuse

Beneath the relay concentration sits a scattered tail across a wide range of hosting and consumer infrastructure. Russian, Chinese, Brazilian, Ukrainian, Dutch, Spanish, French, Taiwanese and Australian sources, reported by Mail.Ru, wp.pl, o2.pl, Zoho, Yahoo and Google.

Two patterns in this tail are worth drawing out.

Randomized-subdomain probing. Multiple streams originate from random-string subdomains: vxxhgpym.toro.us, pnvdr.toro.us, imkpp.toro.us, unuvts.toro.us, pbr.toro.us, ew.toro.us, and a two-level ydy1gc.r8rtqd.exmark.us. This is a deliberate test of subdomain policy inheritance. Toro's sp=reject defeats it. The record of the attempts reached Toro's own processor and also, because of the second reporting address, a stranger's mailbox.

The homoglyph domains are in use. tor0.com, t0ro.com and t0r0.com all appear as failing sending identities, from AWS infrastructure, reported by Google. As noted in Section 6.2, they resolve to Toro's shared record and sit at p=reject, so the enforced policy is defeating the attempts. The evidence is consistent with Toro-owned defensive registrations being spoofed by a third party.

8.4 Enforcement is working, and that is the problem

Adding the disposition and envelope-from columns shows what receivers actually did.

Every failing stream carries reject. Toro's policy is being enforced by receiving providers exactly as published: 94.12% compliance, 5.82% of traffic having policy applied, zero blacklisted traffic.

There is no failure state anywhere in this picture. A security team reviewing these numbers in their own Proofpoint console sees a healthy, well-run program and closes the tab. That is why a second rua address survives for years without anyone querying it, and it is the argument of Section 12 rendered as a dashboard.

8.5 The largest failing stream is not an attack

An earlier reading of this data characterized the torogroundsforsuccess.com traffic as a phishing campaign directed at Toro employees. That characterization is not supported and should not be repeated.

The envelope-from column shows the largest failing streams carrying mail1.wpengine.com as the return path, relayed through a bulk provider that is the default outbound path for a great many shared WordPress hosts.

Direct verification closes it. The domain resolves to 141.193.213.10 and 141.193.213.11, which is WP Engine address space. Its SPF record reads:

$ dig +short TXT torogroundsforsuccess.com
"v=spf ms -all"
"groundsforsuccess2.azurewebsites.net"
"google-site-verification=tsGFMLnNzajHVAmbUhS9T4PKtDcY3SY6LjuB92UlRas"

v=spf ms -all is not a valid SPF record. Receivers cannot obtain an SPF pass from that record; absent another valid SPF record, SPF therefore cannot satisfy DMARC for mail using this domain. There is no aligned DKIM signature either, so those messages fail DMARC.

So the explanation is mundane. A Toro marketing microsite on WordPress hosting, still live, still sending mail, never correctly added to the domain's SPF record and never DKIM-signed. Every message it sends fails DMARC and gets rejected under the inherited p=reject. Mail addressed to toro.com is most plausibly internal notifications or form submissions from that site to Toro staff, not an adversary.

That reading fits the evidence better than an attack does, and it is the more interesting finding. Sixty-four percent of the apparent spoofing against this portfolio is Toro sending mail to itself from a forgotten property it no longer authenticates. Toro's own reporting would show this, since these reports reach Proofpoint like everything else; what makes it easy to overlook is that it looks like ordinary policy enforcement working correctly, failing mail being rejected, rather than a misconfigured internal sender. The additional wrinkle is that a copy of every one of these reports also went to the abandoned endpoint, so a stranger saw Toro's internal mail failures too.

It is also a second-order finding about validators. A malformed record like this has almost certainly gone unread since the day it was added. Most SPF checkers we have tested either ignore a record like this or report the domain as having no policy rather than a broken one, so the failure is silent in the same way the reporting-endpoint failure is silent: nothing surfaces it to the person who could fix it.

The genuine abuse in this dataset is the long tail: the CIS and Asian-hosted streams, the randomized subdomains, the homoglyph domains. It is smaller than the headline number and it is real.

9. Custody and handling

This is the section where a reader determines whether this was research or collection. It is stated in full rather than summarized.

9.1 Endpoint configuration

The endpoint was a Google Workspace mailbox on GoDaddy DNS. Eight records, no web presence.

Three things follow, and all three are stated here rather than left to be discovered.

Mail was received, not merely bounced. A single MX to Google Workspace. Reports arrived in a mailbox.

There was no web service. No A record, no hosting. The domain served no purpose beyond receiving mail, which is consistent with the defensive-registration account and not with anything else.

The EDV record was a wildcard. *._report._dmarc with v=DMARC1 authorizes report delivery from any domain on the internet, not only the 86 enumerated. This is the conventional configuration for a report-receiving endpoint, since a per-domain record for each of 86 policy domains would be unmanageable, and it is what the original operator would have needed too. But it means the scope of what the endpoint could receive was unbounded rather than fixed at 86. A reader who finds a wildcard authorization that this document did not mention would be right to read the omission as concealment.

9.2 Processing and retention

Reports were ingested into SH Consulting's own DMARC analytics platform, parsed to per-message-stream granularity, and retained in a queryable window. The Section 8 exhibits are captures from that platform and evidence the depth of processing directly. No third-party analytics service touched the data.

The envelope_to values collected through gca-emailauth.org are the most sensitive material held from this incident, and they belong to third parties who are not party to this research: Toro’s dealers, customers and municipal accounts. They were queried once, to establish the finding in Section 7.2. They have never been extracted, exported, enriched or shared with any party other than the affected organization itself.

The visible envelope_to values reproduced in Section 7.2 are from separate, previously remediated research and are not part of the gca-emailauth.org dataset.

Findings derived from report data were shared only with the organization they concerned. The GPAEA analysis in Section 7.3 is an example: it went to GPAEA and nowhere else. Per-domain forensic detail at that level exists for every affected domain, since the same reports that carried the endpoint exposure also carried each domain's full authentication picture. That detail was provided to each organization in its notification. It is not reproduced here for organizations other than the illustrative case, both to keep this document to a reviewable length and because publishing every affected domain's sending infrastructure would itself be a disclosure. In the copy of the UWSP disclosure retained as evidence, third-party vendor names identified from report data are masked, though they were not masked in the mail that actually went to UWSP. That masking is a handling control applied to the evidence set, and it is visible in Exhibit E1.

9.3 Exit

The MX record and the wildcard EDV record were both removed on 30 July 2026. Removing the MX stops delivery. Removing the EDV withdraws consent at the protocol level, which is the more complete exit of the two, and it is the same record that authorized report delivery in the first place.

Reports therefore arrived over the period from 20 November 2025 to 30 July 2026.

One thing worth stating plainly, because it is a finding in its own right: removing the MX stops reports arriving, but it notifies nobody. Google and Microsoft log the delivery failure and move on. Nothing reaches the domain owner. There is no mechanism in DMARC by which a dead reporting destination produces a signal at the organization publishing the record. The exit is as silent as the entry.

The domain was transferred to the Global Cyber Alliance at no cost. Registration was maintained by SH Consulting throughout the transfer window so that it could not lapse a second time in the interim.

9.4 Data handling

SH Consulting is registered in Poland and operates in the EU and the United States. The reports were received rather than solicited: no report was requested, and other parties' DNS directed them to the endpoint. They were used only to identify and notify affected organizations and to establish the findings in this document, were not shared with any party other than the affected organization each concerned, and are scheduled for deletion on 11 November 2026.

10. Disclosure

10.1 Method

The disclosure model applied here is the one used in prior SH Consulting research, including the Hazy Hawk subdomain takeover campaign across 34 US universities: notification, a lapsed remediation window, and publication independent of remediation status.

Publication is not contingent on organizations fixing the issue. It is contingent on their having been told, and having had a reasonable opportunity to act.

10.2 Timeline

Two observations on that timeline.

The collection window is materially longer than the May 2026 campaign implies. The first disclosure is dated 21 November 2025, the day after registration, and already states that reports had been received. The window is a little over eight months, not the two the May correspondence might suggest.

And the disclosure practice deserves noting because it is what distinguishes a disclosure campaign from a notification blast. The Toro notification went to the CISO, three named stakeholders, and the RFC 2142 postmaster@ and abuse@ role addresses, which is the correct belt-and-braces approach for an organization whose named contacts may have moved. The managed.sa sequence escalated to the group Chairman only after the CISO went quiet.

10.3 What the notifications contained

Notifications provided the specific affected domains, the exact DNS record at issue, an independently runnable verification command, a plain-language description of the exposure, and the remediation step. Where report data revealed material authentication problems unrelated to this finding, such as SPF failures, active spoofing, or deprecated tags, those were provided to the affected organization as well.

Register was adapted per recipient, and the evidenced disclosures show the range.

University: technical, enumerated, sent to a security function. All fourteen affected zones listed explicitly, routed to the Information Security Office with the responsible administrator and a system-level contact copied.

Education agency: plain language, operational finding foregrounded. No jargon, single-sentence remediation, and the spoofing analysis delivered as the more urgent item. The recipient was an IT generalist at a regional agency, not a security specialist, and the mail was written for that reader.

Corporation: concise, quantified, belt-and-braces on addressing. Scope, mechanism, impact and remediation in five short paragraphs.

Government: through the coordinating body. The two .gov domains were disclosed to CISA rather than to the county governments directly, as part of a wider notification covering exposed DMARC reporting destinations across multiple US government domains.

No security contact reachable: channel improvisation and escalation. Where no security address was published, contact was made through LinkedIn to the named CISO, and escalated to the group Chairman three days later when the first went unanswered.

These are reproduced rather than summarized because the accountability argument in Section 11 depends entirely on the notifications having been substantive, well-addressed, and comprehensible to their recipient. A reader who wants to test that claim can now test it.

10.4 Two things we would do differently

The notifications said there was no recipient information. That was accurate as to message bodies and subject lines, and it is how the protocol is normally summarized. It sat alongside envelope_to data that was in fact held. Nobody was misled about anything material and the framing was made in good faith, but organizations remediated partly on the strength of that description, and this document states that recipient domains were present. Affected organizations were sent a correction before publication rather than being left to notice the discrepancy afterward.

Notifications did not name GCA. Affected organizations were told the endpoint was an abandoned third-party domain, without attribution. The reasoning at the time was defensive: naming a specific nonprofit in correspondence sent to more than 20 organizations creates a risk of the attribution reaching that nonprofit through an uncontrolled channel, in a form they cannot respond to, before they have been told directly.

That sequence, meaning affected parties first, named third party before publication, publication last, is the one we would use again. It is stated here rather than left for a reader to reconstruct.

One further note on method, since this document is partly a record of process. Our standard practice is to offer a draft to disclosure recipients for review before publication. That offer was not made here. GCA was given the findings in full, in writing, twelve days before publication, and was invited to correct anything factual or provide a statement. They were not sent the draft itself.

10.5 Coverage of the notification campaign

Notification coverage was not complete, and the gaps are stated here rather than left to be inferred.

Seventy-four of the 86 domains were notified in the November 2025 and May 2026 rounds, covering UWSP, Great Prairie AEA, The Toro Company, managed.sa, and the two .gov domains through CISA.

Three further domains, ennis.k12.tx.us, sciotodd.org and vivida.io, were missed in those rounds and were notified on 5 August 2026, six days before publication. That is a notification, not a remediation window, and their status in Section 11 should be read accordingly. No conclusion is drawn from it.

Four domains could not be notified. koolcats.biz, fenton.biz and azimco.onmicrosoft.com have no identifiable operator: no website, no published contact, and no registrant information beyond privacy protection. xmxf98.com publishes no MX record at all, so the domain cannot receive mail on any address, including the role addresses an abuse notification would normally use.

That last case deserves a sentence of its own. A domain that publishes a DMARC policy but cannot receive mail is a configuration nobody can be told about. There is no channel. Whatever process produced that record left no way to reach whoever owns it, and the domain will keep publishing the endpoint until somebody corrects or changes the affected DNS.

The remaining five domains, the four belonging to NCSSM and electronbeamservices.com, were never contacted by us and remediated anyway. That is covered in Section 11.2.

This matters because the accountability argument in Section 11 depends on it. An organization named as unremediated has to be one we can evidence having notified, with adequate time to act. Where that is not the case, it is said here.

11. Remediation status

11.1 The numbers

A verification sweep was run across all 86 domains on 5 August 2026, resolving _dmarc.<domain> for both CNAME and TXT and checking whether the currently published record names the endpoint. The method is in Appendix B and is reproducible by anyone.

65 of the 86 domains still publish the endpoint. Twenty-one no longer do.

Of the 74 domains whose owners we notified directly, 15 have remediated: the fourteen UWSP zones and Great Prairie AEA. One further notified domain, spectoro.com, no longer publishes the endpoint, but it was not remediated in any deliberate sense. It was withdrawn from service and listed for sale, which is a different event and is treated separately in Section 6.5. Counting it as a fix would overstate the remediation rate. Of the 74 notified domains, 15 were remediated and one (spectoro.com) was withdrawn from service, leaving 58 that still publish the endpoint.

Because the Toro cluster is 65% of the affected population and 54 of its domains are governed by a single shared record, the headline number is dominated by two unmade edits. One edit to the shared record removes the endpoint from 54 domains at once, by deleting the ,mailto:dmarc@gca-emailauth.org string from the rua list. A second edit, on myturf.com, covers the fifty-fifth.

11.2 The organizations that fixed it without being told

Five domains remediated with no contact from us at all, and they are worth more attention than the raw figure suggests.

NCSSM remediated all four of its domains. ncssm.edu now publishes v=DMARC1; p=reject; rua=mailto:oic+dmarc-forensics@ncssm.edu, pointing at an internal address. The other three subdomains no longer resolve at all. Somebody at a public residential high school reviewed their own DMARC records, found a rua destination they did not recognize, and redirected it to an internal address. One commercial domain, electronbeamservices.com, also remediated without any contact from us, though its record leaves no trace of how or why. NCSSM is the clearest case of an organization deliberately catching this on its own: the redirect to a named internal mailbox shows someone understood what they were looking at, rather than the exposure disappearing as a side effect of some unrelated change.

electronbeamservices.com likewise now points its reports at a destination under its own control.

That is the answer to the obvious question this research raises, which is whether an organization can realistically be expected to catch this. One of them did, and it was not the one with the largest security budget.

11.3 UWSP closed it by going blind

UWSP remediated all fourteen domains, and the method is worth recording. Their records now read:

v=DMARC1; p=reject; fo=1;

There is no rua tag at all. The reporting destination was not redirected. It was deleted.

That closes the exposure completely and it is a legitimate response. It also means the institution now has full policy enforcement and no visibility into what that policy is doing. Fourteen zones at p=reject with no aggregate reporting is a configuration where a broken sender fails silently and permanently.

The safer remediation is to redirect the rua to an address under your own control rather than remove it. Deleting the tag solves the disclosure problem, but creates a monitoring one.

11.4 The distribution is the finding

The organizations that remediated fastest were the ones with the least security resource. A regional education agency in southeast Iowa closed the issue in roughly 24 hours. A public high school found it unprompted. A NYSE-listed manufacturer with a named CISO, a commercial DMARC processor and full policy enforcement has not responded to three contacts across ten weeks, for a fix that is two DNS edits: one to the shared record covering 54 domains, and one to myturf.com.

This reframes the research. The story is not that organizations misconfigured DMARC. Misconfiguration is unremarkable and blameless, since the configuration was correct when it was made. The story is that organizations were told, by name, with the affected records enumerated and a verification command supplied, and most of the affected domains still publish the endpoint.

That is not a technical finding. It is a finding about how security notifications are received, triaged and disposed of inside organizations that have the resources to act on them.

11.5 Removing the endpoint is not the same as being protected

There is a category of response worth isolating, because it looks like success and is not quite.

An organization can remediate the reporting exposure, redirect its rua to a destination it controls, close the leak completely, and still leave itself open to the exact impersonation the reports documented. The two are independent. Fixing where the reports go does nothing about whether the policy those reports describe is actually enforced.

Great Prairie AEA is the clearest example, and it is an uncomfortable one to raise given how well they handled the disclosure itself. Their reporting exposure is fully closed. The rua now points at three processors under their own control. On the endpoint question, they are a model.

Their published policy is p=reject, which reads as full enforcement. The complete record is p=reject; sp=reject; pct=10.

That pct=10 changes what the policy does. The tag limits how much of the failing mail the published policy is actually applied to; the rest falls through to the next-lower disposition. For a reject policy at pct=10, roughly one in ten failing messages is refused and the other nine in ten are quarantined rather than rejected. Quarantine means delivered to the recipient, in a spam or junk folder, from which a user can retrieve it. It is not refusal.

The strongest evidence for this is not the tag semantics but the received reports themselves, which show what the receivers demonstrably did with GPAEA's failing mail rather than what a specification says they should. Section 8's disposition data for this domain shows the great majority of failing mail quarantined, not rejected, which is the behavior a pct=10 record produces and is exactly what one would expect a stalled ramp to look like.

A note on the tag, since a technical reader will raise it. pct was removed from the DMARC standard in the 2026 revision, on the grounds that intermediate values were applied inconsistently across implementations. In deployed practice, though, the tag is still widely honored: millions of published records still carry it, and no major mailbox provider is going to start ignoring it overnight and abruptly change enforcement for all of those domains. So "deprecated in the spec" and "ignored by receivers" are years apart. At GPAEA the tag is still doing what it says, which the disposition data confirms directly.

The effect is visible in the same data as the impersonation finding. Across the window, of the messages that failed authentication against gpaea.org, only about a tenth were being refused outright. The remaining volume, including the Central Asian telecom traffic in Section 7.3 that has no legitimate relationship to an Iowa education agency, was being quarantined. Delivered. Landing in mailboxes belonging to a community that includes the families of children receiving special education services, in a spam folder rather than blocked.

Two honest qualifications, because the number invites overstatement. Not all failing mail is malicious: the same view shows legitimate senders the agency never aligned, and those quarantined messages are misconfiguration, not attack. And pct=10 is a legitimate transitional setting, the value an administrator uses for a week or two while ramping toward full enforcement. Seen once, it means nothing.

The difficulty is that it has not moved. Microsoft's aggregate reports show p=reject; sp=reject; pct=10 as the published policy from before this research began, and the same value was still live at the verification sweep.

Whatever the pct=10 was for, it has been the standing configuration for the entire period, not a ramp caught mid-step.

None of this diminishes the speed of GPAEA's response on the endpoint, which remains the fastest in the campaign. It makes a different and more general point. "We fixed it" and "we are protected" are separate claims, and an organization can honestly believe the first while the second is not true. Removing an abandoned reporting destination closes a disclosure. It does not enforce a policy. The work this document asks for in Section 14 is the first of those. The second is a larger job, and the reports show how many domains have not finished it.

12. The disclosure to GCA, and the return of the domain

GCA was notified on 30 July 2026, twelve days before publication. The notification went to their published DMARC program address and to several members of staff, and covered the endpoint, the scope, the live training materials, and the envelope_to finding. It offered the domain back at no cost and no conditions.

GCA's Head of Engineering responded the same day.

The response committed to correcting the affected materials and to running a site-wide scan for other references to the endpoint. It accepted the domain transfer and supplied the target nameservers. It also, notably, opened an investigation into the domain's history rather than simply closing the ticket, and it was that investigation that established the registration timeline in Section 5.2 and the assessment that the domain had most likely belonged to a partner organization rather than to GCA.

The domain was unlocked, nameservers were repointed, and the transfer has completed. No money changed hands in either direction.

Two things about this response are worth stating for readers who will compare it against the rest of Section 11.

The first is speed. Same-day acknowledgment from an engineering lead, on a disclosure that arrived cold from an outside researcher with no prior relationship, is close to the ceiling of what a coordinated disclosure process can produce.

The second is that GCA went looking for the answer rather than accepting the convenient one. The convenient version was a lapsed renewal, which would have been embarrassing but simple. What they surfaced was more awkward: a probable dependency on a partner's infrastructure that had been embedded in published curriculum and had outlived the relationship. They looked into it and shared what they found.

The contrast in this research is not between organizations that had budget and organizations that did not. Every affected organization has been in the same position: a DNS record that was correct when it was written and is not correct now. The variable is what happened after somebody told them.

13. Why this pattern persists

13.1 Five structural conditions

None of these is anyone's fault individually. All of them compound.

DMARC records have no expiry semantics. A record published in 2018 is as authoritative in 2026 as the day it was written. There is no TTL on the validity of the destination, no revalidation, and no staleness signal.

Failure is silent by design. The protocol optimizes for not disrupting mail flow. A reporting destination that changes hands generates no error anywhere, in either direction. Silence is indistinguishable from correctness.

Guidance outlives its infrastructure. A setup guide is a document. Documents propagate: copied into internal runbooks, pasted into ticket templates, reproduced in third-party tutorials, cached, archived, translated. The infrastructure the document references is a service with an operating cost. The document is free to persist forever. The service is not. Nobody owns the job of reconciling them.

This case is the strongest demonstration of that we have documented, and it is stronger than the usual version of the argument in two ways. The guidance did not merely survive its infrastructure in some forgotten corner of the internet. It was being actively served, from the originating organization's own domain, under a 2025 upload path, in translation. And on the evidence the organization serving it was not running the endpoint on its own infrastructure in the first place, so no renewal calendar of its own could have caught it.

Nobody monitors their own reporting destination. DMARC monitoring products monitor authentication results. Nothing in standard tooling watches whether the destination the reports go to is still controlled by the party you chose. The blind spot sits behind the instrument you installed to see with.

A redundant destination produces no symptom at all. This is the fifth condition and it is the one with the widest reach.

An organization with no DMARC visibility eventually notices. Dashboards stay empty, a quarterly review turns up nothing, someone asks why the reports stopped. The absence is a signal, even a weak and slow one.

An organization with two rua destinations, one of which works, never gets that signal. Toro's reports arrive at Proofpoint. The dashboards populate. The data is complete. Every check passes. The second address is a silent copy to a party nobody has thought about since the record was written, and there is no state anywhere in the organization's environment that differs from the state where it does not exist.

Maturity offers no protection here. Full enforcement, a commercial processor, forensic reporting, a named CISO, a security program: all of it was present throughout, and none of it surfaces a second rua address, because none of it treats the rua tag as an asset with an owner. The tag is treated as configuration, and configuration that produces correct output does not get audited.

13.2 What this means for guidance publishers

There is a lesson here that is specific to anyone who publishes technical documentation, and it does not require being a security nonprofit to apply.

Every concrete value in a configuration example is a dependency you are creating in other people's infrastructure. Not a suggestion. A dependency. Some proportion of readers will copy it verbatim into production, because that is what configuration examples are for, and the more authoritative the source the higher that proportion will be.

That has three practical consequences.

Use reserved values in examples. example.com is reserved by IANA for exactly this purpose. Any domain that can be registered by a third party will eventually be registered by a third party. This is precisely the error Cloudflare made with third-party-example.com and corrected.

If you must use a real endpoint, own it, and treat it as production infrastructure with an owner and a renewal process for as long as the documentation exists. If the endpoint belongs to a partner, that partnership is now a documented dependency and needs to be tracked as one.

And when a program sunsets, the materials sunset with it. Retiring the infrastructure while leaving the guidance live is the specific failure mode this document describes.

14. What to do about it

There is exactly one action any organization should take from this document, and it is not a project.

Print your DMARC record. Read the rua= tag. For every address in it, not just the first one, establish who controls the domain on the right-hand side of the @, and when you last confirmed it. If there is more than one address and you cannot immediately account for the second, that is your finding.

dig +short TXT _dmarc.example.com

If the record is CNAME-delegated, follow the delegation and check the record it resolves to, then check whether every domain in the portfolio actually delegates. As Section 6.4 shows, the one that does not is the one that will be missed.

dig +short CNAME _dmarc.example.com

Four follow-on checks are worth the time.

Check every domain, not just the primary. Marketing microsites, acquired-brand domains, ccTLD variants and defensively registered lookalikes all publish DMARC records, and they are the ones nobody reviews.

Check what your "parked" or "default" record actually governs. A shared record accumulates domains. Some of them will have become production systems since the record was written.

Do not remove the rua tag to fix this. Redirect it to an address under your own control. Enforcement without reporting is a configuration where the next broken sender fails silently.

Diarize it. The destination domain's registration expiry is a date in someone else's calendar. If nothing in your process re-checks it, nothing will.

For a portfolio of any size, the check is a loop and takes minutes. The command is in Appendix B.

Appendix A: Full domain inventory

86 domains. Status as of the verification sweep of 5 August 2026.

The Toro Company, 56 domains, 55 still publishing

Corporate and marketing (20)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 (8)myturf.com (direct record, p=none, see 6.4) · yardcare.com · torolynx.com · toroinfinity.com · mytoronsn.com · snorisk.com · snowrator.com · flex21.com

Homoglyph cluster (4)tor0.com · tor0.net · t0ro.com · t0r0.com

Exmark (5)exmark.net · exmark.us · exmarkdealer.com · exmarkdealers.com · exmarkoriginalparts.com

Ditch Witch and Charles Machine Works (7)ditchwitchdealer.com · myditchwitchdealer.com · ditchwitchgarage.com · theundergroundonline.com · theundergroundmagazine.com · rslining.com · citylinerusa.org

BOSS Snowplow (1)bossplows.com

Irrigation and lighting brands (8)irritrol.email · irritrolsystems.ru · rain-master.com · rainmaster.cn · rainmaster.com.cn · smrt-logic.com · smrtscape.com · lightlogicplus.com

Hayter, UK (1)hayter-limited.org

Other (2)spectoro.com (no longer publishes; now carries an Afternic verification record) · toroag.ru

toro.com is not affected. Fifty-four of the 55 still-publishing domains delegate by CNAME to _dmarc.parked.thetoroco.com. myturf.com publishes directly.

University of Wisconsin–Stevens Point, 14 domains, all remediated

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

All fourteen now publish v=DMARC1; p=reject; fo=1; with no rua tag. See Section 11.3.

NC School of Science and Mathematics, 4 domains, all remediated

ncssm.edu · alumni.ncssm.edu · nutanix.ncssm.edu · lithium.ncssm.edu

ncssm.edu now reports to an internal address. The three subdomains no longer resolve. Remediated without notification from us.

Education and public services, 3 domains

gpaea.org (remediated, roughly 24 hours) · ennis.k12.tx.us (open, notified 5 Aug 2026) · sciotodd.org (open, notified 5 Aug 2026)

US county governments, 2 domains, both open

LickingCounty.gov · winnebagocountyiowa.gov

Disclosed to CISA on 9 June 2026.

Unclassified commercial, 7 domains

managed.sa (open, notified Nov 2025) · vivida.io (open, notified 5 Aug 2026) · koolcats.biz (open, no identifiable operator) · fenton.biz (open, no identifiable operator) · electronbeamservices.com (remediated without notification) · azimco.onmicrosoft.com (open, no identifiable operator) · xmxf98.com (open, publishes no MX record and cannot receive mail)

Appendix B: Verification

Everything in this document can be checked independently. These are the commands.

Check one domain:

dig +short TXT _dmarc.example.com

Follow a CNAME delegation:

dig +short CNAME _dmarc.example.com
dig +short TXT _dmarc.parked.thetoroco.com

Check for an External Destination Verification record:

dig +short TXT example.com._report._dmarc.processor.example
dig +short TXT *._report._dmarc.processor.example

Sweep a portfolio, capturing both CNAME and TXT:

while read d; do
  printf '%s\t%s\t%s\n' "$d" \
    "$(dig +short CNAME _dmarc.$d | tr -d '\n')" \
    "$(dig +short TXT _dmarc.$d | tr -d '\n')"
done < domains.txt

This is the command used to produce the 5 August 2026 figures in Section 11. Run it against the inventory in Appendix A and the numbers in this document are reproducible, subject to remediation that has occurred since.

Remediation. Edit the rua= tag to name a mailbox under a domain you control. Do not simply delete it.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Appendix C: Evidence exhibits

Series A: Attribution and live guidance

Series B: Endpoint configuration

Series C: Toro delegation architecture

Series D: Report flow

Series E: Disclosure correspondence

Series F: Received report data

These particular views are restricted to sending-side data: source IPs, sending domains, hostnames, dispositions and authentication results. The reports themselves can carry recipient information where a receiver populates the optional envelope_to identifier, which Microsoft’s enterprise reporting routinely does, and that is the basis for the finding in Section 7.2. No third-party recipient identity from the gca-emailauth.org dataset is displayed in any F-series capture. The incident-specific envelope_to captures are withheld as described below. The illustrative examples in Section 7.2 come from separate research and are not part of this evidence series.

Illustrative material — not evidence from the gca-emailauth.org incident

Withheld incident-specific material

The envelope_to captures from the gca-emailauth.org incident supporting the relationship-data finding in Section 7.2 are not reproduced in any public version of this document. They contain named dealers, customers, hospitality groups and municipal recipients who are not parties to this research. The two visible envelope_to illustrations in Section 7.2 are from separate, previously remediated research and contain no data from this incident.

Appendix D: Terminology

Aggregate report (RUA). Daily XML summary of authentication results, sent by receiving mail providers to the address in the rua= tag.

External Destination Verification (EDV). DNS-based consent mechanism permitting a domain to receive DMARC reports on behalf of another domain.

Reporting destination. The domain hosting the mailbox named in rua=.

Endpoint abandonment. The condition where a published reporting destination is no longer under the control of the party the domain owner selected, typically through registration lapse.

Homoglyph domain. A domain using visually similar characters to impersonate another, such as a zero substituted for the letter O.

SH Consulting works on email authentication, deliverability and DNS security for organizations sending at scale. If you want your DMARC records, reporting destinations and domain portfolio checked properly, get in touch or book a call.

‍