If you have used a temporary email address before, the experience raises an obvious question. You never signed up. Nobody created a mailbox for you. So how does a verification code from a real company arrive in a browser tab seconds later?
The answer is that the interesting part happens one level higher than most people assume. Mail is not accepted because your address exists. It is accepted because the domain accepts everything.
The short version
A temp mail service owns a domain, tells the internet that one specific server handles mail for it, and configures that server to say yes to every address on the domain. When a message arrives, the server parses it, stores it against whatever address it was addressed to, and your browser asks for anything matching the address you were handed. A timer deletes it all later.
Six stages, in order. Each one is worth understanding, because the differences between a trustworthy service and a careless one live in the details.
Stage 1: DNS tells senders where to deliver
Email routing starts with a DNS lookup. When a sending server wants to deliver to anything@example.com, it does not look up your address. It asks DNS a narrower question: which mail server is responsible for example.com?
The answer comes from the domain's MX records — mail exchange records — which list the hostnames that accept mail for that domain, each with a priority number so senders know which to try first. If a domain has no MX records, delivery fails immediately and every address on it bounces.
This is the first thing that separates a working disposable address from a genuinely fake one. A fake address is a string that looks like an email and has nothing behind it. A temp mail address sits on a domain with live MX records and a server standing ready. That distinction is why verification mail actually arrives instead of bouncing, and it is the single most misunderstood thing about the category.
Stage 2: A catch-all rule accepts every address
Normally a mail server keeps a list of the mailboxes it knows about and rejects anything else with a "no such user" error. Temp mail inverts that. The server runs a catch-all rule: any address at the domain is accepted, whether or not it has ever been seen before.
That is the whole trick. There is no moment of registration because registration was never required. Generating an address is a purely local act — the service picks a random string, shows it to you, and the mail server was already willing to accept it.
A catch-all has an obvious side effect: the domain will happily receive mail for addresses nobody ever generated, including the enormous volume of spam sent to guessed addresses. A careful service therefore checks whether an inbox was actually issued before storing anything, and rejects the rest. Otherwise the database fills with mail addressed to nobody.
Stage 3: The raw message gets parsed
What arrives over SMTP is not a tidy object with a subject and a body. It is a raw MIME message: a block of headers followed by one or more body parts, frequently a plain-text version and an HTML version of the same content, plus any attachments, all encoded and separated by boundary markers.
Something has to turn that into structured data. A parser extracts:
- The sender, taken from the message headers
- The recipient, which determines whose inbox this belongs to
- The subject line, decoded from whatever character encoding it used
- The plain-text body, the HTML body, or both
- Timestamps and any attachments
The HTML body deserves particular caution, because it is untrusted content from a stranger that is about to be displayed in your browser. Marketing email is full of remote images, tracking pixels, and occasionally scripts. A responsible service strips active content on the way in and renders the result inside a sandboxed frame that cannot execute scripts at all, so that a gap in the first defence does not become an attack on you. Relying on text filtering alone is a mistake, because untrusted HTML can always be written to slip past a pattern match.
Stage 4: The message is stored
Here is the part people find surprising, so it is worth stating plainly: to show you a message, a temp mail service has to store it. There is no version of this where mail appears on your screen without having been written down somewhere first.
Any service claiming it keeps nothing at all is either being loose with words or does not understand its own architecture. The honest claim is narrower and more useful: messages are stored for a short, bounded period, are not analysed or sold, and are deleted automatically. Our own privacy policy says exactly that, and it took a correction to get the wording right.
Stage 5: Your browser asks for new mail
Your browser cannot speak SMTP, and mail servers cannot push into a web page unprompted. So the page asks. Every few seconds it calls the service's API with your address and receives a list of anything waiting.
That polling interval is why a message shows up a moment after it was sent rather than instantly. A few seconds is imperceptible when you are waiting for a login code, so most services choose polling over the extra complexity of a persistent connection.
One implementation detail matters a lot here, and it is where weaker services go wrong. If the only thing required to read an inbox is knowing its address, then the address is a password — and a bad one, because it is pasted into forms and sometimes displayed publicly. A safer design issues a private token when the address is created and requires it on every read, so that guessing an address gets an attacker nothing.
Stage 6: A timer deletes everything
A scheduled job runs periodically and removes messages older than the retention window, along with inbox records that have expired. This is what makes the service temporary rather than simply free.
It also means retention is a range, not a precise figure. If the policy is two hours and cleanup runs hourly, a message can live anywhere from two to three hours depending on when it arrived relative to the last run. Any service quoting an exact lifetime to the minute is describing a countdown in the interface, not the moment data leaves the database.
Why the address is real but not yours
Putting it together: the address is technically indistinguishable from a normal one at the point of delivery. It resolves, it accepts, it delivers. What differs is everything around it — no registration, no identity, no long-term storage, no ability to send.
That last point catches people out. Receiving mail requires a server willing to accept it. Sending mail credibly requires authentication, a reputation, and SPF, DKIM, and DMARC records that vouch for you. Disposable services deliberately skip all of that, which is why temp mail is receive-only. It is not an oversight; a service that let anonymous strangers send mail from its domain would be a spam relay within hours and would lose the deliverability its users depend on.
What separates a good implementation from a careless one
Every service follows roughly the six stages above. The differences that actually affect you are narrower:
| Aspect | Careful design | Careless design |
|---|---|---|
| Address entropy | Cryptographic randomness over a large keyspace | Short or predictable suffixes, so addresses can be walked |
| Read access | Private token required on every request | Anyone who knows the address can read it |
| HTML handling | Sanitised, then rendered without script execution | Filtered by pattern matching alone |
| Unknown recipients | Rejected, so the database holds only issued inboxes | Stored, so guessed-address spam accumulates |
| Retention | Stated as a range and enforced automatically | Vague, or claims nothing is stored at all |
Worth knowing: some services deliberately expose public inboxes where anyone can type an address and read whatever is in it. That is a legitimate design for throwaway curiosity and a serious hazard for verification codes. If you cannot tell which kind you are using, assume the inbox is public.
What temp mail cannot do
- Send mail. Receive-only, for the deliverability reasons above.
- Store anything long term. The deletion timer is the product, not a limitation to work around.
- Recover an inbox you have lost. If access depends on a token held in your browser and you clear it, there is no reset flow — nobody knows the inbox was yours.
- Get past every signup form. Some sites reject disposable domains outright, which is a whole topic of its own — see why websites block disposable email.
Frequently asked questions
If nobody registered the address, how does mail reach it?
Because acceptance happens at the domain level, not the address level. The domain publishes MX records pointing at a mail server, and that server is configured to accept every address on the domain rather than a fixed list. The sending server never asks whether one specific mailbox was created — it only asks which server handles mail for the domain.
Is a temporary address a real email address?
Yes. It resolves through the same DNS and SMTP path as any other address and it genuinely accepts mail. What makes it temporary is policy, not plumbing: the service deletes messages on a schedule and the address is meant to be abandoned rather than kept.
Why does the inbox refresh instead of pushing new mail instantly?
Browsers cannot receive SMTP directly, so the page has to ask the server whether anything new has arrived. Most services poll every few seconds, which is why a message appears a moment after it was sent rather than the instant it lands. A websocket connection could push instead, but polling is simpler and more than fast enough for verification codes.
Can two people be given the same temporary address?
Only if the service generates addresses from a small pool. A well-built service draws the random part of the address from a cryptographic random source over a large keyspace, which makes a collision effectively impossible. Services using short numeric suffixes or predictable patterns can and do hand out repeats.
What happens to a message after it is deleted?
The row holding the message is removed from the database. The service no longer has the subject, body, or sender, and there is nothing left to hand over or to leak. Anything you needed from the message has to be acted on before that cleanup runs.
Where to go next
If you want the plain-language version rather than the mechanics, start with what temp mail is. For the practical walkthrough, read how to use temp mail. And if the question on your mind is whether any of this is a good idea, we answer it directly in is temp mail safe and legal?