Fact-checked by Grok 2 weeks ago

example.com

example.com is a reserved by the (IANA) for use in , examples, and testing within technical specifications and .
It was established through RFC 2606, published in June 1999 by the (IETF), which designates example.com, along with example.net and example.org, as second-level domains under the .com, .net, and .org top-level domains specifically for illustrative purposes to avoid conflicts with real-world registrations.
Unlike standard domains, example.com cannot be registered or used in production environments, ensuring it remains a neutral placeholder in protocols, APIs, and educational materials without risking unintended network interactions.
The domain points to a simple, IANA-maintained webpage displaying placeholder content to demonstrate basic HTTP functionality, further emphasizing its role in non-operational contexts.
This reservation helps standardize across the ecosystem, preventing the need for temporary or fictional domains that could cause or issues.

Purpose and Reservation

Illustrative Role

Example.com serves as a specifically designated for illustrative and educational purposes, allowing authors, educators, and technical writers to reference a hypothetical in documentation without suggesting that it points to an actual, accessible website. This usage prevents confusion among readers who might otherwise attempt to resolve or interact with the in real-world scenarios, ensuring that examples in , tutorials, and sample configurations remain purely demonstrative. The guidelines for employing example.com were formalized by the (IETF) in 2606, published in June 1999, which reserves it alongside other domains like example.net and example.org to facilitate clear, non-ambiguous references in technical specifications and standards documents. Building on this, 6761 from 2013 expands the rationale, emphasizing that such special-use domains like example.com should not be registered or used in production environments to avoid unintended network traffic or conflicts with legitimate registrations. These documents explicitly recommend example.com for scenarios involving (DNS) demonstrations, configurations, and protocol explanations, promoting consistency across technical literature. In practice, example.com plays a crucial role in mitigating potential disputes or legal ambiguities that could arise from using unregistered but realistic-sounding domains in hypothetical examples. For instance, in tutorials, referencing "api.example.com" as a mock avoids any implication of affiliation with a real company, while in legal or policy discussions, it illustrates domain squatting risks without referencing actual entities. This approach underscores the domain's value in fostering accurate, risk-free educational content within the broader framework of management overseen by the (IANA).

Reservation Mechanism

The reservation of example.com is governed by the policies outlined in the (IANA) guidelines for example domains, which designate it exclusively for use in and illustrative purposes. These guidelines, rooted in RFC 2606 and RFC 6761, explicitly prohibit the registration, transfer, or commercial use of example.com, ensuring it remains unavailable to the public to prevent conflicts in the (DNS). Actual DNS resolution for production applications is not supported, as the domain is not intended for operational services; any incidental traffic or basic web responses provided by IANA serve only informational purposes and should not be relied upon. Enforcement of this occurs through ICANN's oversight of IANA functions, with IANA as both the registrant and administrative for example.com in the database, thereby blocking any attempts at delegation or assignment to third parties. While the file primarily manages delegations, the policy-based of second-level domains like example.com is maintained within the broader .com hierarchy under ICANN's coordination, ensuring no authoritative name servers are delegated for it outside of IANA control. This structure upholds the domain's integrity without requiring technical blocks in the root zone itself. Legally, example.com's status under the DNS framework guarantees its perpetual availability for non-commercial, documentation-only use, as mandated by IETF standards to avoid domain squatting or unintended real-world resolutions that could disrupt internet stability. This reservation extends similarly to related domains such as example.org, which are subject to identical prohibitions and oversight.

Historical Development

Origins in Internet Protocols

