Click "Generate Fake Emails" to create random test addresses at reserved domains
This fake email generator creates random test email addresses at reserved example and test domains. Developers and QA testers use them to fill forms, check validation and build seed data without touching a real inbox. Pick how many you need and copy the list. It is free, runs in your browser and needs no sign-up. It is not for signing up to real services.
Click "Generate Fake Emails" to create random test addresses at reserved domains
Addresses use domains set aside for testing and examples, so no real person receives anything you send.
Create one address or a full batch at once with the Number of Emails setting.
Copy a single address with its icon, or grab the whole list with Copy All Emails.
Click Regenerate to get a fresh batch with the same settings when you need new unique values.
Three steps from a blank form to a result you can use.
Choose how many addresses you need for this test run or seed file.
Select which reserved domain the addresses should use, such as an example domain or a test domain.
Click Generate Fake Emails, then copy single addresses or the full list into your form, fixture or script.
A fake email generator for testing gives you realistic looking addresses that belong to nobody. That makes them safe for form checks, staging databases and demo screenshots.
Many random email generators invent addresses at popular providers. That is a problem. A made up address at a real provider can belong to a real person, so a staging system that sends a welcome email or password reset may land in a stranger's inbox. It can also leak test data and hurt your sending reputation.
The internet standards body set aside names for exactly this job. RFC 2606 reserves these names:
| Name | Reserved purpose | Good test use |
|---|---|---|
example.com, example.net, example.org | Names that can be used as examples | Docs, tutorials, screenshots, demo accounts |
.example | Documentation and examples | Sample config files and API docs |
.test | Testing of current or new DNS related code | Staging data and local test environments |
.invalid | Names that are sure to be invalid | Negative tests where an address should fail |
We suggest using these domains by default in fixtures and seed scripts. Nobody can register them, so a test email that slips out of your staging system goes nowhere instead of reaching a person.
Example: a team is testing a new sign-up flow and needs 20 users in staging. They set Number of Emails to 20, choose an example domain and click Generate Fake Emails. The list looks like this (illustration only):
maya.ortiz42@example.com
k.lindqvist@example.com
test.user.0917@example.com
jordan_reid88@example.comThey click Copy All Emails and paste the list into a CSV next to names and roles. The seed script loads the CSV into the staging users table. For the negative test, they add one address ending in .invalid and confirm the form shows a clear error message.
If the import fails because two rows share an address, they click Regenerate and replace the duplicate. The whole job takes a few minutes and no real inbox is involved.
A batch of addresses is only useful if you test the right things. We suggest this checklist for any form that accepts an email:
qa+signup@example.com. Some forms strip or reject the plus character, which is usually a validation bug in your own app.Fake addresses at reserved domains cannot receive mail. To test that an email actually arrives and renders, send it to an inbox your team controls, such as a shared QA mailbox.
This tool creates strings that look like email addresses. It does not create inboxes. Keep these limits in mind:
When your QA work turns into a list of bugs and fixes, Onethread can hold those as tasks with owners and due dates so nothing gets lost between test runs.
Default to example.com or a .test domain in fixtures so a stray staging email never reaches a real person.
Add one address ending in .invalid to every validation test to confirm the error path works.
Test a plus sign address on every sign-up form, because many forms reject it by mistake.
Check large batches for duplicates before importing into a table with a unique email column.
Tag seeded test accounts with a clear role or name so you can find and delete them later.
Developers and QA testers use it to fill sign-up forms, test email validation, create seed data for staging databases and make demo screenshots. The addresses look real but use reserved test domains, so they do not belong to anyone and no real person receives messages sent to them during testing.
No. The tool creates text strings in email format, not working inboxes. Reserved domains such as example.com and .test are not meant to receive mail. To test that a message arrives and renders correctly, send it to an inbox your team controls, such as a shared QA mailbox or a plus alias.
We do not recommend it and the tool is not built for it. Most services send a verification link, which you cannot open without an inbox. Using fake details to get around a service's terms can also break those terms. Use these addresses only in apps you own or are allowed to test.
A made up address at a real provider might belong to a real person. If your staging system sends a password reset to it, a stranger gets your test email. RFC 2606 reserves example.com, example.net and example.org for examples, so nobody can own them and nothing reaches a real inbox.
Yes. The tool is free and needs no sign-up. It generates the addresses inside your browser, so nothing you create is stored or sent to a server. You can generate as many batches as you like and regenerate whenever you need new values for another test run.
Each address is random, so repeats are rare in small batches but possible in large ones or across several runs. If you load the addresses into a table with a unique email column, check for duplicates first or click Regenerate and replace any address that appears twice.