Test addresses that are safe by construction: example.com and example.org are reserved by standard and can never be registered by anyone.
Every address this tool produces ends at example.com, example.net, example.org, or one of the reserved top-level domains .test, .example, .invalid and .localhost. That list is not arbitrary. RFC 2606, published in June 1999, set those names aside so that documentation, tutorials, sample configuration files and test fixtures would have addresses and hostnames that could never collide with somebody's real property. IANA holds the second-level names on behalf of the IETF; nobody can register example.com, and no mail server sits behind it.
The consequence matters more than the trivia. When you paste a generated address into a seed script, a form screenshot or a bug report, there is no inbox at the other end waiting to be surprised. You are not borrowing a stranger's identity for the length of a QA cycle. Compare that with typing something plausible, a first initial plus a surname at a large consumer mail provider. That address probably belongs to someone, and if your staging environment ever picks up live SMTP credentials, they will hear from you.
So treat the reserved domain as the feature rather than the placeholder you intend to swap out later. A random email generator that emitted realistic domains would just be a slow way to mail strangers. Every other detail on this page is negotiable; that one is not.
Reserving names in a document is one thing; making resolvers honour them is another. RFC 6761, published in February 2013, created the IANA Special-Use Domain Names registry and wrote down how software must treat each entry. The name localhost resolves to the loopback address and nothing else. The test top-level domain is for local testing and is not delegated in the global DNS. .invalid is guaranteed never to resolve: a conforming resolver answers NXDOMAIN without ever asking an authoritative server. The example domains are listed there too, marked for documentation use.
That matters for anything you build around generated addresses. If your code attempts a DNS lookup on a host under .invalid, it fails immediately and locally instead of firing a query out to the internet, which makes it a clean choice for offline test suites and for negative cases where you want resolution to fail fast.
There is also a standard way for a domain to announce that it accepts no mail at all: the null MX record described in RFC 7505, a single MX with preference 0 whose target is the root. A sender that understands it stops immediately and returns a permanent failure rather than queueing and retrying for days. Reserved documentation domains are administered for documentation, not as mail hosts; there is no mailbox to accept your message and no operator expecting one.
Syntax tells you whether an address could exist. Delivery tells you whether it does, and only one of those is a property of the string in front of you.
SMTP has a verification command, VRFY, and almost nobody leaves it enabled, answering it truthfully hands address harvesters a free directory, so servers either refuse it or reply with a deliberately unhelpful 252 that promises nothing. Many domains are configured to accept every recipient at the door and decide afterwards, so a successful RCPT TO proves very little; the rejection arrives later as a bounce to your envelope sender. Greylisting adds a temporary refusal on first contact purely to see whether you retry the way a real mail server would.
When a refusal is real, it carries a three-digit reply code and usually an enhanced status code: 550 with 5.1.1 means the mailbox does not exist, while 452 with 4.2.2 means it exists and is over quota. A permanent 5xx and a transient 4xx demand opposite responses, and code that lumps them together will discard addresses that were merely busy.
The practical consequence is unglamorous. The only reliable test of an address is a message that arrives and a link somebody clicks. Everything before that (regex, MX lookup, third-party scoring) is inference, and inference is exactly what fake test data does not need.
RFC 5321 puts hard numbers on the parts of an address, and they are smaller than most people assume. The local part, everything left of the @, is limited to 64 octets. The domain is limited to 255 octets. The forward-path, which is the address wrapped in angle brackets as SMTP transmits it, is limited to 256 octets, which leaves 254 characters as the real ceiling for the address itself.
That figure has a history worth knowing. RFC 3696 stated a total of 320, reached by adding 64 plus one plus 255, and an erratum records the tighter 254 that SMTP's own path limit actually imposes. If you inherited a validator or a column width from an older codebase, that is a common place to find the wrong number baked in.
Note the word octets, not characters. Under the ASCII assumptions most systems still make, the two coincide, but a UTF-8 local part spends between one and four octets per character, so an internationalised address reaches 64 octets long before it reaches 64 letters. The domain has its own nesting limits inherited from DNS: 63 octets per label, 255 for the fully qualified name.
Two useful fixtures fall out of this: one address exactly at the local-part limit, one exactly at 254 overall. Generate them, store them, and watch which layer truncates silently.
The address grammar you are trying to match lives in RFC 5322, and it is stranger than the pattern in your codebase assumes. The local part may be a quoted string, so an address with a space inside quotation marks is legal. Comments in parentheses are legal inside an address. A domain literal in square brackets is legal, so user@[192.0.2.1] is valid and no regex written around dotted labels will accept it. Plus-tags, hyphens, apostrophes and single-character local parts are all legal and all routinely rejected by production forms.
Then internationalisation arrives. RFC 6531 added the SMTPUTF8 extension, which permits UTF-8 in the local part, while the domain side goes through IDNA2008 and its xn-- punycode encoding. Even HTML gave up: the email input type defines its own narrower syntax and the specification openly calls it a willful violation of RFC 5322.
Styled characters are a separate trap. Letters from the Mathematical Alphanumeric Symbols block, U+1D400 to U+1D7FF, look like bold or script letters but carry compatibility mappings that fold them back to plain ASCII, and they are not valid in a domain name. They also sit outside the Basic Multilingual Plane, so each one costs two UTF-16 code units and a field counting code units accepts roughly half as many as you expect.
Validate loosely, then confirm by sending.
Subaddressing, the user plus tag convention, is described for filtering purposes in RFC 5233, the Sieve subaddress extension, which defines a local part split into a user and a detail separated by a delimiter. The plus sign is the common delimiter, though the standard does not mandate one and some systems use a hyphen or a period instead.
Two things make it useful. First, filtering: mail addressed to a tagged variant routes to the same mailbox but can be sorted by a rule matching only the detail. Second, tracing: give each service its own tag and the tag travels with the address. When unsolicited mail turns up addressed to the tag you gave one bookshop, you know exactly which list your address escaped from, with no ambiguity and nothing to argue about.
Tagged variants also make good fixtures. Dozens of unique addresses that a real system would route to one inbox exercise both your uniqueness constraints and your deduplication logic in a single pass.
Now the honest part. A tag is trivial to strip, one substitution removes everything from the plus to the @, so it identifies a careless partner, not a determined one. Plenty of signup forms reject the plus outright even though it is perfectly valid, and the tag exposes your base address to anyone who reads it.
The uses worth naming are variations on one need: a string shaped like an address, sitting somewhere mail might accidentally be sent.
Seeding a database is the obvious one. Fixture files get committed, copied between branches and pushed to public repositories, where they are scraped. An address at a reserved domain in that file is inert forever; a plausible one at a live consumer domain is somebody's address that you have just published.
Screenshots and documentation come second. A signup form captured for a help article, an invoice mockup, a slide showing an admin panel. Each is a place where a real address leaks and stays leaked. The same reasoning produced RFC 5737, which reserves 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 as documentation IP ranges so that examples never point at a live host.
Load-testing a signup path is third. You need thousands of distinct addresses that pass your validator and stress your unique index, and you emphatically do not want your outbound queue attempting delivery to any of them.
Teaching is fourth. Validation is far easier to explain with concrete inputs: one address at the length limit, one with a quoted local part, one whose domain can never resolve. Reserved names give you all three without borrowing anybody's identity to make the point.
Here is the trade, stated plainly. Because these addresses cannot receive mail, whole classes of testing are out of reach. You will not get a confirmation link, a password reset, a magic-link login or a receipt. You cannot test a double opt-in flow end to end, check how your message renders in a real client, or find out whether a spam filter accepts it. Anything that depends on a message arriving needs a mailbox you actually control: a domain you own, or a local SMTP sink that catches outbound mail before it reaches the internet.
There is a second friction. Some registration forms explicitly block the reserved domains alongside disposable-mail providers, so a generated address may be rejected on purpose by the very form you wanted to fill. That is the reservation working as designed, not a defect in the address.
And these addresses look fake, because they are. In a customer-facing screenshot that is usually the point; in a sales demo where you want realism, it will read as placeholder text.
None of that is fixable without surrendering the safety property. A domain you own carrying a null MX record is the honest upgrade: realistic, still undeliverable, and yours to answer for. What you should not do is invent an address at a domain somebody else operates.
Not here. The reserved domains are the safety model, and swapping them out removes it. If you need branded-looking test addresses, use a subdomain you control, publish a null MX record on it, and point your staging transport at a sink rather than a real relay. Realistic, still undeliverable, but infrastructure you have to own.
No, and it is not worth attempting. Nothing sent to a reserved domain reaches anyone, so any confirmation step simply never completes, and many services reject the domains on sight. For a genuine throwaway inbox you need something that actually receives mail: a plus-tagged address on your own mailbox, or an alias at a domain you control.
It is administered by IANA on behalf of the IETF and cannot be registered by anyone. Visiting it serves a short page saying the domain exists for use in illustrative examples. The same holds for example.net and example.org. That is precisely why they are safe to hard-code: there is no future owner who might start collecting mail sent there.
No. It is reserved, but for a different job: RFC 6762 sets .local aside for Multicast DNS, so names under it get resolved by devices on the local link rather than through the global DNS. Putting it in documentation invites confusing behaviour on real networks. Stick to .example, .test or .invalid, which carry no link-local resolution semantics.
Random generation guarantees nothing, with a modest pool of names, collisions show up sooner than intuition suggests. If a unique index has to hold, append a counter or a UUID fragment to the local part instead of trusting randomness, and keep the 64-octet local-part limit in mind when the base name is already long.
The domain is case-insensitive. The local part technically is not: only the destination server may interpret it, and it is entitled to treat two casings as different mailboxes. Nearly every large provider folds case anyway. For test data, store the address exactly as entered, compare the domain case-insensitively, and never silently lowercase the local part.
No. Even with SMTPUTF8 in play, styled letters are not ordinary Latin characters and a domain containing them is invalid, so most forms reject them before a mail server ever sees them. Style the label beside the field or the display name on the account instead. The address itself is one place the substitution trick reliably breaks.
The same idea from a different registry. In North America the 555-0100 through 555-0199 range is set aside for fictional use, and in the UK, Ofcom reserves drama numbers including 07700 900000 to 07700 900999. A real-looking number in test data fails the same way a real-looking address does: somebody's phone rings at three in the morning.