The problem with a ten minute countdown
The original 10 minute mail idea was a good one: get an address, use it, and let it disappear on a timer so you never have to think about cleanup. It works well when everything goes to plan.
It works badly the rest of the time. Verification emails are not always instant. A queued sender, a greylisting delay, or a slow staging environment can easily eat several minutes, and if the countdown expires first you lose the mailbox and start over. Worse, you may have already completed a signup against an address that no longer exists, which means the account is unrecoverable.
The timer solves a problem you do not really have. Nobody needs the inbox destroyed on a schedule. They need it gone eventually, and available while they are using it.
How this works instead
There is no countdown. The address is generated when you load the page and stored in your browser, so it is still there if the verification email takes four minutes, or if you close the tab and come back. You replace it when you want a new one, by pressing New.
Two consequences worth knowing:
- It is tied to your browser, not an account. The inbox does not follow you to another device, and clearing site data discards it for good.
- Message retention is not ours to promise. Delivery runs on an upstream provider, so how long a message stays readable is their decision. Treat any disposable inbox as short-lived and copy out anything you need.
Using it
- Copy the address above. One has already been generated for you.
- Paste it into the form you are registering with or downloading from.
- Watch the live inbox. Messages appear automatically, with no need to refresh.
- Open the message to read the code or follow the verification link.
How this compares to the classic services
| Classic 10 minute mail | This service | |
|---|---|---|
| Lifetime | Fixed countdown, often extendable | No timer; lasts until you replace it |
| Inbox access | Sometimes public by address | Requires the access token issued at creation |
| Automation | Usually none | Free REST API, no key required |
| Domain blocking | Long-standing domains are widely blocklisted | Rotating pool, though still blocked in places |
| Recovery | Gone when the timer ends | Gone when you clear it; no recovery either way |
What it is good for
- One-off signups where you want the content and not the newsletter.
- Receiving a single code from a service you will not use again.
- Testing your own signup flow without filling a personal inbox with staging mail.
- Keeping accounts uncorrelated by using a different address per service.
What it is not good for
A disposable inbox is a convenience, not infrastructure. Do not use one as the recovery address for anything you care about, because if the mailbox is gone and you have forgotten the password, so is the account. Keep banking, government, healthcare, and work accounts on a real mailbox, and do not route anything confidential through a throwaway address.
Some sites will refuse the address outright. That is deliberate on their part, and the right answer is a mailbox on a domain you control rather than a workaround. Why temp mail gets blocked explains how the detection works.
If you are a developer
Clicking New repeatedly to test the same flow gets old quickly. Automating it is the point at which this stops being a 10 minute mail replacement and starts being test infrastructure. There are working Playwright and Cypress examples in the email testing guide.