Inside a Temp Mail Service: The Journey of an Email From SMTP to Your Screen

Why We Are Showing You Our Pipeline

Most disposable email services are black boxes. You type an address, emails appear, and you have no idea what happens in between — who sees the messages, where they are stored, or whether they are ever really deleted. Since the honest answer to "can I trust a temp mail service?" depends entirely on those details, we decided to document exactly how PureTempMail works, component by component.

Everything below describes the production system serving this website right now. It is written by the team that built and operates it — not a simplified marketing diagram. Where we made a trade-off, we say what it was and why.

Step 1: The SMTP Handshake — Where Most Junk Dies

Every email on the internet starts as an SMTP conversation. Our edge runs Haraka, an open-source SMTP server, listening on port 25 with TLS enabled for senders that support it. When a mail server connects and announces a recipient, we do not blindly accept the message.

During the RCPT TO phase — before a single byte of message content is transferred — we check the recipient address against the list of active mailboxes. If nobody generated that address, or its mailbox has already expired, the connection is rejected on the spot with a permanent SMTP error. We never accept-then-silently-discard. This early rejection also reflects a deliberate design constraint: PureTempMail is inbound-only. There is no way to send email from a PureTempMail address, which means the service cannot be abused for spam, phishing, or harassment campaigns.

Step 2: A Queue Between Receiving and Processing

An accepted message is not parsed inside the SMTP server. Instead, the raw email is piped into a message queue (RabbitMQ) and the SMTP conversation ends immediately. The reason is timing: sending servers expect an answer within seconds, while parsing a large email with attachments can take much longer. Decoupling the two means a burst of incoming mail never causes timeouts or lost messages — the queue absorbs the spike and a consumer works through it.

That consumer parses the raw MIME structure: it extracts the subject, sender, HTML and plain-text bodies, and any attachments. Attachments are written to isolated storage under randomly generated names — never under the filename the sender chose, which closes an entire class of path-manipulation attacks. Message metadata and bodies go into PostgreSQL, tied to the mailbox's expiry time.

Step 3: Sanitizing HTML So Marketing Email Cannot Track You

HTML email is the most dangerous part of any inbox. A typical marketing message contains remote images (tracking pixels that report when and where you opened it), external stylesheets, and sometimes scripts. Before an email is ever shown to you, we run it through an HTML sanitizer with a strict whitelist: scripts are stripped, external resources are removed entirely, and only safe inline styling survives. A tracking pixel simply never loads, so the sender cannot tell whether the message was opened.

The sanitized result is then rendered inside a fully sandboxed iframe in your browser. Even if something malicious survived sanitization, the sandbox prevents it from touching the page around it, your mailbox session, or anything else in your browser.

Step 4: Real-Time Delivery With Server-Sent Events

Most temp mail sites make you refresh the page or poll every few seconds. PureTempMail keeps a single long-lived HTTP connection open from your browser using Server-Sent Events (SSE). The moment the consumer finishes storing a message, an event is pushed down that connection and the email appears in your inbox — typically one to three seconds after the sender dispatched it. For time-critical flows like two-factor codes and activation links with short expiry windows, those seconds matter.

The connection sends periodic heartbeats so dead connections are detected, and the client reconnects automatically with exponential backoff if the network drops. The same event stream powers our Android and iOS apps, so every platform sees a new message at the same moment.

Step 5: Expiry Means Real Deletion

Every mailbox is created with a countdown you can see on screen, and you can extend it while it is alive. Once it expires, a cleanup job that runs every few minutes takes over: attachment files are deleted from disk first, then the database rows for the mailbox and all its messages are removed in a cascade.

There is no archive, no backup of expired mail, and no "soft delete" flag that keeps data around invisibly. This is data minimization enforced by architecture rather than by policy: we cannot hand over, leak, or lose what no longer exists.

That is the entire journey — an SMTP handshake, a queue, a parser, a sanitizer, a push event, and a deletion job. Each stage exists to keep an address you will use for ten minutes from costing you anything afterwards. If you ever wonder whether a disposable email service is doing something shady with your messages, ask them to publish their pipeline. We just did.

Prefer the short, non-technical version of this pipeline? See how PureTempMail works step by step