The safest test email is one that cannot reach a human. RFC 2606 reserves example.com, example.org and example.net precisely so that nothing addressed to them ever leaves your infrastructure — which is the default here.
What you can control
- Five local-part styles, from
first.lastto a random handle, so you can match whatever convention you are seeding. - Plus-addressing (
ada+billing@example.com) exercises the sub-address parsing that trips up a surprising number of signup forms. - Non-Latin names fall back to a Latin handle, so a Japanese record still produces an address a mailer can route.
- Custom domains let you point a whole batch at a catch-all you actually control.
What this is not
Reserved domains are guaranteed never to accept mail. Disposable-inbox domains listed here use the .example suffix and are equally inert — they are shaped like the real services without being them.
Questions
Can I actually receive mail at these addresses?
No, and that is the point. Reserved domains under RFC 2606 do not resolve to a mail server. If you need a receiving inbox, use the custom domain option with a catch-all you own.
Do these pass email validation?
Yes. They are syntactically valid and the domain has a valid form, so regex and library validators accept them. A live MX lookup will not.
What is the plus-tag for?
Sub-addressing. Many providers route ada+anything@example.com to ada@example.com, and a lot of signup forms mistakenly reject the plus sign. Turning it on finds those forms.