Why testers use a disposable inbox
Almost every application sends emails: order confirmations, one-time codes, invoices, booking details, alerts and notifications. Those emails are part of the product, and they break more often than people expect. The link points to staging. The code arrives after it has already expired. The sender shows up as a raw server name like ip-10-0-3-17.internal. Nobody notices until a real user complains.
Testing them with your own Gmail does not scale. You run out of "+" aliases, your inbox fills up with test junk, and you cannot easily hand the address to a teammate. A disposable inbox fixes that: open the page and you have a test email address. Copy it, use it in your application, and watch the email arrive in real time. When you are done, forget about it. It deletes itself after 7 days.
Because this is a real inbox on a real domain, your app sends to it over normal SMTP exactly as it would to a customer. You are testing the whole path, from your code to your email provider to DNS to delivery, not a mock.
How to test your application's emails in under a minute
- Copy the address at the top of this page.
- Use it in your application (local, staging or production) wherever it sends an email: an order, a booking, a payment, an alert.
- Watch the inbox. The email appears without refreshing, usually within seconds.
- Check the email: the sender, the subject, the content, every link and any code.
- Click the links or use the code to finish the flow and make sure each step works.
Example: testing a telecom plan purchase before release
Say you work in QA at a mobile operator, and next week's release changes how customers buy a plan online. A customer picks a plan, enters their email, pays, and from then on most of the journey happens by email. Every one of those emails has to be right on day one, because a wrong link here means a customer who cannot activate their SIM.
With a disposable inbox you can walk through the whole journey as a new customer, in staging, before it goes live:
- Buy a plan on the staging site with the address from this page.
- Verify the email address with the one-time code from the email.
- Check the order confirmation: the right plan name, price, taxes and order number.
- Check the eSIM or SIM activation email: the QR code image shows, it has alt text, and the activation link points to production, not to a staging server.
- Check the welcome email with the account number and the link to the customer portal.
- Repeat for each plan type (prepaid, postpaid, family plan) in a new tab, so every test customer has their own inbox.
The same idea works in any industry where a customer action is followed by emails: banking, insurance, e-commerce, travel bookings or SaaS trials. Test every email the customer will receive before your release, not after the first complaint.
Bugs this catches before your users do
- Staging links in production emails. A base-URL setting copied from the wrong environment. Extremely common, and invisible until someone clicks.
- Codes that expire too fast. The email takes 40 seconds to arrive and the code is valid for 30.
- Broken templates. A variable like
{{first_name}}left unrendered, or an empty subject. - Missing authentication. If your emails land in spam, check your sender's SPF, DKIM and DMARC. They are explained in plain English in SPF, DKIM and DMARC explained.
- Wrong language or locale. A French user receiving the English template, or dates in the wrong format.
Testing with several users at once
Invitations, team roles and approval flows need more than one person. Open this page in a new tab or a private window and you get a completely separate inbox. One tab per test user is the quickest way to run a multi-user scenario: invite user B from user A's account, accept from B's inbox, then check what A is told. There is more on this in multi-user testing for QA.
When not to use a disposable inbox
Disposable inboxes are for testing. Anyone who has the inbox link can read it, and everything is deleted after 7 days. So do not use one for production admin accounts, anything tied to payments, or any account you might need to recover later. For those, use a real mailbox your team controls.
FAQ
- Is this a real inbox or a mock?
- It is a real inbox on a real domain. Your app sends to it over normal SMTP, exactly as it would to a customer, so you test the whole path: your code, your email provider, DNS and delivery.
- Does it show HTML emails?
- Yes. HTML emails are rendered in the viewer, the way your users will see them.
- How long do test emails stay?
- Each email is deleted automatically 7 days after it arrives, and the inbox expires 7 days after it was created. You can also delete everything yourself at any time.
- Can I test with several users at once?
- Yes. Open the page in a new browser tab (or a private window) and you get a separate inbox. One tab per test user works well for invitations, roles and approvals.
- Why did my test email not arrive?
- Check the address for typos first. Some services block known disposable domains, and some providers delay the first email from a new sender by a minute or two. If your own app is sending, check its logs and its email provider dashboard.
- Should I use this for production accounts?
- No. Anyone with the inbox link can read it and it expires after 7 days. Use it for testing, never for accounts you need to recover later.