Temp Mail, Explained Like You're Going to Build It

A temp mail address is just a regular email address that the service operator has agreed to throw away. Nothing about the protocol changes. Mail still travels over SMTP, still hits an MX record, still lands in a mailbox. The only difference is that the mailbox has a short TTL and there's no human owner protecting it with a password.

When you generate yourname@tembox.xyz and a service emails you a verification code, the sender's mail server does a DNS lookup for the MX records of tembox.xyz, opens an SMTP connection to whichever server those records point at, and hands the message off. Our server stores it, indexes it by local-part, and serves it to your browser when you open the inbox tab.

That's it. There is no special magic. The reason temp mail feels different from Gmail is everything around the mailbox: no signup, no password, no real owner, no long-term storage. The mailbox itself is boring.

When a sender hits tembox.xyz, here is the chain of things that happen, in order:

1. The sender's outbound mail server queries DNS for MX tembox.xyz. It gets back our inbound SMTP host.
2. It opens TCP 25 to that host, does an SMTP handshake (HELO, MAIL FROM, RCPT TO, DATA), and streams the message bytes.
3. Our SMTP daemon validates that the recipient's local-part is well-formed, accepts the message, and writes it to a local queue.
4. A worker process reads the queue, parses the RFC 5322 headers, pulls out the From / To / Subject / Date fields, extracts the HTML and plain-text bodies, decodes any quoted-printable or base64 transfer encoding, and stores the result keyed by recipient + message-id.
5. The browser, which has the inbox view open, is polling our API every few seconds. It asks "any new messages for yourname?" The API returns the new envelopes and the browser renders them.
6. A cleanup job runs hourly and deletes any messages older than 48 hours, plus any local-parts that haven't been read in 48 hours.

The HTML rendering happens in your browser, inside a sandboxed iframe with a strict Content-Security-Policy that blocks scripts, forbids form submissions, and rewrites tracking pixels. This is the part most temp mail services skip — which is why their rendering looks broken on anything more elaborate than a plain text receipt.

The honest rule of thumb: use temp mail when the value of what you're signing up for is less than the cost of the spam you would receive forever afterwards. That covers a surprising amount of the modern web.

A walled-off article that wants an email before you can read it. A "free PDF" that's actually a 90-day drip campaign. A SaaS trial you'll know within five minutes isn't for you. A forum you want to post on twice and never again. A discount code that requires an email subscription that you will then resent for the next two years. These are all places I personally use temp mail.

Developers and QA engineers use it for a different reason: testing. If you're building a signup flow you need to test with real email addresses — addresses that actually receive mail, not just "test+1@example.com" which most providers correctly reject as not deliverable. Temp mail gives you unlimited valid mailboxes with no state from previous test runs. That makes regression testing for password reset, verification, and transactional notifications dramatically easier.

I built the original version of Tembox because I was running this kind of testing for another project and getting frustrated with the alternatives. They were slow, the HTML rendering was broken, and they expired faster than my test suite ran. The 48 hour window on Tembox isn't arbitrary — it matches the maximum time I'd ever expect to come back to a one-off verification email.

Most temp mail services were built before 2015 and the codebases show it. The common problems I tried to fix when building Tembox:

• Broken HTML. Older services strip styles or render emails as plain text, which makes any verification email with a styled button basically unreadable. Tembox renders the full HTML in a sandboxed iframe with images, layout, and inline CSS intact.
• 10-minute expiries. A sane retention window is hours, not minutes. Many verification emails are sent on a delay. Tembox holds messages for 48 hours so you can come back the next morning.
• Manual refresh. You should not have to keep hitting F5 to see if your code arrived. The Tembox inbox view polls the API in the background and renders new messages as they land, with a subtle animation so you notice.
• Ad-stuffed UI. Some services have more ads than content. Tembox aims to keep the UI clean. If we ever run ads, they will be confined to a single side rail, never inside the inbox view.
• No mobile layout. On most temp mail sites, the inbox is unusable on a phone. Tembox is built mobile-first.

Temp mail addresses are public. Anyone who guesses or knows the local-part can open the inbox and read everything in it. That is not a flaw — it is the cost of getting an inbox with zero signup friction. There's no authentication system because there's no account.

In practice this means two things. One: never use a temp mail address for anything you wouldn't want a stranger to see. Two: pick a random or hard-to-guess local-part for anything where that matters. The default randomly generated addresses on Tembox are 24 characters of mixed case and digits, which is effectively uncrackable for the 48-hour window in which the address exists.

On the server side, we don't log message bodies, we don't store anything past the 48-hour deletion window, and we don't require any identifying information. Your IP is in the standard nginx access log for security and rate-limiting purposes and rotates out within 14 days. That's the entire data trail.