Learning & reference
Example domains for testing: which to use, and how each one behaves
A handful of domain names are reserved so they can never belong to anyone. They are not interchangeable: one resolves and serves a real page, one never resolves, one always points at your own machine. Pick the one whose behaviour your test expects.
The reserved names
| Name | Reserved by | What happens when you resolve it | Use it for |
|---|---|---|---|
.test | RFC 2606, RFC 6761 | Not delegated in the public DNS, so nothing on the internet answers. | Test fixtures. The safe default for addresses and hostnames in tests. |
example.com example.net example.org | RFC 2606 | Resolves, and serves a real page run by IANA. | Documentation and screenshots. Not for tests that make requests. |
.example | RFC 2606, RFC 6761 | Not delegated. | Documentation where the example.com family reads wrongly. |
.invalid | RFC 2606, RFC 6761 | Resolvers should always answer that the name does not exist. | Tests that need a lookup to fail. |
.localhost | RFC 2606, RFC 6761 | Should resolve to your own machine's loopback address. | Local development: app.localhost, api.localhost. |
home.arpa | RFC 8375 | Resolved only inside a home network. | Home-network device names. |
.alt | RFC 9476 (2023) | Never looked up in DNS at all. | Names from non-DNS systems. Rarely what a test needs. |
Test suites that call example.com are sending real traffic. The domain is real and hosted, so a
test that fetches it in a loop is hitting someone else's server, and it will fail whenever your CI has no
internet access. Point request tests at .test names you control locally, or at a mock server.
Names that look safe and are not
| Name | The problem |
|---|---|
.local | Reserved for multicast DNS (RFC 6762). Lookups go out to the local network, and macOS, Windows and Linux handle it differently. Slow or failing resolution is the usual symptom. |
.dev | A real top-level domain. The whole namespace is HSTS-preloaded, so browsers force HTTPS on every .dev address. Local setups using it broke when that happened. |
.app | Also a real, HSTS-preloaded top-level domain. |
test.com, mail.com, domain.com | Registered domains owned by real companies. Mail sent to them in a test is mail sent to a stranger. |
company.internal | Reserved for private use by ICANN in 2024. Fine inside your own network, but it is not a test domain and will not resolve anywhere else. |
Email addresses to test a validator with
All on reserved domains, so none can reach anyone. Each is a case real users produce, or a case your validator must refuse.
| Address | Should be | Why it is here |
|---|---|---|
| jordan@example.test | Accepted | The baseline. |
| jordan+orders@example.test | Accepted | Plus addressing. Rejecting it is the most common validator bug. |
| o'brien@example.test | Accepted | An apostrophe is legal, and a real surname. |
| Jordan.Pike@Example.Test | Accepted | The domain is case-insensitive. Compare lowercase domains when checking for duplicates. |
| jordan@sub.dept.example.test | Accepted | Several subdomain levels. |
| josé@example.test | Your decision | Internationalised local part (RFC 6531). Valid, but only if your mail path supports it. |
| "jordan pike"@example.test | Your decision | A quoted local part with a space. Legal, rare, and often refused on purpose. |
| jordan@[192.0.2.1] | Your decision | An address literal. Legal, almost never wanted. |
| jordan@example | Usually refused | No dot in the domain. Legal in theory; nearly always a typo. |
| jordan..pike@example.test | Refused | Two dots in a row in an unquoted local part. |
| .jordan@example.test | Refused | A local part cannot start with a dot. |
| jordan@example.test. | Refused, or trimmed | A trailing dot. Valid in DNS, surprising in a form. |
| jordan @example.test | Refused | An unquoted space. |
Some validators refuse .test itself, because they check the domain against the list of public top-level domains and .test is deliberately not on it. If yours does, your test data cannot pass through it. Decide which you want: accept reserved test domains in non-production environments, or refuse them everywhere and use example.com in fixtures.
Questions
What domain should I use for test email addresses?
A name under .test, such as user@example.test. It is reserved, not delegated, and mail to it cannot be delivered.
What is the difference between example.com and .test?
example.com is a real domain that resolves and serves a page. .test is not delegated at all. Use example.com in docs and .test in anything that sends requests or mail.
Can I use .local for development?
Best avoided: it is reserved for multicast DNS. Use .test, or .localhost for names that point at your own machine.
Why does my .dev domain force HTTPS?
.dev is a real, HSTS-preloaded top-level domain. Browsers upgrade every .dev address to HTTPS. Use .test or .localhost.
Which domain is guaranteed not to resolve?
.invalid. Resolvers should always answer that it does not exist.
Keep going
All safe test data Reserved IP addresses → Email test files →
More from Learning
Guides and references for test data, file handling and AI evals. All free, no sign-up. See the full hub.