Do these emails receive mail?

No. The example.com, example.net and example.org domains are reserved by IANA precisely for documentation and testing. Any email to those domains bounces.

How is this different from a temporary email?

A real temporary email (10minutemail, mailinator) does receive mail for a while. These fake emails receive nothing — they are just strings in email format for forms and databases.

When to use example.com vs test.com?

example.com is IANA-guaranteed. test.com is not a reserved TLD and could be registered by someone. For critical fixtures, prefer example.com.

Do they pass email validation?

They pass format validation (regex). Existence checks (DNS lookup, MX record) reject them. That is expected: you want test data, not emails that receive spam.

Fake Email Generator for Testing

Why .example domains exist

IANA (Internet Assigned Numbers Authority) reserves example.com, example.net and example.org in RFC 2606 specifically for documentation, examples and cases where you don't want to point at a real domain. That guarantees two things: nobody can register them (they won't end up pointing somewhere else), and email servers reject them automatically.

The same applies to reserved TLDs like .test, .invalid, .localhost and .local: none resolve on the public internet, so they're safe for synthetic data.

Difference from real temporary emails

A real temporary email (Mailinator, 10minutemail, Tempmail) is a public inbox: anyone can read incoming messages. Useful for signing up to services without giving out your real email, but not for automated testing: you don't control delivery timing and they aren't private.

Generated emails here are different: they receive nothing. They're valid-format strings without a mailbox behind them. If your test sends mail to one, it bounces. That's what you want in CI/CD: no external system is affected by your test suite.

When to use each local-part style

Name-based (john.smith@example.com): when you want the email to "look" real, tied to a name. Useful for demos and screenshots.
Random (kx7p2qm9@example.com): when you only need uniqueness and volume. Useful for fixtures testing long lists.
user1, user2…: when order and traceability matter. Useful for tests where you reference "the fourth user" unambiguously.

Common email-data testing mistakes

Using your real email. If a test run skips a guard and sends mail, you fill your inbox or, worse, spam a teammate.
Using domains that look fake but are real. fake.com, nope.com and many others are registered. Stick with example.com.
Hard-coding one email everywhere. If all test users share an email, you don't catch uniqueness bugs in the database.
Not flagging emails as synthetic. An is_test_data flag makes cleanup easy.

Sending best practices in non-prod

Even with synthetic emails, harden against accidental sends:

In dev and staging, configure a mail catcher (MailHog, Mailtrap, mailpit). Captures everything the system "sends" without delivering it.
Whitelist only internal addresses on the sender outside production.
Implement a kill switch: an env var that disables real sending in any non-production environment.
Log every send attempt so leaks surface fast.

Email validation to keep in mind

The generator emits emails with valid format (name@domain.tld). Different libraries validate differently:

Simple regex (HTML5, frontend): accepts them all.
Strict RFC 5321: accepts.
DNS/MX lookup validation: example.com has MX (pointing to itself), but the specific address doesn't exist. Some libraries reject.
SMTP validation: bounces.

For tests where you need an email "that passes deep validation", use a real disposable email. For everything else, these synthetic ones are enough.

Fake Email Generator