Temporary mail works by borrowing a mechanism that every address on the internet already uses, and then removing the parts that make a mailbox permanent. Nothing about the message changes; what changes is where it lands and how long it stays. Understanding the two halves of an address and the trip a message makes explains most of the behaviour that surprises people, including the fact that a message can arrive twice and a temporary address always dies.
The two halves of every address
An address is split by the at sign into a local part and a domain. The local part is the label the receiving system uses to decide which mailbox the message belongs to. The domain is the part that belongs to an organisation, and it is the part the wider mail system knows how to find.
Everything before the at sign is up to the receiving service, so a temporary mailbox can hand you any label it likes without asking anybody’s permission. The domain is the part that has to be real, because the sender’s side has to be able to look it up. That asymmetry is why disposable services give you addresses on their own domains rather than inventing new ones.
The delivery path, step by step
The order of events is fixed, and each step is a place where a message can be delayed or dropped.
- Something triggers a message — a signup form, a password reset, an order event.
- The sending system looks up the domain of the recipient and asks which server accepts mail for it.
- That server is contacted and offered the message.
- The receiving server decides whether to accept it, and stores it if it does.
- Your client, or the page you are looking at, later reads whatever was stored.
The middle step is the one people forget. A domain has to publish a record that names its receiving mail server; without it, mail for that domain has nowhere to go and the sender gives up. The mechanism is standardised in the IETF’s transport specification, RFC 5321, which is also where the rule that delivery is asynchronous comes from. A sender hands a message over and moves on; it does not wait for you to log in.
Why does a temporary address expire?
Because nothing in the chain promises otherwise. A permanent mailbox is a service somebody operates on your behalf for as long as you keep the account. A temporary mailbox is the opposite arrangement: it is scoped to a session or a short window, and when that scope ends, the stored messages are deleted.
Expiry is not a defect that a better provider would fix. It is the feature. The reason a disposable address is cheap, unregistered and free of passwords is that it is not designed to be durable. Once the window closes there is no recovery path, no support queue and no archive to search.
That also explains a common complaint about codes that “stop working”. A verification code sent to a temporary address has its own short lifetime on the sending side as well; if the inbox and the code both expire, the only way forward is to start the flow again with a fresh address.
Is a slow message a lost one?
Usually not, and this is the distinction that separates a working integration from a flaky one. Mail delivery is asynchronous, so a message can take a moment or considerably longer to appear. Duplicate delivery is also normal rather than exceptional: the same message may arrive twice, and a receiving system that treats the second copy as an error is fighting the transport instead of using it.
The practical response is patience with a ceiling. Look for the message until it appears or until your limit is reached, and treat the limit expiring as a result in itself rather than as a reason to wait forever.
What the mailbox page here does
The temp mail tool gives you an address on one of its mail domains, keeps what arrives in an inbox on the page, and lets you throw the address away and take another. Because the address is not registered anywhere, a fresh one is genuinely fresh: no earlier messages, no shared history, nothing to explain.
That is useful precisely because it is shallow. A mailbox you can replace at any moment is the right tool for receiving a confirmation, and the wrong tool for anything you would be upset to lose. If you are still deciding which kind of address you want, what a disposable email address is covers the difference in plain terms.
An address produced here belongs to the errand that needed it and to no one at all. It is a test fixture, kept for the testing purpose only, and it must never be copied into a profile, a mailing list or any register of genuine people.
For developers: polling, retries and isolated addresses
Three decisions shape whether mail-based tests are stable.
The first is the polling interval and the ceiling. Choose an interval short enough that the suite is not idle and a ceiling long enough that ordinary latency never trips it; then make the timeout failure loud, with the message that was expected and the window that was waited, so that the next person knows what happened.
The second is address isolation. A unique address per case removes the single largest source of false positives, because the message you find can only have come from the case you are running. Reusing one address across cases invites stale mail to satisfy an assertion it does not belong to.
The third is tolerance for repetition. Because duplicates arrive, assertions should be built on the presence and content of a matching message rather than on the count of messages. A suite that fails the first time a message is delivered twice is a suite that will fail in production conditions.
The flow testing article goes further into what the verification path itself should be asked to prove.
Next steps
If a message is not showing up, check the two likeliest causes before anything else: an address that expired while you were reading something else, and a code that expired on the sender’s side. Then open the temp mail page and start the flow again with a clean address rather than trying to rescue the old one.