Developer Testing
Testing Signup and Email Verification Flows with Temporary Inboxes
A QA checklist for exercising signup and verification mail with a 10-minute receive-only inbox, based on building this service. Use it only on systems you are authorized to test.
I built this inbox so a browser can catch a message and then forget it. The same loop is useful when you are testing signup and email verification on a system you own or are authorized to test. It is not a license to open extra accounts on other people’s products, and it is not a place for real customer data.
This guide is the testing playbook. It assumes a 10-minute, receive-only mailbox with no outbound mail and no recovery—the constraints this site actually has.
What this kind of testing is for
Use a temporary inbox when you need to:
- Confirm that your app sends a verification message
- Read a one-time code or confirm-link from a staging or local environment
- Check that the message is readable (subject, text, HTML, attachments you expect)
- Repeat the flow without filling a personal Gmail with test noise
Do not use production customer addresses, production dumps, or live payment accounts “just to see.” Do not point tests at a third-party service in a way that violates its terms.
What this inbox cannot simulate
- Sending mail from the test address (there is no SMTP out)
- Long-running accounts (the mailbox dies in 10 minutes)
- Recovering an expired test identity
- Deliverability into Gmail or Outlook (this is a separate domain)
- Getting around a vendor’s disposable-domain blocklist
If your product must accept only durable addresses, test that rejection path honestly. If you block disposable domains, this inbox should fail in staging the same way it would in production.
Preconditions
- You are authorized to test the target system
- You have a staging (or local) environment that can send mail
- You will not paste live personal data into the form
- You can finish the verification step inside 10 minutes, or you will create a fresh mailbox and resend
A reusable QA loop
- Open the homepage inbox and create a mailbox.
- Copy the address with the provided control.
- Submit your signup form.
- Watch this tab until the message appears (the UI polls on a short interval; manual refresh exists with a cooldown).
- Open the message. Confirm subject, recipient, and that the code or link matches what your app should send.
- Complete verification in the app.
- Delete the mailbox, or let it expire. Do not leave test mail sitting around.
If the timer is close to zero, do not keep waiting. Create a new mailbox and trigger a new send. Expired inboxes cannot be recovered. See expiration troubleshooting.
Test cases worth running
| Case | What to look for |
|---|---|
| Happy path | Message arrives; code/link works once |
| Resend | A second message arrives; old code behaves as your app specifies |
| Typo in email | Your app shows a clear error; nothing is sent to a stranger |
| Disposable domain blocked | If you block these domains, the form should refuse this address |
| Slow send | Mail after several minutes; your copy should tell the user to wait or retry |
| HTML vs text | Body is readable after sanitization; essential code is in the text part too |
| Confirm link | Link host is your domain; it does not require a different device session you do not have |
| Expiry of your token | App token expires even if this mailbox is still alive |
| Mailbox expiry | After 10 minutes you cannot read the message here; your app should not depend on that |
Staging recommendations
- Send staging mail from a clearly labeled environment so nobody mistakes it for production
- Never load production user tables into a test signup
- Prefer unique test accounts you can delete
- If you need many repetitions, wait for the rate limits on this site and on your own mailer—do not script mailbox farms against either side
- Keep Turnstile or your own bot checks enabled in production; disable them in local QA only when you understand the risk
Building this service taught a few sharp lessons: the timer starts at creation, not at first byte received; a cookie-bound session does not follow you to another browser; HTML email that looks fine in Gmail can still contain markup we will strip; attachments outside a small allowlist never show up.
Security warnings
- Do not test with real production customer information
- Do not use this inbox to probe a system you are not allowed to test
- Do not treat sanitization as a reason to click unknown links
- Do not try to defeat another site’s disposable-mail detection
- Report abuse of this service on Report abuse
The Acceptable Use Policy still applies during QA.
Related reading
