Use addresses at example.com, example.net or example.org, or at a domain ending in .test, for every email in test data. These names are reserved by an internet standard so they never belong to a real mailbox. Random addresses on gmail style domains can reach real people.
Why this matters
Staging systems send mail. Password resets, invoices, digests and alerts all fire during tests. If your test users have emails like jane.doe84 at a popular provider, one of those messages may land in a stranger's inbox, and it can contain whatever your test fixtures hold.
Data generators make this easy to get wrong. The Faker documentation notes that the emails its standard method produces could coincidentally be real addresses, so you should not use them for sending. For that case it points to a separate example email method.
What is reserved
RFC 2606 sets aside names for testing and documentation. The table lists what the standard reserves.
| Name | Intended use |
|---|---|
| .test | Testing of current or new DNS related code |
| .example | Documentation or examples |
| .invalid | Online construction of domain names that are clearly invalid |
| example.com, example.net, example.org | Second level names reserved for examples |
Of these, example.com style names are the most common choice in fixtures. The .test suffix is handy when you want many distinct hostnames, such as tenant1.test and tenant2.test, without any chance of resolving on the public internet.
Steps to adopt it
- Search your fixtures, seed scripts and factories for email patterns. List every domain that is not reserved.
- Replace them with a single helper that builds addresses at a reserved domain, such as user plus a counter at example.com.
- Add a lint or test that fails when a fixture contains an email on any other domain. A simple regular expression over the fixtures folder is enough.
- Configure staging to deliver all outgoing mail to a catch tool rather than the internet. See the related post on stopping staging from emailing real customers.
- Keep one allowlisted domain of your own for the rare end to end check that needs real delivery, and use mailboxes your team controls.
Edge cases
Plus addressing on your own domain, such as dev plus test1 at your company domain, is fine when you own the mailbox. It is not a substitute for reserved names in shared fixtures, because the fixtures get copied into repos and demos.
Do not invent a domain that looks unregistered. A made up name like acme-test-users.com may be registered tomorrow by someone else, and mail to it will then arrive there.
Mistakes to avoid
- Using your customers' real domains in realistic looking test accounts.
- Copying a support ticket email address into a bug reproduction.
- Letting a webhook or notification feature bypass the mail catcher by using a separate provider key.
- Assuming the mail provider's sandbox mode covers every message type. Check each sender.
Quick check
Is example.com a real website?
Yes, it resolves, but it is a documentation placeholder run for that purpose. It is not a customer mailbox, and the standard reserves it for examples.
Can I use .local for test hosts?
It is not on the list above, and it has other uses on local networks. Prefer .test for hostnames and example.com style names for emails.
Does a reserved domain stop all delivery risk?
It removes the risk of reaching a real person at that address. You should still send staging mail to a catch tool, because other fixtures may hold different addresses.
Sources
Last reviewed: 19 October 2026.
