The Unregistered RUA Domain: A Class of DMARC Vulnerability Hiding in Plain Sight

In mid-2025, during routine domain structure analysis on a hosting provider's legacy subsidiary, we noticed a DMARC record on zitcom.dk with the reporting destination rua=dmarc@dk-team.blue. The pattern was unusual — dk-team.blue looked like an internal naming convention, presumably a domain the parent company (team.blue) had intended to register but never did.

A quick check confirmed it: dk-team.blue was not a registered domain. Anyone could buy it for the cost of a .blue TLD registration and start receiving DMARC aggregate reports — containing source IPs, sending volumes, internal infrastructure references, and authentication patterns — from a hosting subsidiary's production mail.

We reported the finding through team.blue's vulnerability disclosure program. The report was redirected to their Intigriti bug bounty platform, sat idle for two weeks, and was then marked "out of scope." Rather than leave the exposure live, we registered dk-team.blue ourselves as a protective measure. The DMARC reports began arriving within hours.

This post is about a class of vulnerability that almost any organization can have — the unregistered RUA or RUF domain — and what to do about it.

The Pattern

A DMARC record looks like this:

v=DMARC1; p=reject; rua=mailto:reports@dmarc-vendor.example.com; ruf=mailto:forensics@example.com

The rua and ruf addresses are where the receiving mail server sends aggregate and forensic reports. Receivers don't validate that the address resolves or that the domain is owned by the sender. They just deliver mail there. If the domain doesn't exist, no mail flows. If the domain does exist — whether registered by the sender or anyone else — mail flows to whoever controls it.

The vulnerability class: a DMARC record with a reporting destination on a domain that the sender does not currently own. There are several common ways this happens.

Typos. A developer setting up DMARC misspells the intended destination. rua=mailto:dmarc@dmrcvendor.com instead of dmarc@dmarcvendor.com. The typo'd domain is unregistered. An attacker registers it. Reports flow.

Decommissioned vendors. An organization used DMARC monitoring vendor X, set the RUA to reports@x.com, then stopped paying for the service. The vendor account is closed, the DNS record stays, and at some point the vendor lets the actual domain expire — or the vendor goes out of business and the domain becomes available.

Internal naming conventions that never got registered. This was the team.blue case. The DMARC record references a domain that looks like it should exist internally, but never made it to the registration step. Common when DMARC is set up by one team and the related infrastructure is planned by another.

Forgotten subsidiaries and rebrands. A company acquires another company. The acquired entity's DMARC records point to the old parent's email domain. The old parent's domain gets shut down years later. The DMARC records still reference it.

Documentation copy-paste. We covered this in our writeup of the Cloudflare third-party-example.com finding. An admin copies an example DMARC record from documentation, replaces the parts that look obvious, and ships it. If the placeholder domain in the documentation was unregistered, the production record now sends reports there.

What's in a Report

The risk depends on what aggregate reports actually contain. The XML format is well-documented but worth being concrete about:

• The reporting organization (the receiver, e.g., Google, Microsoft, Yahoo)
• The reporting time window (typically 24 hours)
• The sender's published DMARC policy
• Each source IP that sent mail under your domain during the window
• The volume of messages from each source
• The disposition applied to those messages (delivered, quarantined, rejected)
• SPF result and the SPF-authenticated domain
• DKIM result and the DKIM-signing domain
• Alignment results
• The header-from domain on the messages

What an attacker learns from a few weeks of aggregate reports:

• Which ESPs and SaaS platforms send mail under your domain (and therefore which vendors are part of your stack)
• Which subdomains are actively used
• Sending volumes and patterns (week-over-week trends, peak hours, weekend behavior)
• Which mail streams are misconfigured (failing SPF or DKIM, often a tell for vendors mid-migration)
• Whether you're on Google Workspace or Microsoft 365 (the source IPs make this obvious)
• The relative weight of marketing vs. transactional vs. corporate mail in your traffic

None of this is the kind of breach that lands in headlines. It's reconnaissance. It's the kind of information that turns a generic phishing campaign into a targeted vendor-impersonation attack — "an email from your CRM provider asking you to confirm credentials" — that knows which CRM you actually use because the attacker has been reading your DMARC reports for two months.

What Happened After We Registered dk-team.blue

