TL;DR - On 11 August 2026, a researcher revealed that he had spent USD 10 to register an expired DMARC aggregate-reporting domain (
gca-emailauth.org), then quietly received the email-failure telemetry of 86 domains across 20+ organisations including Toro Company (NYSE-listed). 65 of those 86 were still publishing the endpoint at the time of disclosure. The bug originated in training material from the Global Cyber Alliance; the dependency was never written down. If you set up DMARC more than 24 months ago, yourruaendpoint might point somewhere you have not looked at since. What you need to do tonight: pull your current DMARC record, confirm therua=destination still resolves to a mailbox you control, and migrate to an address you actively monitor before you read another security briefing.
If you set up DMARC in 2024 or earlier and have not revisited the rua= record since, this is the evening to spend ten minutes on it. The same instinct that says "audit before you trust the cleanup is complete" applies to the small DNS records you stopped looking at, especially the ones that quietly hand your email telemetry to a third-party inbox you forgot existed.
Get my Personal Security Quick-Start Guide - the practical handbook for the controls that actually change your day. 193 pages, no jargon.
Plus: Join 158+ Australians getting one 5-minute security briefing every Friday.
The PNG and the ten-dollar gamble
On Tuesday I was reading through the morning's r/netsec threads when I hit a post that stopped me cold. A researcher (operating under the consultancy brand sh.consulting) had paid USD 10 to register an expired domain called gca-emailauth.org. That domain name used to be the recommended aggregate-reporting mailbox for organisations that followed the Global Cyber Alliance's email-authentication guides. It was printed into training documents and workshops, the kind of thing a junior sysadmin would copy-paste straight into a DMARC record without thinking.
The domain had lapsed. Nobody had renewed it. So the researcher registered it, pointed it at a fresh mailbox, and waited.
Eight months later, his inbox held the DMARC aggregate reports of 86 domains. Twenty-plus organisations. One of them - Toro Company - is a NYSE-listed Fortune 1000 with a multi-billion-dollar market cap. The rest were a mix of mid-market businesses, regional government departments, and financial-services outfits. These are not vanity domains; they are the production email domains of organisations that handle real inbound and outbound mail at scale.
Every one of those 86 domains had decided - at some point in the past - to send its DMARC failure data to mailto:reports@gca-emailauth.org. Every one of them had forgotten.
65 of the 86 domains were still publishing the endpoint at the time of disclosure. Eight months is a long time to be receiving someone else's email telemetry without anyone noticing.
The report is dated 11 August. The original GCA documentation that recommended the endpoint was years old. The dependency was never written into a runbook or a handover document. It just sat there in a v=DMARC1; rua=mailto:reports@gca-emailauth.org line on someone's authoritative DNS, doing nothing useful for as long as the original GCA mailbox accepted the traffic, then doing something actively dangerous when the domain was allowed to lapse.
By The Numbers
| What | Value | Why it matters |
|---|---|---|
| Cost to register the lapsed domain | USD 10 | The price of a domain that handed over email telemetry for 86 organisations |
| Domains affected | 86 | Production email domains that pointed their rua= at the lapsed endpoint |
| Organisations affected | 20+ | Mix of mid-market, regional government and financial-services |
| Of the 86 still publishing at disclosure | 65 | Three-quarters had not noticed in 8 months |
| Read window before disclosure | ~8 months | How long the researcher quietly held the telemetry |
| Replied to the disclosure | 21 of 86 | The rest did not respond before the researcher's write-up |
| NYSE-listed among them | 1 (Toro Company) | Real Fortune 1000 exposure for a $10 buy |
What was actually in those reports
The bit that reads like a thriller novel but is, in fact, a Tuesday afternoon DNS problem: DMARC aggregate reports (rua) are XML files sent daily by every receiving mail server that processed a message claiming to come from your domain. They tell you the source IP, the SPF pass/fail, the DKIM pass/fail, the alignment verdict, the count, and the disposition (delivered, junked, rejected). They are the raw data you need to see who is sending email as you, whether the attempt is legitimate, and whether your enforcement is actually being applied.
In the wrong hands, that dataset is a map.
An attacker holding 8 months of your DMARC telemetry can enumerate every third-party sender authorised (or not authorised) to send as your domain, find the SPF records that point at forgotten cloud IPs, identify the DKIM selectors your marketing platform rotates every quarter, and time phishing campaigns around the natural spikes in your sending.
This is not theoretical. The data is the instruction manual for business email compromise aimed at your domain specifically. It tells an attacker which senders you trust, which you don't, where your defence is thin (likely p=none), and what your legitimate traffic looks like in volume terms. With that, a well-prepared attacker can craft a campaign that aligns with your real sending patterns enough to slip past the heuristic checks most SMB mail gateways lean on.
How this could happen to anyone
Two conditions had to be true for the GCA leak, and both conditions exist in thousands of SMB environments right now:
1. The rua= endpoint was set once and not revisited. Standard pattern: a junior IT-pro follows a GCA guide (or a CIS Control 9 reference, or an industry-body workshop), publishes a DMARC record pointing at a third-party inbox, then moves on. The record does its job for a while (reports flow, engineering tribal knowledge carries the maintenance, the inbox receives daily mail), but the inbox is not in anyone's onboarding document, not in the runbook, not on the password manager. Then the third-party project ends, the certificate lapses, the consultant disengages - and the inbox quietly dies without anyone noticing.
2. The rua= endpoint was a third-party domain that the org never owned. This is the part that makes the GCA case different from a generic "let your domain lapse" story. The orgs affected did not own gca-emailauth.org. They trusted a guide that pointed them at it. When the org following the guide stops trusting the guide, there is no natural trigger to migrate their DNS record. The guide is gone. The blog post that referred to it is gone. The DNS record remains.
The same pattern will exist tomorrow for any of these scenarios:
- A consultant-led DMARC setup with a
rua=address on the consultant's domain ("send the reports tomyemail@consultancy.exampleso we can review them during the engagement"). - A MSP setup with
rua=pointing at a shared mailbox on the MSP's own domain, where the MSP later lost the engagement or the email account was rotated. - A one-off vendor evaluation where you trialled a "DMARC monitoring tool" that provided a
rua=address on their domain, then stopped subscribing. The address is now your reporting destination forever.
In every case, the report destination is on someone else's domain and that someone else has no contractual reason to keep the address alive.
The five-minute audit you can run tonight
You do not need to wait for a vendor, a tool, or an incident. You need three commands and ten minutes. Run them from any machine with dig (Linux, macOS, or the equivalent in PowerShell).
dig TXT _dmarc.yourdomain.com +short
dig TXT +short rua-endpoint-hostname
nslookup -type=mx rua-endpoint-domain
Read the output. You are looking for three things, in this order.
1. Does your rua= point at a domain you own or actively control? If the output says anything like mailto:reports@vendor-i-tried-2-years-ago.com, mailto:admin@consultancy.example, or mailto:dmarc@somembdtool.io and you are not currently paying that vendor or currently employing that consultant, you are in exactly the position the 86 organisations found themselves. Stop reading and put the next section's remediation on tomorrow's calendar.
2. Does the destination mailbox still exist and is it actively checked? A good answer is "yes, I get the daily digest, here are last week's sample reports". A bad answer is "I have not logged into that mailbox in 18 months" or "the address is an alias that forwards to a security inbox we check twice a year".
3. Is the destination domain still resolving? A dig for the hostname in the mailto: (just the part after the @) should return either an MX record or a CNAME that resolves to one. If it returns NXDOMAIN or SERVFAIL, the destination no longer exists and your reports are being silently dropped - which means you have been flying blind and a future lapsed-domain event will not even generate an alert to you.
If any of those three checks raise an eyebrow, this week's job is to migrate. The migration is not difficult, but it is also not optional.
What to do this week
The right shape for the fix is two-stage. Stage one - tonight - is a stopgap. Stage two - within the week - is the permanent fix.
Tonight (10 minutes):
- Pull the DMARC record and write down the current
rua=value. Paste it into your ticket system or runbook so it is at least documented somewhere you can find it. - Add a calendar reminder 12 months out labelled "DMARC
rua=annual review". This is the single most effective long-term fix: a recurring review date beats a runbook page every time. If you do nothing else, do this. - If the audit suggests the current
rua=is wrong (expired vendor, lapsed consultant, stale MSP), change it tonight to a working address you own. A moving-to-rua=mailto:dmarc-reports@yourdomain.comeven if you do not yet have a parser set up is still safer than arua=pointing at a domain that no longer resolves. Reports you cannot read are better than reports going to someone else's Gmail.
Within the week (an afternoon):
- Pick a permanent address on a domain you own.
dmarc-reports@yourdomain.comorpostmaster@yourdomain.comare conventional. If you already have asecurity@, that's fine too. The key is that the domain in the address matches your sending domain or a sibling domain in your portfolio, not an external party. - If you have access to a DMARC-report parser (open-source tools like
parsedmarcexist, commercial offerings from Proofpoint, Valimail, and others also work), stand it up and pipe the mailbox into your SIEM or alerting bucket. The reports are useful even if you are not actively responding to spoofing attempts; they are the only reliable way to see what third-party senders are claiming to be you. - Move your DMARC policy from
p=nonetop=quarantineif you have a clean two-week window of reporting. The standard SMB cadence is two to four weeks of monitoring before tightening. The GCA leak is one more reason to put that on the calendar rather than leave the policy atp=noneforever - you do not want to discover a reporting gap after you have moved top=reject.
Longer term (this quarter):
- Add
rua=audit to your annual DNS review. The same checklist that catchesp=nonepolicies also catchesrua=drift. - If you operate a portal where clients or partners self-configure their email authentication, add a "this address must be a domain you own" field-level validation. Hard rule: no third-party domains in the
rua=field. This is the structural fix for the entire class of incident. - Subscribe to the
gca-emailauth.orgor similar blog-replacement alerts from the Global Cyber Alliance and the ACSC. The original GCA documentation has been updated to remove the now-compromised endpoint. If you follow their guidance, follow the updated version.
What to do for any other "third-party DNS dep" you have inherited
The DMARC rua= is one of many DNS dependencies that quietly sit on other people's infrastructure. The same shape applies to:
- DKIM selectors on legacy ESP platforms where the ESP was decommissioned but the selector still resolves to a third-party CNAME the org no longer uses.
- SPF
include:statements that point at decommissioned marketing platforms, transactional email providers, or old ticketing systems - they all widen the attack surface for email spoofing as much as the abandonedrua=widens the surface for telemetry exfiltration. - CAA records pointing at CAs that no longer exist (less common but seen in the wild).
The general shape: every DNS record that points outside your organisation is a small contract that your org made with someone else and forgot to terminate. The migration discipline is the same as any other vendor offboarding. If you do not have a written list of every include:, rua=, _smtp._tls, caa=, and mta-sts reference in your DNS, you do not know how many of those you have.
What is going on at the Global Cyber Alliance
To be clear about the source: the GCA is a well-regarded international non-profit that has done more for email authentication adoption than almost any other body. The bug was a training-material refresh that did not happen when the underlying endpoint was decommissioned. The dependency was carried forward in derivative guides and workshop slides that nobody owned as authoritative. The blog write-up from sh.consulting notes that the issue has been disclosed responsibly and that the GCA has updated the affected guides. The lesson generalises: even reputable training bodies have small gaps in their documentation lifecycle. The org responsible for your DNS record is always you.
Frequently Asked Questions
Did I get the GCA leak if my rua= pointed at gca-emailauth.org?
Yes. If your DMARC record contains rua=mailto:reports@gca-emailauth.org (or any other @gca-emailauth.org alias), that report traffic has been routed to a domain now controlled by a security researcher since the disclosure. You should change your rua= to a domain you own today.
Is this a breach of my organisation's email? In the strict sense, no. DMARC aggregate reports do not contain the message bodies of your email. They contain the source IP, the SPF/DKIM verdict, and the count. In the practical sense, yes: an attacker holding 8 months of telemetry has a precision map of who sends as you, which is enough to craft a high-success spoofing campaign. Treat it as a precursor breach and revisit your monitoring posture.
How is this different from a generic email-spoofing campaign? It is not a spoofing campaign at all. The attacker is reading the telemetry that helps a future spoofing campaign succeed. The damage is information leakage about your sending posture, not message interception.
Is the GCA still a credible source for DMARC guidance? Yes. The GCA has updated the guides that referenced the lapsed endpoint. The lesson is "trust the latest version of any guidance, not the version that was current when your DNS record was originally published".
Do I need a commercial DMARC monitoring tool?
No. parsedmarc plus a mailbox you control plus a weekly look at the report is enough for a small IT-pro environment. Commercial tools save analyst time, but they do not save your organisation from a rua= that points at the wrong destination. That check is yours to make.
Further Reading
- sh.consulting - Abandoned DMARC reporting domain - the researcher's own write-up of the GCA endpoint incident
- Expired DMARC reporting endpoint exposed a NYSE Fortune 1000's infrastructure for $10 (r/netsec) - the r/netsec discussion that broke the story on 11 August 2026
- Global Cyber Alliance - DMARC guidance - the GCA's current (post-disclosure) email authentication guides
- CIS Controls v8 - Control 9: Email and Web Browser Protections - the canonical control that calls out DMARC reporting hygiene
- parsedmarc - open-source DMARC report parser - the free, self-hostable tool that turns the XML reports into something queryable
- ACSC - Email hardening guidance - the Australian Cyber Security Centre's email posture guide
- Your domain still says yes to everyone (IT-pro brief, August 2026) - the earlier IT-pro brief that covered
p=nonetop=rejectmigration, useful context for any org moving from monitoring to enforcement
Mathew Clark Founder, SecureInSeconds Currently: writing a recurring "annual DNS review" calendar invite for the same six anchors I keep meaning to add every August.
