How long should a temp email last? 5, 10, 30 minutes compared

Duration looks like a minor setting. You pick a number, the inbox opens, mail arrives, done. But the duration determines whether your verification code arrives in time, how long someone who guesses the address can read it, and whether the inbox feels appropriately temporary or starts to collect follow-up mail. Each number reflects a different set of assumptions about the task at hand. This guide works through those assumptions carefully.

What the clock is actually measuring

The timer on a temporary inbox starts at inbox creation — when you open the page and the address is generated. It does not start when mail arrives. It does not pause while you're reading. It runs continuously from the moment the address exists.

This matters because the time between "inbox created" and "verification mail arrives" is not in your control. The sending path has its own latency: application processing, transactional provider queue, SMTP delivery, ingest. On a fast sender, this takes fifteen to forty seconds. On a slow or throttled sender, it takes two to five minutes. In unusual cases, longer.

A five-minute inbox that loses three minutes to delivery latency leaves you two minutes to act on the code. A thirty-minute inbox loses the same three minutes but leaves twenty-seven. The cost of choosing a short window is not that the inbox is "more temporary" — it's that you're betting the sender is fast.

Five-minute inboxes

Five minutes is a rational window for one specific situation: an OTP flow where the sending path is known to be fast. If you've used a site before and observed that their verification emails arrive within thirty seconds, a five-minute window is adequate margin. For anything where the sender's speed is unknown, five minutes is risky.

The benefit of a shorter window is reduced exposure. An address that exists for five minutes is available to be read by anyone who knows it for five minutes. An address that exists for thirty minutes is available for thirty minutes. For high-entropy random addresses, this difference is mostly theoretical — enumeration within five minutes is not practical. But it's a real consideration on services with predictable address formats or shared short namespaces.

Five-minute mail tools are built around the assumption that speed matters more than buffer. If you're in a flow where you can watch the inbox the moment you submit the form, and the site's mail is historically fast, the tradeoff is reasonable. If you get interrupted between submitting the form and checking the inbox, five minutes is unforgiving.

Failure mode: the code arrives at four minutes and fifty seconds. You open it. The link or code has a five-minute server-side validity window counting from generation time, not delivery time. The code is already expired before you act on it. This sequence is not common, but it happens with tightly windowed senders. Five-minute inboxes amplify this risk.

Ten-minute inboxes

Ten minutes became the cultural baseline for temporary email primarily because of the longevity and visibility of ten-minute-mail.com, which launched in 2005 and defined user expectations for years. Most people, when they picture a throwaway email tool, picture a ten-minute window. This is a familiarity effect, not an optimization.

Ten minutes is adequate for well-configured senders in normal conditions. The typical transactional email takes under two minutes end to end, leaving eight minutes of margin. That's enough for most verification flows.

It becomes tight in specific scenarios. If the sender uses a shared IP pool that's throttled due to another customer's complaint rate, the initial delivery attempt may fail and the retry happens two to three minutes later. Now you're at five or six minutes into the clock. If the verification link has a five-minute validity window from generation time, you're already close to the edge. If you were briefly distracted when the form submitted, the margin gets tighter still.

Ten-minute mail works reliably for most fast senders. It's a reasonable default if you're attentive and the sender has a track record of quick delivery. The argument for thirty minutes is not that ten is wrong — it's that the cost of being wrong is losing the verification attempt and starting over, while the benefit of the shorter window is minimal for random-string addresses.

Thirty-minute inboxes

A thirty-minute window absorbs realistic delivery variability without requiring you to monitor the form submission in real time. If the sender queues slowly, you have margin. If you step away for a few minutes between submitting and checking, you have margin. If the code has a five-minute validity window, you'll still receive it with time to act.

Thirtel uses a fixed thirty-minute TTL, set at write time via Workers KV's expirationTtl parameter. The value is 1800 seconds. Cloudflare's infrastructure handles deletion automatically when the TTL expires — there's no scheduled cleanup job, no cron that might fall behind under load. The address simply stops existing.

The tradeoff is that the address is live for longer. Thirty minutes of potential exposure is more than five or ten. For random-string addresses on a catch-all domain, this rarely matters in practice — no one is enumerating random strings at a rate that makes exposure window a meaningful attack surface. For services where someone already knows your Thirtel address — because you gave it to them, or because an attacker has observed it somehow — a shorter window reduces the window for observation. In practice, if someone has your temporary address, the verification flow you're completing is your immediate concern, not the remaining window afterward.

