A temporary email address sounds almost too simple to be a software project: generate a random string, accept some email, show it in a browser, and delete everything ten minutes later.
Then you start asking questions.
Who is allowed to read the messages? What happens when mail arrives at the exact moment the inbox expires? Where do attachments live? How do you delete the underlying data instead of just hiding the UI?
Suddenly it's a neat little systems-design exercise.
Start with a constraint: receive-only
The first architectural decision I would make is not to build a miniature Gmail.
A receive-only service needs to accept and display inbound messages. It doesn't need compose, reply, forwarding, or outbound SMTP.
Every extra feature introduces operational and abuse risks that the core use case doesn't need.
That's how 10 Minute Temp Email is designed: it handles short-lived inbound messages, but doesn't let users send or reply.
Split mail processing from the website
One useful real-world reference is the site's published Cloudflare architecture:
Browser
|
v
Web Worker ------> D1: metadata
|
v
Inbox UI
Email Routing
|
v
Mail Ingest Worker
|
+-------------> D1: metadata
|
+-------------> R2: message bodies
The web side creates a mailbox and exposes authenticated read/delete operations.
The ingest Worker receives incoming mail through Cloudflare Email Routing, checks that the address is valid, parses the message, and stores the permitted content.
Separating those responsibilities makes the design easier to reason about. A normal page request should never have to process a raw MIME message.
Expiration has to be enforced by the server
A countdown in JavaScript is useful feedback, but it is not your security boundary.
If the browser says an inbox has expired, your API must still reject further reads.
If a message is delivered to an expired address, the ingest side must not quietly accept it just because the browser is no longer watching.
A reasonable data model keeps an expires_at timestamp for each mailbox.
Every read and ingest operation checks that timestamp against server time. A scheduled cleanup process then removes database records and stored message objects.
This distinction matters: access expiration and physical cleanup are related, but not the same operation.
Your session is the mailbox key
Making the generated email address the only secret would be a mistake.
Addresses are visible to the services that send mail and could appear in logs.
The safer pattern is to bind a mailbox to a browser session.
In this example project, an HttpOnly cookie proves ownership, while an HMAC hash of the session token is stored in D1.
That way, knowing someone's temporary address isn't enough to open their inbox.
It's also why opening the same email address in a different browser won't magically give you access to its messages.
The failure paths are the interesting part
Think about these cases before writing the happy-path UI:
- An email arrives seconds after expiration.
- The object store succeeds, but the database insert fails.
- The same message is delivered twice.
- Someone guesses random inbox addresses.
- A user tries to download an attachment from another session.
A robust implementation needs consistent checks, rollback or compensating cleanup, deduplication, and authorization on every attachment fetch.
The useful takeaway
Tiny products can contain serious engineering lessons.
A ten-minute inbox combines event-driven processing, ephemeral storage, authentication, cleanup, and untrusted content handling in a compact system.
If you're curious about the exact components used by this particular service, its creator has documented the receive-only inbox architecture.
If you were building one, which part would you prototype first: ingest, session security, or expiration?
Top comments (0)