Technical documentation assumes a sophisticated reader who replaces placeholders with real values. Years of evidence suggest that a predictable percentage of readers do not.
Cloudflare's DMARC documentation, in its original form, instructed administrators to configure their DMARC record to send aggregate reports to example@third-party-example.com. The first half of that address — example.com — is an IANA-reserved domain that can never be registered by anyone. The second half — third-party-example.com — is a normal, publicly available .com domain. Until recently, it had never been registered by anyone. We registered it.
Within weeks, eighteen unique organizations were sending us real DMARC aggregate reports for their production domains. Not examples. Not tests. Real operational data: sending IP addresses, third-party email vendors, authentication failure rates, volume statistics. The kind of infrastructure reconnaissance a threat actor would otherwise have to work for.
This is a story about a defect in documentation. It is also a story about a behavior that security engineering has understood for decades: a predictable fraction of administrators will copy a configuration example into production without substitution, and documentation that relies on "they should know better" to prevent data exposure is not designed for the environment it operates in.
What a DMARC Aggregate Report Actually Contains
To understand why this matters, it helps to be clear about what's in the envelopes that were arriving in the inbox of the domain we registered.
A DMARC aggregate report, sent by receiving mail servers like Gmail, Microsoft, and Yahoo to the address specified in the rua= tag of a domain's DMARC record, is an XML document that describes every mail stream that asserted the reporting domain in its From header during a 24-hour window. For each sending source, the report lists the source IP address, the volume of messages, the SPF and DKIM authentication results with alignment, and the disposition the receiving server applied. One report from a single provider for a single day can contain hundreds of distinct sources across legitimate vendors, third-party integrations, and unauthorized senders.
Laid end to end across weeks and providers, these reports are a near-complete inventory of an organization's email infrastructure. Which transactional email provider they use. Which marketing automation platform. Which CRM. Which country their backup mail server is in. Whether a specific subsidiary has been spun up recently, judging by new IP ranges appearing in reports. Whether they're being actively spoofed, and from where, and at what volume.
This is not inherently sensitive information in the same way a password is — none of it, taken alone, constitutes a breach. But it is exactly the kind of operational metadata that an attacker planning a targeted phishing campaign would want before they started. Knowing which vendor sends a company's invoices, on which IP range, with what authentication posture, changes the plausibility of a forged invoice email from "maybe" to "convincing." It is the reconnaissance phase of an attack compressed into a daily inbox feed.
The DMARC specification's own privacy considerations acknowledge this. Aggregate reports contain operational metadata that domain owners expect to send only to parties they have explicitly authorized. When the rua= address in a DMARC record points to a domain the intended recipient does not actually control, that expectation is quietly inverted.
Why example.com Exists in the First Place
RFC 2606, published in June 1999, is a short document with a specific purpose. It reserves four top-level domains — .test, .example, .invalid, and .localhost — and three second-level domains — example.com, example.net, and example.org — for use in documentation, testing, and the construction of names that must be unambiguously non-operational. The security considerations section of that RFC is unusually blunt. It states that even examples used only in documentation can end up being coded and released, or cause conflicts due to later real use and the possible acquisition of intellectual property rights in such example names. The reservation of these domains, the RFC argues, minimizes that confusion and conflict.
The entire reason example.com exists is to absorb exactly the failure mode this incident represents. Someone, somewhere, is going to paste a configuration example into production without substituting the placeholder. If the placeholder is example.com, the paste is harmless — the domain belongs to IANA, will never route mail, and cannot be acquired by an adversary. If the placeholder is a .com domain that sits in public registration space, the paste becomes a data-disclosure vector whose exploitation cost is the price of domain registration.
Cloudflare's documentation team had every standard-body sanctioned option available. They could have used third-party-example@example.com and kept the recipient inside reserved space. They could have used third-party.example, leveraging the reserved .example TLD. They could have constructed any number of unambiguously reserved names. Instead, they picked third-party-example.com — a plausible-looking, unreserved, publicly registerable domain — and published it in documentation that, based on the Wayback Machine, has been live since at least October 2021.
The Pattern Is Older Than This Finding
The instinct, reading this far, may be to treat Cloudflare as an outlier. It is not.
In early 2020, the security researcher Terence Eden noticed that Google's G Suite documentation had for years referenced the example domain spottedfig.org. He also noticed that Google had forgotten to renew it. He bought it, for roughly ten pounds, and briefly owned the domain that Google's official setup guides instructed new administrators to query. Google subsequently updated its English-language documentation to use a different placeholder: solarmora.com.
solarmora.com is not IANA-reserved either. It's a .com domain Google registered and controls. Which means the anti-pattern survived the fix — a private .com held by the vendor rather than a reserved name in standards-compliant space. Four years later, in May 2024, the deliverability researcher Al Iverson ran a scan and found solarmora.com appearing in the DMARC configuration of more than three hundred production domains. Three hundred administrators had copy-pasted an example DMARC record directly from Google's documentation into their DNS zone without substituting the domain. Most of them presumably still do not know they did this.
This pattern has a long tail. One commenter on our original post mentioned buying exampledomain.nl — a placeholder used somewhere in Dutch-language technical guidance — and finding traffic. Another mentioned buying not-a-phish.com, a domain referenced in the installation instructions for the Evilginx community edition. A third recalled, almost fondly, registering a domain from a printed Microsoft Exchange courseware book in 1998 and watching email for a production audience drift in for three decades. The specific vendor rotates. The behavior does not.
A database search by Deepinfo across roughly four hundred million domains found ten domains currently publishing DMARC records containing third-party-example.com. For comparison, the same database found approximately two thousand domains with some form of example.com in their DMARC records — the safe version, landing in IANA-reserved space where no one can listen. The ratio tells you something. A meaningful number of administrators will paste example DMARC records verbatim. Most of the time that behavior is harmless because the placeholder is reserved. When the placeholder isn't reserved, the same behavior becomes an exposure.
The Argument That This Is Admin Error
The pushback to our original post was predictable, and worth engaging seriously because it's wrong in an instructive way.
The argument runs: the domain third-party-example.com contains the literal word "example" in its hostname. Any competent administrator looking at the example DMARC record would understand it is a placeholder to be replaced with their own DMARC reporting endpoint. Administrators who copy configuration examples verbatim into production without understanding them shouldn't be administering DNS in the first place. The responsibility rests with the admin, not the docs.
Parts of this are true. Administrators who paste records they don't understand are making a mistake. Copy-paste without substitution is a failure of professional judgment. In a world with infinite time and flawless training, it would not happen.
The world does not have those properties. DMARC deployment, specifically, underwent a phase shift in February 2024 when Google and Yahoo announced that domains sending more than five thousand messages per day to their users would need to publish DMARC records or face delivery consequences. Microsoft followed with similar requirements in May 2025. PCI DSS v4.0 added DMARC to its scope in March 2025. The audience for DMARC documentation stopped being "mail administrators at organizations with mature email programs" and became "every small business with a mailing list, every SaaS founder sending onboarding emails, every nonprofit with a newsletter, and the IT generalist who got handed the ticket." The population grew by orders of magnitude in eighteen months. The documentation did not.
A predictable fraction of that expanded population is not a DNS specialist. They are a person who received a Google enforcement email, searched for "how to add a DMARC record," landed on the first result, and configured what the example showed them. For that person, "it literally says example in the hostname" is not a reliable control. The word "example" appears in a technical specification they do not fully understand, inside a string of syntax that is itself largely opaque. They are pattern-matching the shape of the record, not parsing its semantics.
Security engineering has a long-settled name for this dynamic: a control that depends on the user noticing something is a control that fails at predictable rates. The entire purpose of reserved example domains is that they let documentation be robust to that failure mode. Administrators still shouldn't copy-paste examples verbatim. When they do anyway, the system should fail closed.
Cloudflare's original documentation did not fail closed. That is the finding.
What Cloudflare Changed, and What They Didn't
In the weeks after our post, Cloudflare updated the English-language version of their learning-center page on DMARC records. The example now reads rua=mailto:third-party-example@example.com instead of rua=mailto:example@third-party-example.com. It is a one-character rearrangement — swapping the local-part and the domain around the @ — and it moves the recipient into IANA-reserved space.
%20(1).png)
This is the right fix. The new construction is safe even against the copy-paste failure mode. An administrator who pastes this example into their DMARC record verbatim, without substitution, has now configured their domain to send DMARC reports to a mailbox at example.com. Those reports will fail to deliver because example.com does not accept mail. No data leaks to a third party. The worst case becomes administrative inconvenience rather than information disclosure. That is what good documentation looks like.
It is also, as of this writing, an incomplete fix. Cloudflare's learning-center articles are translated into multiple languages, and the non-English versions have not all been updated. The British English page, at the time we last checked, continued to show the original example@third-party-example.com construction. Italian, German, Spanish, and Chinese versions, based on the indexed search results that prompted our original investigation, are in various states. Each one of those pages is a separate distribution channel for the original unreserved placeholder. An Italian-speaking administrator configuring DMARC from Cloudflare's Italian documentation is reading a version of the page that still teaches the exposure.
The fact that the fix was made in English first is not surprising. The documentation team presumably updates the primary-locale version before the translation pipeline catches up. The problem is that the original documentation has been live in multiple languages since at least 2021 — more than four years of indexed, pasteable examples — and the remediation has been piecemeal. From a security-engineering standpoint, the defect was introduced simultaneously across locales and should be fixed simultaneously across locales. Anything short of that leaves non-English administrators with a more dangerous version of the same page.
The Out-of-Scope Problem
Before we registered third-party-example.com, we considered reporting the issue through Cloudflare's vulnerability disclosure program on HackerOne. The program's scope explicitly excludes documentation issues, informational pages, and marketing content. This is typical. Most major vendors' bug bounty programs treat the documentation site as separate from the product, reportable only through standard support channels, and not eligible for coordinated disclosure.
The framing is defensible in the general case — a typo in a blog post is not a vulnerability. It becomes harder to defend when the documentation in question is operational guidance that administrators translate directly into production DNS configuration, and when the defect in that guidance creates a measurable exposure at scale. A .com domain hardcoded in a page that has been indexed in every major search engine for four years is not documentation in the decorative sense. It is, for a nontrivial fraction of readers, the production configuration itself.
The gap between "documentation is not security" and "documentation is where a meaningful percentage of production configurations come from" is the gap this finding lives in. It is an industry-wide gap, not a Cloudflare-specific one, and it is the reason the pattern keeps recurring.
What to Check on Your Own Domain
The most useful thing a reader of this post can do is spend two minutes verifying that their own organization is not currently publishing a DMARC record that points to an unreserved example domain. The check is a single DNS query.
On any modern operating system, run:
dig +short TXT _dmarc.example.com
Substitute your own domain for example.com. The output is the TXT record containing your DMARC policy. Read the values after any rua=mailto: and ruf=mailto: tags. The domain portion of those email addresses is where your DMARC reports are being sent.
If that domain is one you control, or belongs to a DMARC monitoring vendor you have a contractual relationship with, the configuration is working as intended. If it contains the string example in any form other than @example.com, @example.net, or @example.org, you have a problem, and the first remediation step is to change the record before investigating how it got there. If it points to any of the known example-domain artifacts discussed here — third-party-example.com, solarmora.com, spottedfig.org — change it immediately.
Extend the check to every domain your organization owns, not just your primary. Organizations that maintain dozens or hundreds of domains frequently apply identical DMARC templates across their portfolio, which means a configuration defect present on one domain is typically present on many. Parked domains, acquired domains, defensive registrations, and subsidiary brands are all candidates for the same misconfiguration, and they are the domains most likely to have been configured once and never reviewed.
Beyond DMARC, the principle generalizes. The rua and ruf tags on DMARC records are the most common vector for this pattern because DMARC is the most widely deployed reporting-oriented DNS configuration, but the same anti-pattern appears in TLS reporting records (_smtp._tls) and MTA-STS policies, both of which reference external reporting endpoints. Any DNS record that publishes an email address to an external domain is a candidate for the same mistake.
The Documentation Surface Is a Security Surface
The broader point is that technical documentation, for configuration-heavy protocols like DMARC, is not separate from the security of those protocols. It is part of the security of those protocols. A DMARC deployment that follows sound cryptographic practice, uses correctly aligned signing keys, and maintains strict policies can still leak infrastructure metadata through a reporting endpoint defined by a copy-pasted example.
This is an argument about where responsibility sits in a system designed for scale. DMARC is now a baseline requirement for commercial email. The pool of administrators deploying it includes millions of people whose professional focus is not email authentication. Documentation for a protocol with that audience needs to treat every example as code that will run in production, because for some meaningful fraction of readers, it will.
The remediation is not complex. Standards exist. Reserved domains exist. The .example TLD exists. Every technical writer publishing DMARC configuration examples has access to safe placeholders that fail closed under the copy-paste failure mode. Using them is not a matter of skill — it is a matter of convention, and the convention is straightforward enough that there is no reason to violate it.
The harder remediation is inside programs that classify documentation as out-of-scope for vulnerability disclosure. The categorical exclusion is an artifact of an earlier era when documentation was read by a narrower, more specialized audience. That era has ended. The audience for email-authentication documentation in 2026 is general, and the impact of a misconfigured placeholder in a widely-read docs page is, demonstrably, a measurable exposure across multiple production environments. A vulnerability disclosure program that has no channel for that kind of finding is a program that has a blind spot.
Eighteen organizations is not a catastrophe. It is, however, a measurement. It tells you the rate at which a specific documented configuration is being deployed without substitution, from a single docs page, across a four-year window, into production DNS. The measurement would be the same, or larger, for whichever similar finding is out there and hasn't been noticed yet.
At SH Consulting, we audit DMARC deployments against exactly these kinds of configuration drift and documentation-sourced exposures, along with the broader set of authentication, reporting, and reputation controls that determine whether an organization's email infrastructure is actually doing what it claims to be doing. If you'd like a second look at your setup, book a 30-minute call.