Thirty minutes is the point at which the "this is temporary" expectation still holds clearly. An hour starts to feel like an extended session rather than a quick verification. A day starts to collect follow-up mail and loses the feel of disposable entirely. Thirty minutes sits on the right side of that line. 30-minute email explores this window specifically and the situations where it fits best.

Longer windows — one hour, twenty-four hours

Some services offer configurable TTLs, including one hour, four hours, or a full day. These longer windows are marketed as flexibility. They often produce problems instead.

An inbox that lives for twenty-four hours starts receiving follow-up mail. A welcome email arrives. A "getting started" sequence fires. Two promotional messages land. The inbox becomes crowded, and the specific message you needed is buried. The product's clarity — one address, one message, done — is gone.

More significantly, a twenty-four-hour inbox can start to feel like a real address. Users sometimes use it for multiple signups during that day. Now there's an informal identity attached to the address — but with no way to recover it after the day ends. A week later, they've lost access to everything registered under it. This is a predictable failure pattern with long-window disposable services.

The signal that a window is too long: the inbox starts receiving more than two or three messages for the task you intended it for. At that point, a secondary email account would have been more appropriate and is worth using going forward for that particular relationship.

Decision table: match duration to task

Fixed TTL vs inactivity-based expiry

Two distinct approaches exist for managing inbox expiry. They make different promises and produce different failure modes.

Fixed TTL sets a hard expiry time at inbox creation. Thirty minutes from creation, the address is gone, regardless of what happens during that window. Thirtel uses this approach. The advantage is predictability: both the user and the infrastructure know exactly when expiry occurs. The KV record's expirationTtl is set at write time. There is no process that needs to track activity or extend expiry. The system is simpler and the promise is clear.

The limitation of fixed TTL is that there's no extension. If you're partway through a verification flow at twenty-eight minutes, the inbox expires in two minutes. You cannot extend it. You need to open a new inbox and re-register. This is an edge case in practice — thirty minutes is generous — but it's a real property of the design.

Inactivity-based expiry resets the countdown when a new message arrives or when the user reads the inbox. The inbox lives as long as there's activity. This sounds user-friendly. It creates two problems.

First, the expiry time becomes uncertain. You open an inbox, submit a form, the code arrives, you act on it. The inbox now has recent activity. How long will it stay open? The answer depends on when the last message arrived and the service's inactivity threshold — which is often not prominently displayed. Users routinely forget they still have an active inbox from hours ago.

Second, ongoing mail extends the inbox. A welcome email lands at minute five. A follow-up at minute twenty. Another at minute forty. Each resets the inactivity clock. The inbox that was supposed to last ten minutes is still alive at an hour, receiving mail the user no longer expects. This is the opposite of the "temporary" property. It's a secondary inbox with an unpredictable lifespan.

Fixed TTL is the more honest design. It is also the correct one for an inbox meant to handle a single verification task. Inactivity-based expiry is better suited to a more general purpose session inbox — which is a different product with different expectations.

How Thirtel implements expiry

When an inbound message is received and parsed, the Worker calls kv.put(key, value, { expirationTtl: 1800 }). Cloudflare's KV infrastructure handles deletion at the expiry time. The address remains valid for the full thirty minutes from inbox creation regardless of whether messages arrive or not — the countdown is on the inbox, not on individual messages.

A visible countdown in the browser shows the remaining window. This is not cosmetic. It is the single most useful piece of information for managing a verification flow: knowing how much time you have left tells you whether to proceed normally or start over with a new address.

After the TTL expires, the KV namespace no longer contains the inbox record. Any mail that arrives after that point cannot be written — the put either targets a namespace entry that no longer exists or writes a new record with no reader attached to it. There is no message queue waiting to drain. Late-arriving mail is simply discarded at the storage step.

The right frame for choosing duration

Duration is not a security parameter in any meaningful sense for a receive-only inbox — you cannot act on mail in a Thirtel inbox unless you're the one watching the browser tab. It is primarily a reliability parameter. A longer window increases the probability that slow senders deliver in time. A shorter window reduces the duration of inbox existence, which is a marginal privacy benefit for high-entropy addresses.

The practical choice, given these tradeoffs, is thirty minutes for general use. Five minutes for flows you're certain are instant. Nothing longer than an hour without switching to a secondary email account instead. That covers the real distribution of tasks people actually use temporary mail for.

FAQ

Related