The reports started arriving within hours of the domain becoming active. Production mail flow data from a hosting provider subsidiary, delivered to an inbox controlled by us, with no notification to the original organization that anything had changed.

We reported the finding through team.blue's published Vulnerability Disclosure Policy. The response was to redirect us to their Intigriti bug bounty program. We re-submitted. The report sat in Intigriti's queue for two weeks before being marked "out of scope."

Then we published the research on LinkedIn. The response from team.blue's Group CISO, Jakob Flink Schwartz, was direct:

"Alex Shakhov — First off, thank you for reporting this and secondly sorry for the poor communications. It is no excuse, but we receive many spurious submissions reports about DMARC policy settings such as p=none etc, which are out of scope. Unfortunately, your initial report was mistakenly categorized among those and therefore not handled as it should have been. When the right team was notified of your LinkedIn post the issue was corrected shortly after."

This is candid and we appreciated it. It also illustrates a structural issue with how bug bounty programs handle this vulnerability class. Bug bounty triagers see "DMARC issue" reports constantly, and most are not real findings — they're scanner-generated alerts about p=none policies, which are not vulnerabilities. The signal-to-noise ratio is low. When a real finding (an unregistered RUA domain) arrives, it gets bucketed with the noise.

The cost of that miscategorization, when the vulnerability is exploitable, is that an attacker gets there first. We chose to register the domain rather than wait through the disclosure process precisely because the window between disclosure and remediation is the window during which the attack works.

How to Check Your Own Records

The check takes a few minutes. Pull every DMARC record across every domain you operate:

dig TXT _dmarc.example.com

For each record, extract the rua and ruf email addresses. For each address, separate the domain part. For each domain, verify:

1. The domain is currently registered. A whois lookup will show registration status. If the query returns "not found," the domain is available — and your reports are flowing to whoever happens to register it next.
2. The domain is registered to your organization or to a DMARC monitoring vendor you currently use and pay for.
3. The MX record on the domain points to infrastructure you trust — your own mail platform, or your vendor's.

For organizations with many domains, this is a scripted job, not a manual one. We typically do it as part of every audit. We've found unregistered RUA domains often enough that it's now a required check on every initial engagement, not a special-case investigation.

If you do find an unregistered RUA domain, the immediate action is to either register it yourself or update your DMARC record to point to a destination you control. The longer it sits, the more time someone has to discover it.

The Receiver Side: Why This Won't Be Fixed Upstream

A reasonable question is why DMARC receivers don't validate the RUA destination. The answer is in RFC 7489, which defines the protocol: receivers are explicitly not required to validate that the sender owns the reporting domain. If the address is syntactically valid, the receiver delivers the report.

There's a partial mitigation in the spec — if the reporting domain is different from the policy domain, the reporting domain has to publish a special DMARC record (<policy-domain>._report._dmarc.<reporting-domain>) confirming it's willing to receive reports on the policy domain's behalf. In practice, most receivers don't enforce this consistently, and most senders don't know it exists. The check would catch attackers who register a domain to receive someone else's reports without their consent, but it doesn't catch the case where the original sender's domain expires and a third party legitimately registers it later.

The fix has to be on the sender side: know what's in your DMARC records, verify the destinations are domains you control, and audit periodically.

A Broader Pattern

Unregistered RUA domains belong to a larger class of DNS-hygiene issues we encounter across audits: artifacts of past configurations that are still alive in DNS but disconnected from the controls that should govern them.

• Stale DKIM selectors for vendors no longer in use
• CNAME records pointing to deprovisioned cloud resources (the basis for subdomain takeover attacks, which we covered in our writeup of the Hazy Hawk university campaign)
• SPF includes for ESPs decommissioned years ago
• DMARC RUA destinations on domains that don't exist
• Verification TXT records that served their purpose and were never cleaned up

Each one, individually, is mundane. Collectively, they're a security posture made of forgotten decisions. DMARC enforcement at p=reject is the entry point to email security — the prerequisite. DNS hygiene is what actually keeps the protection meaningful over time.

If your organization has had DMARC published for more than two years and nobody has run a full RUA audit recently, the probability that you have at least one record pointing to a destination you no longer control is not negligible. The fix is fast. The exposure, if left alone, isn't.

---

Written by the team at SH Consulting. If you want a full DNS hygiene audit across your domains, including DMARC reporting destinations, stale DKIM selectors, and dangling references that have outlived their purpose, book a call.