Documentation is infrastructure for the people who read it. When the example contains a registerable domain, a predictable fraction of readers will deploy it to production.
We registered third-party-example.com — a domain that had never been registered by anyone, and that appeared in Cloudflare's DMARC documentation as the example reporting address in a DMARC TXT record. Within days, real DMARC aggregate reports started arriving from production domains. The count is currently at twenty-two organizations and growing, and that's only the senders we've confirmed.
The first version of this story, published on LinkedIn, framed it as a Cloudflare documentation defect. That framing was incomplete. The same unreserved placeholder appears in at least eight distinct documentation sources across multiple languages, propagated through the technical-content ecosystem in a way that looks more like a software supply chain than like an isolated mistake. Cloudflare has since updated their documentation. The third-party sites that copied the example haven't. And neither action removes the production DNS records that twenty-two organizations have already deployed.
This is a story about a class of exposure that the industry doesn't currently treat as a class of exposure: misconfigurations sourced from documentation, propagated by copy-paste, and operating silently in production for years.
What's Actually Happening
DMARC is the protocol that tells receiving mail servers what to do with email that fails authentication. Part of the configuration is a rua= tag — an email address where receiving servers send daily aggregate reports about every mail stream that asserts your domain. Those reports are XML files that list each sending source's IP address, message volume, SPF and DKIM authentication results with alignment, and the disposition the receiver applied.
A single day's reports from a single major provider can describe hundreds of distinct sending sources. Across weeks and providers, the cumulative picture is a near-complete inventory of an organization's email infrastructure: which transactional email vendor sends their invoices, which marketing automation platform handles their newsletters, which IP ranges their backup mail servers live in, whether they're being actively spoofed, and from which networks at what volume.
<?xml version="1.0"?>
<feedback xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<version>1.0</version>
<report_metadata>
<org_name>Enterprise Outlook</org_name>
<email>dmarcreport@microsoft.com</email>
<report_id>[REDACTED]</report_id>
<date_range>
<begin>1776124800</begin>
<end>1776211200</end>
</date_range>
</report_metadata>
<policy_published>
<domain>[REDACTED]</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>quarantine</sp>
<pct>100</pct>
<fo>0</fo>
</policy_published>
<record>
<row>
<source_ip>2a01:111:f403:c202::7</source_ip>
<count>4</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_to>[REDACTED]</envelope_to>
<envelope_from>[REDACTED]</envelope_from>
<header_from>[REDACTED]</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>[REDACTED]</domain>
<selector>selector1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>[REDACTED]</domain>
<scope>mfrom</scope>
<result>pass</result>
</spf>
</auth_results>
</record>Cloudflare's DMARC documentation, until recently, instructed administrators to configure that rua= address as example@third-party-example.com. The first half — example.com — is an IANA-reserved domain that can never be registered by anyone. The second half — third-party-example.com — is a perfectly normal, publicly registerable .com domain. Until we registered it, no one had.
Twenty-two organizations had copied that exact example into their production DNS without substituting the placeholder. Their daily DMARC reports — sending IPs, vendor inventories, authentication failure patterns, spoofing volumes — have been arriving in our inbox ever since. None of those organizations had any idea. Most still don't.
What the Reports Reveal
To be concrete about why this matters, here's what we've actually been receiving.
The reports come from Google, Microsoft, Yahoo, and other major receivers — the same providers that send legitimate DMARC reports to legitimate reporting endpoints worldwide. For each affected organization, we now have a daily-updated map of their email-sending infrastructure: which ESPs they use, the source IP ranges they send from, the percentage of their traffic that fails authentication, the volume of unauthorized senders attempting to spoof their domain, and the geographic distribution of those attempts.
This isn't sensitive in the same way that, say, a leaked database dump is sensitive. None of it constitutes a breach in the legal sense. But it's exactly the kind of operational metadata that an attacker planning a targeted phishing campaign wants. Knowing that a company sends invoices through Mandrill, marketing through HubSpot, and transactional traffic through SparkPost — with specific authentication patterns on each — turns a generic phishing template into a credible forgery. The reconnaissance phase of a targeted attack, normally requiring patience and indirect signal collection, becomes a daily inbox feed.
The DMARC specification's privacy considerations explicitly acknowledge this. Aggregate reports are intended for the domain owner or an authorized delegate. When the rua= address points to a domain the intended recipient does not actually control, that authorization is silently inverted, and the reports flow to whoever happens to be answering mail at that domain.
It Was Never Just Cloudflare
The Cloudflare documentation page is where we found the example, and it's by far the most-trafficked source. But the same string — third-party-example.com — appears across the technical-documentation web in a way that suggests this isn't a single editorial mistake. It's been copied, mirrored, translated, and re-presented as instructional content by a long tail of secondary sources.
We've identified the same exposed example in at least eight distinct documentation properties. CloudMySite's DNS documentation reproduces it verbatim. PostmanSMTP's tutorial on DMARC, SPF, and DKIM uses it as the canonical example DMARC record. DeBounce's blog on email authentication includes it. NE1 Web Design's explainer on DMARC records does too. Andrew Baker's personal technical blog at andrewbaker.ninja carries the same string. Long-form LinkedIn articles have reproduced the example. A Chinese-language tutorial on cnblogs.com carries it as well, as does a related explainer on Zhihu, China's largest Q&A platform. The actual count is almost certainly higher than what we've manually verified.
Four examples, ranging from formal hosting documentation to a Chinese-language Q&A platform:
Cloudflare's own documentation existed in this same state across multiple language editions for years. To Cloudflare's credit, every locale has now been updated — the English, Polish, Italian, and other localized versions all reference IANA-reserved space. The defect is closed at the source. The third-party sites listed above have not been updated.
This is the part that turns a documentation defect into something more like a supply-chain problem. The original Cloudflare page has been live since at least October 2021, based on Wayback Machine archives.
Over the four years that followed, the example propagated outward — into tutorial sites, personal blogs, translated guides, and Q&A platforms. Each of those secondary sources became its own distribution point. Each one, today, is still teaching readers to deploy a record that points at a domain we control. Even with Cloudflare's source page corrected, the downstream copies will continue to teach the original mistake until each is independently updated.
And the production DNS records already deployed to twenty-two organizations don't change at all. Documentation fixes never reach back into the configurations that were copied from earlier versions of the documentation. The only thing that updates a DNS record is the domain owner updating it.
Cloudflare updated all localized versions of their documentation to use IANA-reserved domains after we published our initial findings.
The Pattern Is Older Than This Finding
This is not the first time documentation-sourced misconfigurations have caused real-world exposure, and the previous examples form a pretty clear pattern.
In early 2020, the security researcher Terence Eden noticed that Google's G Suite documentation had for years referenced an example domain — spottedfig.org — that Google itself had forgotten to renew. 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 their English-language documentation to use a different placeholder: solarmora.com, a .com domain Google registered and controls but that, crucially, is not IANA-reserved either.
Four years later, in May 2024, the deliverability researcher Al Iverson scanned for solarmora.com in DMARC configurations across the public internet. He found it appearing in the DMARC records of more than three hundred production domains. Three hundred administrators had copied the example DMARC record directly out of Google's documentation into their DNS zones without substituting the domain. Most of them presumably still don't know they did this.
The same anti-pattern shows up in security research more broadly. Researchers have registered not-a-phish.com (a domain referenced in Evilginx installation guides), exampledomain.nl (used in Dutch-language technical content), and various other unreserved placeholders pulled from various technical guides. The vendor rotates. The behavior — administrators copying examples verbatim into production — is constant.
Every one of these incidents had a different root cause and a different remediation path, but they all share a shape. Documentation, in 2026, is infrastructure for the people who read it. The audience for technical guides isn't a small population of specialists who substitute placeholders by reflex. It's a much larger and growing population that includes founders, IT generalists, marketing operators, and the small-business owners who got a Google bulk-sender enforcement email in February 2024 and Googled "how to add DMARC record." That audience pattern-matches on the shape of the example, not on the semantics. When the example contains a registerable domain, a measurable percentage of those readers will deploy it to production unchanged.
Why IANA-Reserved Domains Exist
RFC 2606, published in 1999, reserves the second-level domains example.com, example.net, and example.org — along with the top-level domains .test, .example, .invalid, and .localhost — for exactly this purpose. The RFC's security considerations section is unusually direct: it warns that examples used "only in documentation" can end up being coded and released, and that the reservation of these domains is meant to minimize the resulting exposure.
The entire reason example.com exists is to absorb the failure mode this incident represents. Someone, somewhere, will paste a configuration example into production without substituting the placeholder. That's not a hypothetical — it's a base rate, and it has been measured repeatedly. If the placeholder is example.com, the paste is harmless: the domain belongs to IANA, will never accept mail, and cannot be acquired by an adversary. If the placeholder is a .com domain in public registration space, the same paste becomes a data-disclosure vector whose exploitation cost is the price of a domain registration.
Every documentation author publishing DMARC examples has access to safe placeholders that fail closed under the copy-paste failure mode. third-party-example@example.com keeps the recipient inside reserved space. third-party.example leverages the reserved .example TLD. Any number of unambiguously reserved constructions are available. Choosing a registerable .com instead is a control failure, and it's a control failure that has been made by Cloudflare and a long tail of secondary sources — CloudMySite, PostmanSMTP, DeBounce, NE1 Web Design, andrewbaker.ninja, long-form LinkedIn articles, a cnblogs.com tutorial, and a Zhihu explainer, among others — most of whom were probably copying from each other rather than arriving at the same bad choice independently. Cloudflare has corrected the source. The downstream copies remain.
The Argument That This Is Admin Error
The pushback to our original post is worth engaging directly because it's wrong in an instructive way.
The argument runs: the domain literally contains the word "example" in its hostname. Any competent administrator looking at the example DMARC record would understand it's a placeholder to be replaced. 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. 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 underwent a phase shift in February 2024 when Google and Yahoo announced that bulk senders 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 around the same time. The audience for DMARC documentation expanded by orders of magnitude in eighteen months — from "mail administrators at organizations with mature email programs" to "every small business with a mailing list, every SaaS founder sending onboarding emails, every IT generalist who got handed the ticket."
A predictable fraction of that expanded audience is not a DNS specialist. They are a person who received an enforcement notice, 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. 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 whole point 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.
The original Cloudflare documentation, and every site that copied from it, did not fail closed. Twenty-two production deployments measured to date — and counting — is what failing open looks like.
What To Check On Your Own Domain
The most useful thing a reader can do right now is spend two minutes verifying that their own organization isn't 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 will be 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 an actual contractual relationship with, the configuration is working as intended. If it points to third-party-example.com, solarmora.com, spottedfig.org, or any other unreserved placeholder, change the record before you investigate how it got there. If it contains the word "example" in any form other than @example.com, @example.net, or @example.org, treat it as suspect and verify.
Extend the check to every domain your organization owns. Parked domains, defensive registrations, acquired brands, and subsidiary domains all tend to inherit DMARC templates from the same source, which means a configuration defect on one is typically present on many. The domains least likely to have ever been reviewed are the ones most likely to be quietly leaking.
The same anti-pattern appears beyond DMARC. TLS reporting records (_smtp._tls) and MTA-STS policies both reference external email endpoints, and both are vulnerable to the same documentation-sourced misconfiguration. Any DNS record that publishes an email address to an external party is a candidate for the same mistake.
Documentation Is Infrastructure
The broader argument here is that technical documentation, for configuration-heavy protocols like DMARC, is not separate from the security of those protocols. It's part of the security of those protocols. A DMARC deployment using sound cryptography, correctly aligned signing keys, and a strict policy can still leak infrastructure metadata for years through a rua= endpoint copied from a docs page nobody on the team has looked at since deployment.
The remediation isn't complex. Standards exist. Reserved domains exist. The .example TLD exists. Every technical writer publishing a DMARC example has access to safe placeholders that fail closed. Using them is a matter of convention, and the convention is straightforward enough that violating it doesn't have a defense.
The harder remediation is in how the industry treats documentation as a security surface in the first place. Most major vendors' bug bounty programs explicitly classify documentation issues as out of scope. That made sense when documentation was decorative. It makes less sense when, for a measurable percentage of readers, the example in the documentation is the production configuration. A defect in a widely-indexed docs page that produces twenty-two confirmed production exposures is not categorically different from a defect in code that produces the same outcome — except in how it gets classified, who reports it, and how quickly it gets fixed.
Twenty-two organizations isn't a catastrophe. It's a measurement. It tells you the rate at which a specific documented configuration is being deployed without substitution, sourced from at least eight distinct documentation properties, into production DNS. The measurement would be similar — likely larger — for the next instance of the same pattern that nobody has 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.