The concept of example domains like example.com originated in the evolution of Internet addressing during the 1980s transition from to a broader /IP-based network, where early RFCs employed names to demonstrate hierarchical naming without risking real-world conflicts. As host tables grew unwieldy, documents introduced domain structures to organize addresses, using institutional or hypothetical labels as stand-ins for clarity in protocol explanations. For example, RFC 799 (1981) outlined domain naming for user applications, illustrating mail syntax with domains such as and to show hierarchical partitioning across networks like and . This approach addressed the limitations of flat naming in 's HOSTS.TXT file, promoting scalable addressing in emerging standards. Jon Postel, who informally established the (IANA) in the early 1970s and served as Editor from 1969 until 1998, significantly influenced the standardization of these placeholders in protocol documentation. Postel's oversight ensured that examples in RFCs consistently illustrated key mechanisms, such as in RFC 821 (1982), where he specified SMTP and used .ARPA domains like USC-ISIF. and ISI-VAXA. to depict mail transfer between hosts. Similarly, in DNS-defining RFC 1034 (1987), placeholders including VAXA.ISI.EDU and XX.LCS.MIT.EDU clarified name resolution and zone management, reflecting Postel's emphasis on practical, non-conflicting illustrations for protocols like SMTP and early hypertext transfer concepts. His role as IANA founder centralized these practices, fostering uniformity in Internet technical specifications. Before formal IANA policies solidified, pre-1992 technical papers and IETF drafts—starting with the IETF's formation in 1986—routinely incorporated such informal placeholders to denote hypothetical domains in network diagrams and protocol flows. These uses, often adapting real or names like those in RFC 882 (1983) for domain concepts, avoided ambiguity in discussions of mail routing and host addressing during ARPANET's phase-out. RFC 1591 (1994) built on this foundation by referencing example-like structures, such as .Armonk.NY., to exemplify delegation hierarchies in DNS administration.

Formal IANA Designation

The formal designation of example.com as a domain name was established by the (IANA) to provide a stable, non-conflicting identifier for use in technical documentation, software examples, and network testing scenarios. This status ensures that the domain cannot be registered or delegated to private entities, thereby avoiding real-world operational implications or issues in illustrative contexts. The reservation specifically targets second-level domains under established top-level domains like .com, .net, and .org, reflecting IANA's role in coordinating the global (DNS) namespace. A key milestone in this designation occurred with the publication of RFC 2606 in June 1999, which explicitly reserved example.com, example.net, and example.org for documentation purposes as a best current practice (BCP 32). Authored by Donald E. Eastlake 3rd and Aliza R. Panitz on behalf of the IETF DNSIND working group, the document aimed to standardize the use of these names to prevent confusion in private testing and public specifications, noting that IANA would maintain their non-delegated status. This formalization built on earlier informal practices in development, providing clear guidelines for their non-commercial application. Further evolution came in RFC 6761, published in January 2013, which expanded on special-use domain names and reaffirmed the reserved status of example.com within a broader for non-DNS-resolving . This update, prepared by the IETF's Applications Area , emphasized operational considerations, such as not attempting DNS queries for these domains in production environments, and reinforced IANA's oversight to ensure consistency across standards. IANA maintains ongoing responsibility for example.com, including blocking delegation to any registrar and integrating it into the root zone file as a special-purpose entry. Periodic policy reviews, coordinated through IETF processes and ICANN's oversight of IANA functions, confirm its relevance amid expanding DNS usage; as of 2025, no changes to its reserved designation have been implemented, preserving its utility for educational and developmental purposes.

Technical Specifications

Domain Hierarchy and Structure

The domain example.com occupies a position within the (DNS) as a second-level domain (SLD) labeled "example" beneath the (gTLD) ".com," forming the hierarchical structure example.com. This places it two levels below the DNS , where ".com" serves as the TLD managed within the global DNS namespace, and "example" functions as the SLD without further delegation to subdomains in production use. The syntactic composition adheres to standard DNS label rules, limiting the SLD to 63 characters of alphanumeric and hyphen characters, with no leading or trailing hyphens, ensuring compatibility with DNS protocol specifications. Despite its reserved status, example.com is delegated with A and AAAA records in the authoritative DNS zones, mapping to IPv4 (93.184.216.34) and (2606:2800:220:1:248:1893:25c8:1946) addresses maintained by IANA, allowing to a simple demonstration webpage for basic HTTP functionality. DNS queries for example.com return a NOERROR response code from the .com TLD's authoritative name servers, enabling this limited operational behavior while aligning with its documentation-only purpose and avoiding conflicts in the public DNS. Queries for non-existent subdomains under example.com elicit an NXDOMAIN response to prevent unintended production use. Similar reserved domains, such as , follow an analogous structure as an SLD "example" under the ".net" gTLD, sharing the same syntactic constraints and resolvable characteristics with A and AAAA records pointing to IANA's infrastructure. Both domains are exempt from standard registration processes and support consistent DNS handling for illustrative examples, with NOERROR responses for the apex domains and NXDOMAIN for subdomains. This uniformity across example.* variants under different gTLDs supports their role in technical documentation without introducing variability in query resolution mechanics.

