How MailboxTemp works
This page describes the real system behind the inbox — not a marketing diagram. It's written by the people who operate it, and everything below matches how the service actually behaves in production, including the parts that are limitations rather than features.
The short version
MailboxTemp runs its own inbound mail server. When you load the site you get a randomly generated address on one of our domains; any message sent to that address is accepted by our mail server, parsed, stored, and pushed to your browser in real time. A cleanup process permanently deletes the inbox and everything in it when its timer expires. The service is receive-only: no message can ever be sent from a MailboxTemp address.
Step by step: from page load to deleted inbox
- Address generation. The moment the page loads, the API creates an address with a random 7-character local part (letters and digits, e.g.
k3x91qa) on one of the active domains in our pool. The inbox record is stored with an expiry timestamp — 60 minutes for free inboxes, extendable in 10-minute steps; 24 hours on the Pro plan. Your browser remembers the address locally so a page refresh doesn't lose it. - Mail intake (SMTP). Each domain's MX record points at our mail server, which speaks standard SMTP as defined in RFC 5321 and supports STARTTLS for encrypted delivery from the sending server. It accepts a message only if the recipient address matches a live, unexpired inbox — mail to expired or never-created addresses is rejected during the SMTP conversation with a "mailbox not found or expired" response. Messages over 10 MB are refused.
- Parsing and code detection. Accepted messages go onto an internal queue, where a worker process parses the raw message (headers, text and HTML bodies, attachments — the format defined in RFC 5322). The worker also scans the message for one-time verification codes; when it finds one, the code is stored alongside the message so the inbox can show it at the top for one-tap copying.
- Storage. Parsed messages are stored in a database and attachments in separate object storage, each stamped with the same expiry as their inbox. HTML bodies are sanitized before display so a message can't run scripts in your browser.
- Real-time delivery to your browser. The open inbox page holds a WebSocket connection to our server. When the worker stores a new message it publishes an event, and the message appears in your inbox within a second or two of arrival — no refresh, no polling.
- Expiry and deletion. A purge job runs every 5 minutes. It first deletes attachment files from object storage, then deletes the expired messages and inboxes from the database. After a purge pass there is no copy of the content left to restore — expired mail is genuinely unrecoverable, by us included. See can you recover a temp mail? for the full explanation.
The privacy model — read this part
Free MailboxTemp inboxes have no password and no account. The address itself is the only key: anyone who knows the exact address while it is live can open that inbox. Random 7-character addresses are hard to guess (about 78 billion combinations), but if you paste your temporary address somewhere public, the inbox behind it is effectively public too.
Practical consequences, stated plainly:
- Treat a temporary inbox as unlisted, not confidential. It hides your identity from the sender; it is not a vault.
- Never receive anything at a temporary address that would hurt you if someone else read it — password resets for real accounts, financial documents, medical information. Our safety guide covers this in detail.
- We keep standard server logs (including IP addresses) for rate limiting and abuse prevention, as described in the privacy policy. We do not require or store any identity information for free use.
Why receive-only?
MailboxTemp deliberately has no outbound mail capability — there is no "compose" feature, no reply, no forwarding, and no SMTP submission service. That single design decision removes the main way disposable-email systems get abused: nobody can use a MailboxTemp address to send spam, phishing, or harassment. It also means our domains exist purely to receive, which keeps the service simple and auditable.
Known limitations
| Limitation | Why it exists |
|---|---|
| Some sites reject our domains | Many services block known disposable-email domains at signup. We rotate the domain pool, but there is no guarantee a given site will accept a temporary address — and we don't attempt to disguise our domains as permanent providers. |
| Expired mail is gone forever | Deletion is the product. The purge job removes content permanently; there are no backups of expired inboxes to restore from. |
| No sending, ever | Receive-only by design, to prevent abuse (see above). |
| 10 MB message cap | Large messages are refused at the mail server. That covers virtually all verification and notification mail; it is not built for big file transfer. |
| Inbox lists the 50 most recent messages | A practical cap for a short-lived inbox; older messages beyond 50 are not shown via the API. |
| Not for accounts you'll need later | Once the inbox expires, password resets and future notifications for anything registered with it are unreachable. Use a real address for anything long-term. |
Build on it
Everything the inbox page does happens through a public HTTP API — creating inboxes, listing messages, reading a message with its auto-detected code. Developers use it for automated email-verification and OTP testing. The full reference, including rate limits and error codes, is at /docs.