Example.com is a domain reserved by RFC 2606 for use in documentation, tutorials and sample code. It is held by IANA, cannot be bought or registered by anyone, and accepts no email. That is why you see it in placeholders like name@example.com: it shows the format of an address without pointing at a real person or company.
What example.com is and who owns it
Open example.com in a browser and you get a single page titled Example Domain with a short note: the domain exists for illustrative examples and may be used in documents without asking permission. There is no sign-up, no dashboard, no mailbox service behind it.
The domain is administered by IANA, the function that manages the DNS root zone and the registries of protocol parameters. Run whois example.com and the registrar field reads RESERVED-Internet Assigned Numbers Authority. The name never expires into the open market, never goes to auction and cannot be sniped by a drop-catcher. Its siblings example.net and example.org are held the same way. If you want to understand every field in that WHOIS output, see our WHOIS lookup guide.
Why every tutorial uses it: RFC 2606 and RFC 6761
Before 1999, authors invented hostnames for their examples, and sooner or later someone registered those names. Readers pasted configuration from a book into production and ended up sending traffic to a stranger's server. RFC 2606 fixed this by reserving four top-level domains (.test, .example, .invalid, .localhost) and three second-level names: example.com, example.net and example.org.
In 2013, RFC 6761 went further. It created a registry of special-use domain names and spelled out how applications, stub resolvers, recursive resolvers and authoritative servers should treat each one. Names under .invalid must always come back as non-existent; names under .localhost may be answered with the loopback address without asking DNS at all. IANA keeps the current list in the Special-Use Domain Names registry.
Reserved names compared
These names are not interchangeable. One resolves to a working website, another is guaranteed never to resolve, and a third always means "this machine".
| Name | Defined in | Behaviour | Typical use |
|---|---|---|---|
| example.com / .net / .org | RFC 2606 | Resolves and serves the Example Domain page over HTTP and HTTPS | URLs and hostnames in docs and sample code |
| .example | RFC 2606 | Not delegated in the root; NXDOMAIN | Fictional organisations: acme.example |
| .test | RFC 2606, RFC 6761 | Does not exist in public DNS | Test environments with their own DNS |
| .invalid | RFC 2606, RFC 6761 | Guaranteed non-existent | Testing error handling, deliberately broken addresses |
| .localhost | RFC 2606, RFC 6761 | Loopback: 127.0.0.1 / ::1 | Local development |
| home.arpa | RFC 8375 | Residential networks only | Device names on a home LAN |
| .local | RFC 6762 | Handled by multicast DNS (Bonjour, Avahi) | Zero-config device discovery, not your own zones |
ICANN has also set aside .internal for private networks, which gives companies a safe replacement for home-grown suffixes like .corp or .lan that carry no such guarantee.
What you get at https://example.com
The site answers on http://, https:// and www alike, and the HTTPS certificate is genuine, so no browser warning appears. That is deliberate: snippets such as curl https://example.com or fetch('https://example.com') are meant to run cleanly, so a beginner is not left debugging their own setup.
curl -I https://example.comA 200 status line followed by server headers means everything works. If the command fails, the problem is your network, proxy or resolver — not example.com.
Subdomains such as api.example.com, app.example.com or smtp.example.com are a different story. In documentation they stand for "your API host here". There is no working API, app or mail relay behind them, so when a guide says host: api.example.com, replace it with the real value from your provider or admin panel before running anything.
Email at example.com: placeholder, not a provider
Sign-up forms often show name@example.com as the hint text in the email field. It illustrates the format — mailbox, @, domain — and nothing more. You cannot create an inbox on example.com, and mail sent to any address there will not be delivered.
The domain states this explicitly in DNS. At the time of writing it publishes a null MX record as defined in RFC 7505 — an MX with preference 0 and an empty host (.). A sending server that sees it bounces the message immediately instead of retrying for days. Check it yourself:
# Linux / macOS
dig example.com MX +short
# Windows cmd
nslookup -type=mx example.com
# PowerShell
Resolve-DnsName example.com -Type MXThe part after the @ is the domain whose MX records decide where mail goes; our explainer on MX records walks through how that lookup works. And if you need to know whether a real address actually exists, see how to verify an email address.
A practical warning for developers: never seed a test database with addresses like test@gmail.com or admin@company.com. Use user1@example.com or anything under .invalid, and a misfired job cannot reach a real inbox.
Why apps are called com.example
Android package names and many bundle identifiers follow reverse-domain notation: a company that owns acme.io names its app io.acme.app. Android Studio fills in com.example.myapplication for new projects, which is why com.example.* names show up in tutorials, crash logs and half-finished builds. Google Play rejects package names that start with com.example, so switch to a namespace based on a domain you control long before release.
Which domain to use for testing and documentation
The rule is short: no example, fixture or template should contain a name that a real person or company could own. Pick from this table instead.
| You need | Use | Why |
|---|---|---|
| A URL in a README, blog post or book | example.com, example.org, example.net | Reserved, resolvable, owned by nobody who could abuse it |
| Placeholder in an email field | name@example.com | Null MX, mail never lands anywhere |
| An address that must fail to resolve | user@mail.invalid | NXDOMAIN is guaranteed by the standard |
| Local development | app.localhost, api.localhost | Always your own machine, no hosts-file edits in most browsers |
| A staging stack with its own resolver | shop.test | Never collides with a public zone |
| A home network | nas.home.arpa | RFC 8375 was written for exactly this |
| Internal corporate services | A subdomain of your own domain, or .internal | You control the name; no collision risk |
| IP addresses in docs | 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32 | Documentation ranges from RFC 5737 and RFC 3849 |
| An app identifier | com.yourdomain.app | com.example is refused by the store |
Two suffixes cause recurring pain. .local belongs to multicast DNS, so on macOS and on Linux with Avahi a unicast zone named .local can resolve slowly or not at all. .dev is a real top-level domain run by Google and the whole zone is on the HSTS preload list, so browsers will only open those names over HTTPS — a local project at myapp.dev without a certificate simply will not load.
The cost of inventing "realistic" domains
Made-up names like test.com or mycompany-demo.com are either already registered or can be registered tomorrow. test.com, for instance, is an ordinary domain with an owner.
- Data leaks. A test job emails fixture data to an address that belongs to someone real.
- Traffic to strangers. Readers copy your config and their clients start calling a host you do not control.
- Takeover by documentation. If your docs mention an unregistered domain, anyone can buy it and answer the requests your users send.
- Name collisions. Private suffixes such as .corp or .home are not protected the way .test and .internal are, and queries for them leak to public resolvers.
If an example needs to look realistic, build it on reserved ground: billing.example.com, mail.example.org, or a fictional company like acme.example.
How to check a domain yourself
- Ownership and registration status: run a WHOIS lookup. For example.com you will see IANA; for an invented "test" name you may find a real owner. To check whether a name is free, see how to check domain availability.
- Published records: use the DNS lookup to see A, AAAA, the null MX and the SPF record in TXT.
- What the web server returns: the HTTP header checker shows the status code, redirects and security headers.
New to the terminology? Start with what a domain is.
FAQ
Can I buy example.com?
No. It is reserved by RFC 2606 and held by IANA. It is never released, sold or auctioned, and the same applies to example.net and example.org.
Can I sign up for a service with user@example.com?
A form may accept it, but the confirmation email will never arrive and you will have no way to recover the account. Use an address you actually own.
Is example.com safe to open?
Yes. It is a static IANA page with no scripts, ads or forms. If you see something else at that address — ads, a redirect, a warning — check your hosts file, DNS settings and browser extensions.
What is the difference between example.com and .example?
example.com is one specific domain that resolves and serves a page. .example is a whole top-level domain that is not delegated at all, so any name under it, such as shop.example, does not exist.
Why does example.com load but example.test does not?
example.com has address records in public DNS; .test is absent from the root zone, so resolvers answer NXDOMAIN. .test only works inside networks where you run your own DNS for it.