Management by IANA

The (IANA), operated by Public Technical Identifiers (PTI) as an affiliate of the (ICANN), holds primary responsibility for maintaining the reserved status of example.com within the . This involves ensuring the domain's entry in the root zone database reflects its non-delegable nature, preventing public registration or transfer, and periodically updating associated registries to enforce policy-based reservations. As outlined in RFC 2606 and extended by RFC 6761, example.com is explicitly reserved as a under .com for use in , testing, and illustrative purposes, with IANA coordinating these allocations to avoid conflicts in the global DNS namespace. For handling queries and misuse reports related to example.com, IANA processes change requests to the root zone through established procedures, including of before any updates are propagated. Misuse, such as unauthorized attempts at registration or operational deployment, is addressed via ICANN's contractual mechanisms, where reports are investigated and mitigation actions—like blocking invalid delegations—are enforced in coordination with root server operators. These operators, numbering 13 independent entities, receive IANA-approved root zone updates via automated distribution systems to maintain consistent DNS responses, such as NOERROR for example.com and NXDOMAIN for its subdomains. The management of example.com has evolved from manual oversight by , who performed IANA functions including root zone maintenance from the 1970s until his death in 1998, to a formalized structure under following the 1998 transition agreement. This shift introduced automated systems for root zone changes and registry updates, enhancing efficiency and global coordination. As of November 2025, no substantive changes to this framework have occurred, preserving the domain's reserved status without alteration.

Usage and Impact

Applications in Documentation

The domain example.com is extensively utilized in technical documentation to provide illustrative examples without relying on real-world domains, thereby avoiding unintended dependencies or conflicts in specifications and tutorials. In (RFCs) published by the (IETF), it serves as a standard placeholder for demonstrating (DNS) configurations, email protocols, and network behaviors; for instance, RFC 7208 on (SPF) employs example.com to show valid and invalid email authentication scenarios. Similarly, API documentation often incorporates it to depict endpoint structures, such as in OpenAPI specifications where sample requests reference https://api.example.com/users for clarity. Programming tutorials frequently adopt example.com in code snippets, particularly for web technologies; the Mozilla Developer Network (MDN) documentation for anchor elements uses to illustrate implementation. Standards bodies leverage example.com to ensure specifications remain independent of proprietary or operational domains, fostering interoperability and ease of adoption. The (W3C) and its aligned HTML Living Standard recommend its use in examples to illustrate URI handling and form submissions, as seen in sections detailing link navigation and secure contexts. The reservation of example.com by the (IANA), as outlined in RFC 2606, underpins this consistent application across these contexts. Its prevalence in IETF documents alone—appearing in hundreds of —highlights its role in promoting uniformity and reducing errors in technical examples, with the explicitly endorsing https://example.com/ as the preferred format for illustrations. This widespread adoption enhances conceptual clarity in educational materials, such as CSS tutorials demonstrating domain-based selectors or JavaScript demos for fetch requests to hypothetical servers.

Common Misuses and Typosquatting

One common misuse of example.com arises from frequent typographical errors by users, particularly in technical documentation, configuration files, and manual entry, leading to misdirected DNS queries. For instance, "exmaple.com" is a prevalent misspelling where the letters "a" and "m" are transposed, resulting in unintentional traffic to unintended domains. , which owns exmaple.com as a "typo " to analyze such errors, reports that this traffic often stems from automated scripts, bots, or human input without autocorrect, highlighting how reserved domains like example.com can inadvertently draw erroneous requests in non-production environments. Typosquatting poses a security risk for domains resembling example.com, where malicious register slight variations—such as "examp1e.com" or "examplee.com"—to intercept users seeking the legitimate domain for documentation purposes. These rogue domains can host pages, malware, or redirect traffic to fraudulent sites, exploiting the domain's prominence in educational and illustrative contexts. Although example.com itself is protected from registration, variations remain available in the open market, enabling attackers to capitalize on common errors like character substitutions or omissions. The (IANA) and the (ICANN) address these issues through reservation policies and ongoing DNS monitoring, ensuring example.com cannot be registered for real-world use and reducing direct misuse potential. Per RFC 2606, this reservation minimizes conflicts and security confusion in testing or examples, with maintaining oversight to handle abuse reports related to the . As of 2025, no major incidents of specifically targeting example.com variations have been publicly reported, though general advisories emphasize vigilance against domain spoofing in applications.

