Guide
Disposable email for testing sign-up flows
Disposable email for testing gives you a real address that receives mail, so you can run a sign-up flow, a password reset or an email verification step without using your own inbox. The addresses here are real gmail.com addresses with the inbox on the page, up to 500 at a time. They suit manual testing in staging well, and automated test suites far less, for reasons worth knowing before you start.
By Bathan DevUpdated 4 min read
Why testers need a fresh address every run
A fresh address is the only reliable way to test the path a new user takes, because most apps treat an email they have seen before differently. Sign up twice with the same address and the second attempt usually meets an ‘already registered’ error, a login prompt or a quiet merge with the old account. That is worth testing too, but it is not the first-time flow, and the first-time flow is the one that breaks most often.
Old mail is the other problem. If every run sends to the same inbox, this run’s welcome email sits on top of yesterday’s, next to a reset link from last week. It is easy to click the wrong link, read an old template, or pass a test because a message from an earlier run happened to be there.
A new address per run removes both problems. The account does not exist yet, and anything that reached the inbox before the address was generated is listed separately as Earlier mail, so this run’s messages stand on their own.
What to test with a disposable email address
Anything your product sends to a new or forgetful user is worth testing with a disposable email address. That means the sign-up flow from form to confirmation link, the email verification step, including what happens when a code is entered late or twice, the welcome email, the password reset, and the confirmation sent when someone changes their address.
Read each message as it was delivered, not as the template looks in your editor. The viewer here shows the full email with its images, links and attachments, so you can check that links point at staging rather than production, that images load, that attachments open, and that the subject and sender name are what you meant.
Emails open in a sandbox with scripts turned off. Most mail apps do not run scripts in email either, so if part of a message only works with them, you will see it fail here before your users do. When a message carries a verification code, it is picked out of the subject or body and shown beside the message, ready to copy into the next step.
Try it nowGet a temporary Gmail address in one click. No sign-up.
Get temp mailBulk test email addresses for QA
When you need many test email addresses, bulk makes up to 500 in one request. Copy them all, or download them as a .txt file, and you have a list ready for a test plan, a sheet of test accounts or a script that fills in forms. It costs one request rather than 500, which matters because the email service has a shared request limit.
Any address in the list can be made active to read its inbox. A tester can work down the list, sign up with the next address, make it active and confirm the mail arrived, without generating anything new between runs.
Treat the file with some care. On public accounts, anyone who knows an address can read what arrives at it, so a list of test addresses is also a list of readable inboxes.
Unique-looking addresses with dots and plus tags
Gmail’s dot and plus behaviour lets one inbox answer to many addresses that look unique to your app. Gmail ignores dots before the @ and anything after a +, so u.s.er@gmail.com and user+x7k@gmail.com reach the same mailbox while your database sees two different emails. The addresses here are made exactly that way, on shared accounts, and Gmail plus addressing and the Gmail dot trick explain each in more detail.
That is a test in itself. If your app should treat u.s.er and user as one person, sign up with both and see whether it does. If it should accept a + in an address, try a tagged one; plenty of forms refuse a valid + because their check is too strict.
For your own day-to-day testing, the same trick works on a Gmail account you own. Add a new tag for every run, and every message lands in an inbox only you can read.
Limits to know before you rely on it
It is a tool for testing by hand in staging, not a mail system for real users. Public addresses are shared, so treat every test email as readable by a stranger: never send real customer data, real passwords or production secrets to one, and never sign a real customer up with one. The service is receive-only, so you cannot test replies, and if its shared request limit runs out, it works again once the limit resets.
There is no public API, so a test suite cannot fetch mail from here. For automated tests, use a domain of your own with a catch-all mailbox, where any address at the domain delivers to one inbox you control, or a mail sandbox that catches everything your staging environment sends before it reaches anyone. Both keep test mail private, and both can be read by your own code.
For checking by hand that a flow works end to end, though, generate a temporary Gmail address and follow the mail exactly as a new user would.
Questions
Is there an API for automated email tests?
No public API is offered. For automated suites, a catch-all mailbox on a domain you own, or a mail sandbox in your staging environment, lets your tests read mail directly.
Can I use these addresses for real users in production?
No. They are shared, temporary and can be recycled at any time, so a real user’s mail could be read by others or lost. Use them only for test accounts that hold nothing real.
Why does a fresh test address show emails I did not send?
Shared inboxes keep old mail, so anything that arrived before you generated the address is listed separately as Earlier mail. Mail from your own test run appears apart from it.