Every temporary email address arrives with two clocks, and they do not run at the same speed. One clock belongs to the name you were handed: it measures how long that address stays yours. The other belongs to the messages inside it: it measures how long the server keeps whatever lands. Misreading either clock is behind most of the confusion people have with disposable mail, so it is worth pulling them apart before asking how to hold on to a code, a confirmation or a test fixture a little longer.
How long does a temporary address last?
A temporary address survives for the length of the session that created it, and that session is yours to end. On the tool here, an address is issued the moment the mailbox page loads, and it stays in your browser until you replace it, clear the page’s storage, or close the tab and lose the local record. Nothing about that moment is announced with a countdown, because the address itself is not on a timer; what ends it is the browser forgetting, not a server revoking anything.
There is a second, server-side sense in which an address lasts, and it is the one that matters while mail is still arriving. The domain that receives the message does not need an account to exist. It will accept mail for any label on its domain, which means a name can go on receiving after you have walked away from the page, as long as the same label is produced again. But the link between the name and your screen is fragile. The address is a value held in the browser, not a record on a server tied to your identity. Lose the value and you have not lost the ability to receive at that name so much as the instruction to look there.
The practical lifespan, then, is short and driven by your own behaviour. As long as the tab is open and still holds the address, it is alive. A refresh usually preserves it, because the page stores the assignment instead of regenerating it. A fresh visit with no stored value gets a fresh address, and the old one quietly becomes just another label that nobody is watching.
How long are the messages kept?
Messages are kept for the mailbox server’s retention window, which is set by whoever operates that server and is deliberately brief. For the mailbox behind this site, that window is fifteen minutes. A message that arrives and is not read within it is not archived and is not queued for later; it is deleted, and there is no bin to recover it from.
That number is not a judgement about your message. It is a storage decision. A service that keeps nothing for long does not need a backup rotation, a legal retention review or a support queue for people asking to resend mail from last month. By keeping the window short, the operator keeps the whole system shallow, cheap and free of the obligations that come with holding other people’s correspondence.
The clock starts when the message arrives, not when you open the inbox. Opening the page reads what is already stored; it does not extend the deadline. If a message landed ten minutes ago and you look at it now, you have roughly five minutes of the original window left, and no action on your part resets it. This is why a message can seem to appear and then vanish: you found it near the end of its life.
There is one more clock that is easy to miss, and it belongs to the sender. A verification code is almost always time-limited on the sending side too, often to the same order of magnitude. Even if the mailbox kept the message forever, the code inside it would stop being accepted. Two independent expiries have to be outlived for the flow to succeed.
Session storage vs the mailbox server
The reason the two clocks get confused is that a browser page shows you the result of both at once, as if they were one thing. The inbox on screen is assembled from two different stores that live in two different places.
What lives in the browser is the assignment: which address this tab is looking at. It is small, it is local, and it exists to make the page remember what you asked for. Clear the site’s storage, open a private window, switch device or change browser, and the local record is gone even though the server has not changed at all. From your side the mailbox has vanished; from the server’s side nothing happened.
What lives on the mailbox server is the mail: the headers, the body, the code, the attachments. It is remote, it is governed by whatever window the operator enforces, and it has no idea who you are. Deleting the browser’s copy does not delete the server’s copy, and clearing the server’s copy at the end of the window does not need the browser’s permission.
Keeping the two apart explains a whole family of behaviours. Why does an inbox reappear when you paste the address into another tab? Because the server still holds the message and the new tab simply started reading it. Why does an address that looks identical sometimes show an empty inbox? Because the window closed, or the label is not one the server has mail for. Why can two people see the same inbox? Because a shared, unregistered name is not a secret; whoever watches that label sees what lands.
What “expired” actually means
Expired does not mean the address was wrong or that the site is broken. It means one of the two stores no longer has anything to give you, and the shape of what you see tells you which.
The first case is server expiry: the messages have been deleted. The inbox is empty not because nothing arrived but because what arrived is gone. If you can still see the address and reload without error, this is the likely cause, and it is permanent for that message. There is no way to ask for it again; the only recovery is to have the sender produce a new one.
The second case is session expiry: the messages may or may not still be on the server, but your browser no longer knows which address to ask about. You have lost the pointer, not necessarily the data. If you recorded the address somewhere, pasting it back can still work while the retention window is open. If you did not, the pointer is gone and the practical result is the same.
A third case is often mistaken for expiry but is not: the sender refused to deliver in the first place. Some sites decline mail to disposable domains, so nothing ever arrives and waiting will not help. That failure is instant from the inbox’s point of view, and it is different from a message that arrived and aged out.
Telling these apart matters because the responses differ. Expired on the server: ask for a new message. Lost session: find the address. Blocked sender: use a different kind of address.
How to keep something longer
The honest answer is that you cannot keep a temporary message longer inside the temporary system. The window is not a setting you can change; it belongs to the server, not to the page. What you can change is where the content lives after you read it.
Read it early. A message found in the first minute of its window gives you the most room to act. If a code is what you need, use it immediately rather than saving it for later in the flow.
Move it out by hand. If the content is a confirmation number, an order reference or a link you will need again, copy the text into your own notes or into a mailbox you control while it is on screen. This is a manual step precisely because the temporary inbox has no export and no archive. It is designed to let go, so the coping strategy is to take what you need before it does.
Choose the right kind of address first. A disposable inbox is the correct tool for a one-time confirmation and the wrong one for anything durable. If what you are receiving has lasting value, it belongs in a mailbox you control. An alias that forwards to your real inbox is a middle ground: it keeps the throwaway feel for the sender and the durability for you.
For a code, act the moment it lands. The sender’s expiry is running too, so the shortest path from seeing the code to submitting it is the safest. Do not refresh a page that might regenerate your address unless you have already recorded what you need.
Why the window is short on purpose
A short window is not thrift for its own sake; it is the mechanism that makes the whole thing work. The promise of a disposable address is that it is untraceable and unaccountable, and both of those promises depend on it not holding anything for long.
Consider what would be required to keep mail for months. There would be a database to secure, a backup to rotate, a data-protection policy to honour and a support process for people asking to see mail they can no longer reach. Each of those is an obligation to the person whose mail it is, and none of them can be met by a service that does not know who its users are. The short window is what lets an anonymous mailbox exist at all.
The brevity also sets expectations honestly. A verification flow assumes a code arrives in seconds and is used in minutes, and a retention window matched to that rhythm keeps the two halves in step. A mailbox that held messages for a week would invite people to rely on it as storage, which is exactly the role it is not built to fill and the role that would demand everything else.
Seen this way, expiry is not a limitation to work around but the shape of the tool. The address is meant to be spent, not kept. The right response is not to fight the window but to use the mailbox for what it is good at, and to put anything that needs a longer life somewhere built to give it one. When you need an address for a specific errand, the temporary mailbox issues one immediately. When you are still choosing, the difference between a durable and a disposable address is spelled out in how temporary mail works, and the question of which address fits which signup is covered in which email address to use for signups.