Temp mail looks simple from the outside — type an address, get an email — but real mail infrastructure is doing the work. Here's what actually happens at the protocol level.
Receiving the email: SMTP and MX records
When someone sends mail to your temp address, their mail server looks up the MX record for the domain (e.g. mail.td). The MX record points to Mail.td's SMTP servers. The sender's server opens an SMTP connection on port 25 and delivers the message.
Mail.td's SMTP gateway accepts the message and writes the parsed email to storage. The whole receive cycle usually completes in well under a second from the sender's "send" action.
Parsing the message
A raw email isn't just a body. It's a multipart MIME structure with headers (From, To, Subject, Date, Message-ID), one or more text/HTML parts, and attachments encoded as base64. Mail.td parses the message, extracts each part, and stores them so the inbox UI can render them quickly.
Real-time delivery to your browser
When a new email arrives, the inbox UI gets notified two ways:
- WebSocket push — if your browser maintains an open WebSocket connection, the new email ID is pushed the moment it lands
- Polling fallback — if WebSocket isn't available (firewall, transient issue), the UI polls every 10 seconds for new messages
You see the email in your inbox typically within 1–2 seconds of its arrival on the SMTP gateway.
Storage and cleanup
Mailbox passwords are processed in your browser before being sent — the server only stores a hash, never the plaintext. Messages and attachments live in object storage with a strict retention policy. For the exact retention rules, see How Long Does Temp Mail Last?.
What's NOT happening
- Mail.td doesn't send your address to advertisers
- It doesn't read your messages programmatically
- It doesn't archive expired emails — when retention ends, the data is wiped