Test Email Addresses That Never Bounce

Every app with a signup form eventually needs email addresses that aren't yours and aren't your customers'. The trick is choosing addresses whose failure mode is safe — and the safest address of all is one that cannot exist.

The reserved domains that can never receive mail

In 1999, RFC 2606 set aside names for documentation and testing so nobody would ever accidentally register them: the second-level domains example.com, example.net, and example.org, plus the top-level domains .test, .example, .invalid, and .localhost (later reaffirmed by RFC 6761). IANA holds them; they never appear in the public DNS the way a real domain does.

That reservation is what makes an address like [email protected] the perfect test datum: it is syntactically valid, it is guaranteed undeliverable by construction, and it can be published in documentation forever without spamming anyone. Faker — the engine behind our fake email generator — exposes exactly these three domains in its reserved mode.

The gmail.com problem

Generated addresses on real providers look more realistic — and that's exactly the trap. [email protected] sits on a real domain with real inboxes. Send mail to it and one of two things happens: it bounces (harmless), or that username exists and a stranger gets your password-reset link, your invoice, or your test marketing blast (very much not harmless).

Name-based usernames make this worse, not better. Real signup systems build addresses the same way generators do — first name, surname, a number — so a meaningful fraction of generated gmail-shaped addresses correspond to actual accounts. The rule is simple: provider-mode addresses are for display and storage, never for a To: field. If a generated list must be visibly realistic, generate it in reserved mode instead.

What validators do with each kind

Format validators (regex, HTML5 type="email") pass everything shaped like an address — reserved, provider, or custom. Deliverability validators split: an MX lookup on example.com fails because the domain deliberately has no mail exchanger for the world, while a gmail.com address may show valid MX records regardless of whether the specific inbox exists.

Neither behavior is a bug. Signup forms often block example.com on purpose — a user registering an undeliverable address is a support ticket in the making. When you test such a form, reserved-domain rows are your negative cases (expect rejection), provider-mode rows your format positives (expect acceptance), and only a domain you control can prove the full loop.

When you need the mail to actually arrive

Validation and storage tests stop at the inbox. Password resets, confirmation links, and notification digests need mail that a test can read. Two patterns cover it:

• Catch-all domain. Point a domain you own at a catch-all inbox; every address at that domain lands in one place. Generate addresses in custom mode on that domain and you get realistic usernames plus readable mail.
• Test-inbox service. The Mailosaur and Mailtrap class gives you disposable domains with an API to query what arrived — better for CI, since the test reads the inbox programmatically.

Either way, keep real customer inboxes out of your test environment entirely. The convenience of "just use my email" is how reset links and order confirmations end up in production mail logs with test payloads attached.

Realistic usernames, reproducible runs

Faker builds local parts the way real systems do: a first name, an underscore or hyphenated surname, usually a number — Ashton_Donnelly-Veum78, Amari_Hickle92, Colleen_Roberts8 — drawn from the same 3,186-name pool as the name generator. Local parts stay far under the 64-character ceiling RFC 5321 sets (our measured maximum: 22), and domains under its 255 cap, so length-validation tests won't fire by accident.

Seeds work here too: seed 2026 in provider mode yields the same five addresses every run, and the same seed in reserved mode re-draws the same usernames on example domains — handy when a fixture needs the same "person" across names, addresses, and emails. Custom mode even switches style to dotted First.Last addresses, which is what most corporate systems generate.

The bottom line

Match the address to the test: reserved domains for anything published or stored, provider-shaped addresses only where realism must be visible and sending is off the table, and a catch-all or test-inbox domain when delivery itself is under test. Generate all three flavors with the Fake Email Generator, and complete the synthetic customer with the Fake Name Generator and Random Address Generator.