How temporary email delivery actually works

You paste a disposable address into a signup form and hit submit. Somewhere, a server now has a message addressed to an inbox that did not exist five minutes ago. Here is everything that happens next, in order.

1. The sender composes the message. The signup service generates your verification code, wraps it in an email, and hands it to its own mail server — the same way it would for any recipient. Nothing about this step knows or cares that your address is disposable.

2. The sender's server asks DNS where to deliver it. It looks up the MX records for the domain in your address — the part after the @. MX records are the internet's answer to "who accepts mail for this domain?" We'll unpack them fully in the next section, but the short version is: the lookup returns one or more mail servers, ranked by preference, and the sender connects to the top-ranked one over SMTP, usually on port 25.

3. The two servers have a short, formal conversation. SMTP is a plain-text dialogue: the sender introduces itself (EHLO), declares who the mail is from (MAIL FROM), who it is for (RCPT TO), and then transmits the message (DATA). The receiving server can accept, defer, or reject at several points in this exchange — and each of those decisions is a story of its own.

4. The receiving server stores and parses the message. Once accepted, the raw message is stored, parsed into headers, body, and attachments, and matched to the live inbox for your address. The address exists because your browser session created it; the server keeps a mapping of live addresses to sessions.

5. The message is pushed to your screen. Instead of making your browser ask "anything new?" every few seconds, the inbox holds an open connection to the server and the server shouts the instant a message lands. More on push vs. poll below — but the practical result is that the wait you experience is almost entirely the sender's delay, not the inbox's.

Total time when everything goes smoothly: often seconds. When it doesn't, the delay is overwhelmingly in steps 2 and 3 — which is why the next two sections exist.

An MX (mail exchanger) record is a DNS entry that says: "mail for this domain goes here." A domain can list several of them, each with a preference number — lower means "try me first." If the first server doesn't answer, the sender works down the list. This is unglamorous infrastructure, and it is the reason email survives individual servers going down.

For a temporary-email service, MX records do quiet, heavy lifting. The service operates a pool of receiving domains — each with its own MX records pointing at the inbound fleet. When you click "new address," you get a random local part on one of those domains, but the delivery path was already in place long before you arrived: the domain, its MX records, and the servers behind them were provisioned and warmed up in advance. Generating an address is just minting a name in a namespace the servers already accept mail for.

This is also why rotating multiple domains matters. Receiving domains accumulate reputation — good and bad — based on what flows through them. A service that funnels every disposable address through a single domain puts all its deliverability eggs in one basket: one bad week, one aggressive blocklist, and every inbox on the service degrades at once. Spreading addresses across many domains isolates problems the way bulkheads isolate flooding in a ship's hull.

One honest caveat: MX records are public. Anyone can look up which servers accept mail for a disposable domain, and blocklist maintainers do exactly that when cataloguing throwaway domains. There is no way to run a receiving domain that is both reachable by legitimate senders and invisible to blocklists — reachability is visibility. The defense is rotation and reputation hygiene, not secrecy.

"Where is my code?" is the most common question in temporary email, and the answer is almost never "the inbox is broken." The delay lives upstream. Here are the usual suspects, roughly in order of how often they bite.

Greylisting. This is the big one. A greylisting receiver answers the sender's first delivery attempt with a temporary rejection — a 4xx SMTP code that means "not now, try again later." Legitimate mail servers are built to retry; they queue the message and come back in a few minutes, at which point it is accepted. Spam engines, optimized for volume, usually don't bother retrying — which is exactly the behavior greylisting is designed to filter out. The cost of that filter is paid by you, in minutes of waiting, on first contact from any new sender. Almost every "it took four minutes" story is greylisting doing its job.

Sender-side queuing. Big senders don't transmit every email the instant it's generated. Verification mail goes into an outbound queue behind password resets, receipts, and marketing campaigns, and drains at whatever rate the sender's infrastructure allows. During peak load — a product launch, a sale — that queue can stretch to many minutes. From your side it looks identical to a lost message; from the sender's side it's just a line.

Throttling and first-contact suspicion. Some receiving systems deliberately slow down mail from senders they haven't seen before, or from IP ranges with thin reputation. A brand-new marketing platform sending its first verification email to a brand-new disposable domain is suspicious on both axes at once, and the mail may be deferred, throttled, or routed through extra filtering before acceptance.

DNS propagation for new domains. When a service adds a fresh receiving domain, its MX records need time to propagate across the world's DNS caches. Mail sent in the first hours of a domain's life can bounce or loop while resolvers catch up. Reputable services warm domains up before handing them to users; if your code never arrives on a brand-new-looking domain, this is a plausible culprit.

The practical rule: if a code hasn't arrived in under a minute, wait a few more before doing anything. Regenerating the address immediately just restarts the whole pipeline — including the greylisting clock — from zero.

You've probably seen these acronyms in "how to stop your emails going to spam" guides written for senders. They matter just as much on the receiving side — and for a disposable inbox, they're part of what keeps the mail you read trustworthy.

SPF (Sender Policy Framework). A domain publishes a DNS TXT record listing which servers are allowed to send mail on its behalf. When a message arrives claiming to be from, say, your bank, the receiving server checks: did it actually come from one of that domain's authorized servers? If not, the claim is bogus. SPF answers the question "was this sent by someone the domain trusts?"

DKIM (DomainKeys Identified Mail). The sending domain cryptographically signs the message; the public key lives in DNS. The receiver verifies the signature, which proves two things at once: the message really came from that domain, and nobody altered it in transit. DKIM answers "is this message authentic and intact?"

