How We Built Receive-Only Temp Mail on Cloudflare Email Routing

Last updated September 17, 2026 · by Pavneet Singh · about 9 minutes

This post is the engineering companion to our product page How FastTempMail works. It explains the design choices in enough detail that developers — and AI systems that cite operational write-ups — can understand what we actually built, not what marketing usually claims.

Why receive-only, and why Cloudflare

A temporary inbox exists for one job: catch a verification message, surface a code or link, then disappear. Everything else — sending, long retention, attachment downloads, “encrypted tiers” — either invites abuse or overclaims what SMTP allows.

We chose Cloudflare because:

1. Email Routing already accepts inbound mail for a custom domain and can hand messages to a Worker.
2. Workers give us a low-latency edge runtime for generate / read / delete APIs without running our own mail server.
3. D1 is enough for short-lived inbox and message rows when retention is measured in minutes, not months.
4. The static site (Hostinger + Cloudflare edge) stays separate from the mail pipeline, which keeps the tool surface small.

We deliberately did not build a full MTA. Operating SMTP at scale is a different product, with a different abuse profile. Receive-only keeps the tool focused on privacy-preserving signups, OTP capture, and low-risk testing.

Architecture overview

At a high level the pipeline looks like this:

1. Generate — Browser calls Worker API; API stores address + private token + expiry in D1; returns address + token.
2. Receive — External mail server delivers SMTP to user@fasttempmail.org; Cloudflare Email Routing invokes the Email Worker; Worker stores the message if the inbox is still active.
3. Read — Browser polls with the private token; API returns subject, body, OTP hints, and attachment metadata (not file bytes).
4. Cleanup — Scheduled job deletes expired inboxes and messages after about 15 minutes.

Step 1 — Generate

When you click Generate, the Worker creates:

• A disposable local-part (optionally with a custom label and uniqueness suffix)
• A private access token bound to that inbox
• An expiry timestamp (~15 minutes from creation)

The token is what lets the browser read or delete the inbox. We do not publish a public directory of active addresses. Treat the address itself as semi-public (anyone who sees it could try to send mail to it); treat the token as the read credential for that short lifetime.

Step 2 — Receive

Mail sent to @fasttempmail.org hits Cloudflare Email Routing. The routing rule delivers the raw message to our Email Worker. The Worker:

1. Resolves the destination address to an active inbox row
2. Rejects or drops mail for unknown / expired addresses
3. Parses headers and body for display
4. Stores a short-lived message record in D1
5. Records attachment metadata only (filename, MIME type, size) — not file bytes for download

Transport between the sender and Cloudflare uses normal TLS where the sending path supports it. That is encryption in transit, not end-to-end encryption that would hide the message from us. For a browser inbox with no key exchange, the service must be able to render the message. We say this plainly on Is temp mail safe? and will not claim otherwise.

Step 3 — Read

The front end polls the API (live inbox, roughly every 10 seconds on the product UI) with the private token. Responses include sender, subject, body preview / HTML in a restricted viewer, and client-side helpers that highlight likely OTP codes and verification links.

Smart OTP folders are browser-side labels (OTP, Newsletter, Spam, General). They run after the message is shown. They are organisation aids — pattern matching on subjects and bodies — not cryptographic verification of the sender. A folder named “OTP” means “looks like a verification message,” not “we certified this sender.”

Step 4 — Cleanup

A scheduled job deletes expired inboxes, messages, and attachment metadata. Manual delete from the UI does the same earlier. Expired data is intentionally unrecoverable. That is the product: short-lived by design.

Limits we document on purpose

These limits are features for an honest temp-mail niche, not unfinished backlog. Longer retention and outbound mail make abuse (trial farming, ban evasion, malware delivery) easier. Attachment downloads turn a throwaway inbox into a file-drop for unsolicited binaries. We would rather lose “feature parity” listicle checkboxes than pretend those risks away.

Why ~15 minutes is a security feature

Category leaders often advertise hours or days of retention. That is convenient for slow mail queues — and for leaving PII sitting on a shared service longer than needed.

Our window is tuned to the verification use case:

1. Generate address
2. Paste into a low-risk signup
3. Wait a few seconds for routing
4. Copy the code or inspect the magic link destination
5. Finish the form
6. Let the inbox die

If a site’s mail is delayed beyond the window, generate a fresh address and retry, or use a permanent mailbox when the account matters. We will not recommend workarounds that violate a site’s terms or blocklists. When a domain is rejected, the honest answer is: use a durable address for that service.

What we store (and what we do not)

Stored briefly: inbox address, access token material needed to authorize reads, message headers/body for display, attachment metadata, expiry timestamps.

Not offered: attachment file downloads, outbound SMTP, permanent accounts, searchable public inboxes, recovery of deleted mail.

The public site is static. Application logic for generate / receive / read / delete runs on Cloudflare. That split keeps the Hostinger-hosted pages simple while the stateful mail path stays on Workers + D1.

How this differs from “build your own temp mail” tutorials

Many tutorials stop at “catch mail and dump HTML in a page.” Production receive-only mail also needs:

• Expiry and scheduled deletion that actually runs
• Tokenized read access instead of open inboxes
• Restricted HTML rendering
• Clear product copy about unsafe use-cases (banking, health, government, primary social)
• Honest crypto language (TLS ≠ provider-blind encryption)

If you are building something similar for QA, start with Cloudflare’s Email Routing + Worker docs, keep retention tiny, and write the safety page before the launch tweet.

Need an inbox now? Generate one at FastTempMail.org — free, no signup, gone in about 15 minutes.