Realistic test addresses — provider, reserved, or your own domain
Quick answer: this generator builds name-based addresses like Ashton_Donnelly-Veum78 in three domain flavors: real providers (gmail.com, hotmail.com, yahoo.com — look realistic, never send to them), IANA-reserved domains (example.com/.net/.org — can't receive mail, safe to publish), or your own domain for catch-all test inboxes. Seed 2026 in provider mode yields [email protected], [email protected], [email protected], [email protected], [email protected]. Local parts stay well under the 64-character RFC 5321 limit. Runs in your browser.
| # | Email address | Domain type |
|---|---|---|
| Loading Faker engine… | ||
| Reserved name | Kind | Safe to publish? | Typical use |
|---|---|---|---|
| example.com | Second-level domain | Yes | Documentation, fixture files, screenshots |
| example.net | Second-level domain | Yes | Same, when you need variety |
| example.org | Second-level domain | Yes | Same |
| .test | Top-level domain | Yes | Internal test hostnames ([email protected]) |
| .example | Top-level domain | Yes | Examples in docs and specs |
| .invalid | Top-level domain | Yes | Deliberately non-resolving names |
| .localhost | Top-level domain | Yes | Local-only names |
The second-level domains are what Faker's reserved mode draws from; the four TLDs are reserved alongside them and never appear in the public DNS. That's the whole trick: an address at example.com is guaranteed undeliverable by construction, not by convention.
The engine is @faker-js/faker 10.6.0 (MIT), lazy-loaded on first generate and run entirely in your tab. Its internet module builds addresses the way real signup flows do — a person's name transformed into a mailbox, plus a domain — which is why generated lists look like production data instead of [email protected] over and over.
Real providers draws from exactly three domains — gmail.com, hotmail.com, yahoo.com — the provider pool in Faker's English locale. Reserved swaps in example.com, example.net, or example.org. Custom domain takes whatever you type (validated as a hostname — letters, digits, dots, hyphens, at least one dot) so every address points at a domain you control.
Pick a count up to 500, choose the domain mode, optionally set a seed for reproducibility, and generate. Copy as CSV for spreadsheets and imports, as JSON for fixtures, or download the CSV. The Domain type column keeps the three modes distinguishable when you're staring at a 200-row list at 6pm.
Seed 2026, count 5, Real providers:
Same seed in Reserved mode re-draws the same usernames on reserved domains — [email protected], [email protected], and so on — because the username sequence and domain choice both restart from the seed. In Custom mode with toolaspect.com, seed 2026 gives [email protected], [email protected], and three more in the First.Last pattern. Notice the custom mode's different username style — Faker formats provider-less addresses as dotted names, which happens to match how most corporate mail systems build aliases.
And the reminder that matters most: the provider-mode addresses sit on real domains. A quarter of name-based gmail addresses probably belong to somebody. Generate them, store them, screenshot them — but never put them in a To: field.
No — never. Provider mode builds addresses on gmail.com, hotmail.com, and yahoo.com. Those are real domains with real inboxes: mail to [email protected] either bounces or, worse, lands in a stranger's account. The reserved mode (example.com, example.net, example.org) is the safe one for documentation and test data — those domains are IANA-reserved by RFC 2606 and can never receive mail, which is precisely why the standard reserves them.
Provider mode draws gmail.com, hotmail.com, or yahoo.com — the most realistic-looking option, for UI screenshots and fixture files that must resemble production data. Reserved mode swaps in example.com, example.net, or example.org — safe to publish because they can't receive mail, but some signup forms deliberately reject them. Custom mode uses your own domain, which is what you want when a test suite needs to accept the address and you control the domain's catch-all inbox.
The same way real signup systems build them: a first name, an underscore or hyphenated surname, and usually a number — Ashton_Donnelly-Veum78, Amari_Hickle92, Colleen_Roberts8. The pattern draws from Faker's 3,186-name pool, so large batches look organically varied. Local parts stay far under the 64-character limit RFC 5321 sets, and domains under its 255-character cap.
Format validators pass them — they're syntactically valid addresses on syntactically valid domains. Deliverability checks are another story: provider-mode addresses may or may not have real inboxes (undecidable without sending mail), and reserved-mode addresses fail any DNS/MX lookup because example.com deliberately has no mail exchanger for external use. If your validator does MX checks, use custom mode on a domain you control.
Fake addresses exercise validation and storage, not delivery. For end-to-end flows — password resets, confirmation links — use a dedicated test-inbox service (the Mailosaur and Mailtrap class) or a catch-all domain you control, where every address lands in one inbox you can read from the test. Generate addresses here in custom mode pointed at that domain, and you get realistic usernames plus real receivable mail.
Yes, with a seed. Seed 2026, count 5, provider mode produces [email protected], [email protected], [email protected], [email protected], and [email protected] — every time, on any machine, because the generator and its locale data are version-pinned (Faker 10.6.0, English locale). Store the seed in the test, not the addresses.