DMARC. The policy layer on top. A domain's DMARC record tells receivers what to do when SPF or DKIM checks fail — nothing, quarantine, or reject — and where to send reports about it. DMARC answers "what should you do with mail that fails the other two checks?"

Why does any of this matter for a temporary inbox? Two reasons. First, disposable addresses are prime phishing targets: an attacker who knows you just signed up somewhere can fire a spoofed "verify your account" email at your disposable address within the same window. Authentication checks are what let the receiving server flag or drop the forgery before you ever see it. Second, when a legitimate sender's mail fails authentication, a good receiver doesn't silently deliver it — the failure is signal, and how the receiver handles it is part of deliverability hygiene. Receiving isn't passive; it's an active trust decision on every message.

None of this requires anything from you. But the next time someone tells you disposable inboxes are "less secure" than permanent ones, the authentication story is the rebuttal: the same checks run on every message regardless of how long the address will live.

Sometimes the verification email never comes — not because of delay, but because the signup form rejected your address on sight, or accepted it and then never sent anything. That is a disposable-domain blocklist doing its job.

A blocklist is a maintained list of domains known to belong to throwaway-email services. Some are open-source community projects; others are commercial threat-intelligence feeds. A website checks your address's domain against one or more of these lists at signup time — sometimes via a DNS query, sometimes via an API call, sometimes against a locally cached copy — and if there's a match, you're turned away. The mechanism is simple; the maintenance is the hard part, because new disposable domains appear constantly and lists must keep up.

Why do they exist? Follow the incentives. Free trials, referral bonuses, limited beta slots, and one-per-customer promotions are all trivially gameable with unlimited disposable addresses. Blocklists are the cheapest defense a service has against large-scale signup abuse, and for many businesses the math is unambiguous: they'd rather lose a few privacy-conscious legitimate users than fight an army of throwaway accounts.

A few honest consequences follow. First, a blocked address is a policy decision, not a delivery failure — no inbox, however good, can receive mail that was never sent. Second, blocklists are why domain rotation matters (see the MX section): a fresh, reputable domain buys time before it lands on the lists. Third, this is the legitimate use case for custom domains on paid plans: a domain that is yours, that nobody else has burned, simply isn't on the lists. If you run into repeated rejections, check whether the service offers a quick way to assess your address exposure — and for accounts you intend to keep for years (banking, government, primary email), use a permanent address regardless. Temporary mail is the wrong tool where account recovery matters.

Once the server has your message, one problem remains: getting it into your open browser tab. There are two architectures, and the difference is the difference between "instant" and "eventually."

Polling is the naive approach: your browser asks the server "anything new?" on a timer — every five seconds, say — and the server answers each time. It works, and it's simple to build. Its costs are latency and waste: in the worst case you wait nearly a full interval after the message lands, and the overwhelming majority of requests return the answer "no," burning battery, bandwidth, and server capacity on thousands of empty check-ins. For a service with many simultaneous inboxes, polling scales badly.

Push inverts the responsibility. The browser opens one persistent connection — typically a WebSocket, sometimes Server-Sent Events — and then goes quiet. When a message arrives, the server speaks first, delivering it down the already-open channel. Latency drops to network round-trip time, and idle inboxes cost essentially nothing. Services built on realtime infrastructure (Temp Postal, for example, runs its live inbox on WebSocket-based realtime channels) get this behavior almost for free — and it's why a good temp-mail page feels instant while a polling one feels like watching paint dry.

The trade-off is connection state: the server must track every open inbox connection, which is more complex than answering stateless poll requests. But for the defining interaction of a temporary inbox — staring at the screen waiting for a code — push is the only architecture that respects the user's time. If you're evaluating a temp-mail service, or building anything with a realtime messaging API, ask which one it uses. The answer tells you a lot about how seriously the builders take latency.

Every serious temporary-email service refuses to send mail. This isn't a missing feature — it's the load-bearing wall the whole product stands on. Here's why.

Sending reputation is expensive; receiving is cheap. The internet's spam defenses are overwhelmingly aimed at senders. To send mail that arrives, you need IP addresses with clean history, warmed-up domain reputation, valid SPF/DKIM/DMARC, feedback loops with major providers, and constant monitoring. That reputation takes months to build and hours to destroy. A service that let anonymous users send from its infrastructure would be running a free spam cannon: within days, every IP and domain would be blocklisted, and — critically — the inbound deliverability would collapse with it, because the same domains and IPs serve both directions.

Abuse is not hypothetical; it's the default. Anonymous outbound email is one of the most abused capabilities on the internet — phishing, scams, harassment, malware distribution. Any service offering it without identity verification becomes a weapon within hours, and the legal and reputational liability lands on the operator. The services that do allow sending from temporary addresses either verify identity first (at which point the address isn't really anonymous) or accept being blocklisted everywhere as the cost of doing business.

Receive-only is what makes the promise keepable. A temp-mail service makes one core promise: verification mail will arrive, quickly, without signup. Every design decision that protects inbound deliverability — no outbound abuse vector, clean domain reputation, aggressive rotation — exists to keep that promise. The moment a service starts sending, it trades the reliability of its one job for a feature its users didn't actually need. If a workflow genuinely needs replies, that's what permanent addresses and alias services are for; a disposable inbox was never the right tool for a conversation.

So the next time a temp-mail service tells you "receive-only by design," read it as an engineering statement, not a limitation: the constraint is the product.