When DMARC Documentation Becomes a Vulnerability: The Cloudflare third-party-example.com Finding

In late 2025, while working on a routine deliverability audit, we noticed something odd in a client's DMARC record: rua=mailto:example@third-party-example.com. The pattern looked too specific to be invented — and a quick search showed why. Cloudflare's official DMARC setup documentation, in English, Italian, Chinese, Spanish, and German, used third-party-example.com as the placeholder for "where to send your DMARC aggregate reports."

The problem: third-party-example.com had never been registered. Anyone could buy it for the cost of a domain registration and immediately start receiving aggregate reports from organizations that copy-pasted the example into their DNS.

So we did.

Within days, the inbox was receiving real DMARC aggregate reports from real organizations — containing source IPs, sending volumes, header-from domains, and authentication results for production mail streams. We confirmed at least 18 unique organizations were actively sending reports to a domain controlled by us, not Cloudflare. Macit Tuna, CEO of Deepinfo, ran a search across their 400M+ domain dataset and found 10 domains with third-party-example.com in their DMARC records — confirming the long tail. For comparison, the IANA-reserved example.com appears in DMARC records of around 2,000 domains. Bad copy-paste hygiene, but at least example.com is reserved and cannot be registered by an attacker.

This post is about the broader lesson: documentation choices are security controls. When a security vendor publishes example DNS records, the choice of domain in those examples is not a stylistic decision. It's an attack surface.

What an Aggregate Report Actually Contains

To understand why this matters, it helps to be specific about what a DMARC aggregate report contains. The XML format includes the source IP of every server sending mail under your domain, the volume of messages from each source, the disposition (delivered, quarantined, rejected), SPF and DKIM authentication results with the signing domain visible, alignment results, and the policy that was applied.

For an attacker, this is reconnaissance gold. A few weeks of aggregate reports tells you which ESPs an organization uses, which IP ranges send their transactional mail, which internal subdomains are active, and which mail streams are misconfigured enough to fail authentication today. It tells you who their CRM provider is, what marketing automation they run, and whether their corporate mail is on Google Workspace or Microsoft 365. None of that information is individually catastrophic. Together, it's a roadmap for targeted phishing or vendor impersonation.

The organizations sending us these reports had no idea. There's no notification when a DMARC RUA address starts receiving mail from a new domain. There's no log entry. The DNS record they configured years ago kept working, the reports kept flowing, and the only thing that changed was who was on the receiving end.

The Defense That Documentation Makes

The most interesting reaction to our published research came from Dain Perkins at Snyk, who pushed back in the LinkedIn thread:

"The second domain is LITERALLY third-party-EXAMPLE.com, how can anyone not realize that it's an EXAMPLE? Effectively some number of individuals who were implementing something they likely didn't really understand, copied the EXAMPLE DMARC policy DIRECTLY from the docs, implemented it in production, no one caught the glaringly obvious mistake, and now it's Cloudflare's fault?"

It's a reasonable position. Admins who copy-paste DNS records without understanding them shouldn't be administering DNS. But "the admin should have known better" isn't a security stance — it's an abdication. Every misconfiguration in production is, in some sense, an admin's fault. That doesn't make the upstream documentation choice neutral.

Linus Å. captured the technical argument better in the same thread: RFC 2606 reserves four TLDs — .test, .example, .invalid, and .localhost — and three second-level domains — example.com, example.net, and example.org — precisely so technical documentation can use them without creating exploitable artifacts. If Cloudflare needed to differentiate between the primary domain and a "third-party" reporting endpoint in their examples, the reserved options were example.net, third-party.example, or third-party-example.test. None of those can be registered. None create exposure.

Using a .com outside the reserved set for an example introduces avoidable risk. That's true regardless of how many admins should-have-known-better.

Why Copy-Paste Is the Default

The "they should have known better" argument also assumes admins approach DMARC as a security topic. Most don't. DMARC entered the average admin's awareness because Google and Yahoo's February 2024 sender requirements demanded a published DMARC record for bulk senders. Suddenly, marketing teams were asking IT to "just add a DMARC record" so HubSpot or Mailchimp would keep working. The IT person Googled "how to add DMARC Cloudflare," found the official documentation, copied the example, replaced the parts that looked obvious, and moved on.

The parts that looked obvious got replaced. The parts that didn't — like an unfamiliar third-party reporting domain that sounded like vendor infrastructure — didn't. That's not stupidity. That's the predictable behavior of someone solving a checkbox compliance problem, not a security problem.

Documentation that anticipates this behavior is harder to misuse. Documentation that doesn't, ships exposures at scale.

The Disclosure Loop

We initially considered reporting the finding to Cloudflare through their HackerOne program. The program explicitly classifies documentation issues as out of scope, so the formal disclosure route was closed before it started. We published the research on LinkedIn instead. The English-language documentation pages were updated to use example.com within days. Some non-English versions retained the original third-party-example.com reference for longer.

This is a recurring pattern in our disclosure work. Vendor bug bounty programs are designed to catch software vulnerabilities, not configuration patterns, documentation defects, or systemic issues that span multiple products. When a finding falls outside that scope — even when it materially impacts customer security — the path to remediation is often public disclosure rather than coordinated fix.

We registered third-party-example.com as a protective measure. Holding the domain prevents any other party from registering it and harvesting the reports. The reports we now receive are still flowing in months later, which means there are organizations out there that have not updated their DMARC records — and won't, until someone audits their DNS and notices.

The General Principle

If you publish technical documentation that includes DNS records, hostnames, email addresses, or any other globally-resolvable identifier, treat the choice of placeholder as a security decision. The rules are simple:

For domains: use example.com, example.net, or example.org — these are IANA-reserved and cannot be registered. For multi-domain examples, use subdomains under the reserved set: tenant.example.com, vendor.example.net. Or use a reserved TLD: myapp.test, internal.invalid.

For email addresses: build them from reserved domains. admin@example.com cannot be registered as a working address by anyone. admin@third-party-example.com could.

For internal hostnames: use .invalid or .localhost to make it explicit that the names cannot resolve publicly.

This isn't pedantry. It's the same principle as parameterized queries in SQL — make the unsafe path harder than the safe path. Every documentation snippet you publish will be copy-pasted by someone who doesn't fully understand what they're copying. Your only control is making sure the copy-paste, even when uncomprehending, doesn't create an exposure.

What to Check in Your Own DMARC Records

Pull your DMARC record:

dig TXT _dmarc.example.com

Look at the rua and ruf addresses. Are they pointing to mailboxes you control on domains you own? Are they pointing to a DMARC monitoring service (URIports, dmarcian, EasyDMARC, Valimail, Red Sift) you actively use? Anything else — placeholder text, an old vendor you no longer pay, a domain you don't recognize — is a problem.

If you see third-party-example.com, your reports have been flowing to us for some time. We're not doing anything with them. But the principle should worry you: the only thing standing between your DMARC reports and an unknown party was who happened to register the example domain first.

---

Written by the team at SH Consulting, an email deliverability and security consultancy. If you want a full audit of where your DMARC reports are actually going and what they're exposing, book a call.