References

  1. [1]
    IANA-managed Reserved Domains
    As described in RFC 2606 and RFC 6761, a number of domains such as example.com and example.org are maintained for documentation purposes. These domains may be ...Special-Use Domain Names · Delegation Record for .آزمایشی
  2. [2]
    RFC 2606: Reserved Top Level DNS Names
    Reserved Top Level DNS Names June 1999 example.com example.net example.org 4. IANA Considerations IANA has agreed to the four top level domain name ...RFC 1034: Domain names · RFC 1591: Domain Name... · RFC 6761 · RFC 1035
  3. [3]
    Example Domains
    May 13, 2017 · Example domains like example.com are for documentation, not for registration, and are not designed for production applications. They are not ...IANA-managed Reserved... · Contact Us · Performance · Archive
  4. [4]
    RFC 6761: Special-Use Domain Names
    ### Summary of RFC 6761: Special-Use Domain Names (Relevant to example.com Reservation and Special-Use Domains)
  5. [5]
    None
    ### Summary of RFC 799: Internet Name Domains
  6. [6]
    None
    Summary of each segment:
  7. [7]
    None
    Summary of each segment:
  8. [8]
    Jon Postel - Internet Hall of Fame
    Jon Postel was RFC Editor, shepherding drafts through the open consensus processes that characterize Internet development efforts.
  9. [9]
    RFC 1591: Domain Name System Structure and Delegation
    RFC 1591 Domain Name System Structure and Delegation March 1994 Each ... The country code domains (for example, FR, NL, KR, US) are each organized by ...
  10. [10]
    RFC 2606 - Reserved Top Level DNS Names - IETF Datatracker
    Dec 29, 2023 · A few top level domain names are reserved for use in private testing, as examples in documentation, and the like.
  11. [11]
    Root Servers - Internet Assigned Numbers Authority
    Root servers are authoritative name servers that serve the DNS root zone, a network of hundreds of servers in many countries.Missing: misuse reports
  12. [12]
    Submitting a Complaint to ICANN Contractual Compliance
    To submit a complaint, select the form next to the issue which best describes your concern in the chart below.
  13. [13]
    [PDF] SAC067 Overview and History of the IANA Functions - icann cdn
    Aug 15, 2014 · The IANA Functions were originally performed by Postel while he was a graduate student at UCLA; when he moved to USC/ISI after finishing his ...Missing: origins | Show results with:origins
  14. [14]
    [PDF] History of IANA - Internet Society
    Jan 6, 2017 · This document presents a timeline of the history of IANA, the Internet Assigned Numbers Authority, from its birth in 1972 to the end of 2016 ...
  15. [15]
    RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of ...
    1. Simple Examples These examples show various possible published records for example.com and which values of <ip> would cause check_host() to return "pass". · 2 ...
  16. [16]
    RFC Style Guide - IETF
    Apr 7, 2021 · <https://example.com/>¶. The use of HTTPS rather than HTTP is strongly encouraged.¶. 3.4. Capitalization. Capitalization must be consistent ...
  17. [17]
    Typo traps: analyzing traffic to exmaple.com (or is it example.com?)
    Sep 22, 2023 · example.com is a reserved domain name set by the Internet Assigned Numbers Authority (IANA), under the direction of the Internet Engineering ...
  18. [18]
    What is Typosquatting? – Definition and Explanation - Kaspersky
    For example, if the URL is usually example-onlineshop.com, typosquatters might add an extra hyphen to deceive users – e.g. example-online-shop.com. At a glance, ...
  19. [19]
    RFC 2606 - Reserved Top Level DNS Names - IETF Datatracker
    RFC 2606 reserves top-level domain names like .test, .example, .invalid, and .localhost for private testing, documentation, and to avoid conflicts.
  20. [20]
    Abuse Issues and IP Addresses - Internet Assigned Numbers Authority
    Jun 15, 2010 · This document was written to explain our role and to provide some pointers that may be useful in actually resolving abuse cases.