How Tempx Handles Your Mail

This page is the short, honest version of the security posture: what actually happens to a message between the sender and your screen, what protects it, and — just as important — what it is not protected against. Temporary email is a convenience, not a vault, and the design bets on that being clear.

The receiving path

Mail to a Tempx address arrives over normal SMTP at Cloudflare's edge and is handed straight to the Tempx worker for parsing and storage. There is no third-party mailbox service in the path — no forwarding hop where the message would also live. Attachments are stored in object storage under keys that never appear in URLs, and each message carries the expiry that will delete it.

Displaying untrusted mail

Every message is treated as hostile until rendered safely. Before any HTML is shown, it is sanitized: scripts, styles, iframes, forms and event handlers are stripped, and links are made safe. What remains is rendered inside a locked-down sandboxed frame with its own content-security policy, so even a missed vector has nowhere to execute. Remote images — the tracking pixels that tell a sender you opened the mail — load only after you allow them, per message.

Attachments

File types are determined from the file's actual content (magic bytes), never from the name or the claim of the sender.
Executables and scripts — .exe, .js, .sh and friends — are refused outright, whatever they are called.
Only small, verified images can be previewed. Everything else, PDFs included, is download-only.
Downloads go through short-lived signed URLs that expire within minutes, and the files are deleted together with their message.

Retention and deletion

Each message is scheduled for deletion when it arrives — 1 hour in a private inbox, up to 7 days in a named one — and an automated job removes it permanently, attachments included. There is no archive, no trash folder you can dig through, and no way to recover a deleted message. Data you don't keep is data that can't leak.

Who can read an inbox

A named inbox is public by design: the name is the secret, and anyone who types the same name sees the same mail. That is the classic disposable-email trade — instant access with no account, in exchange for a guessable key. A private random inbox inverts it: the address is drawn from a space too large to guess, and reading it requires a bearer token held only by your browser. Pick per task, not per habit.

Tokens and developer credentials

Access tokens for private inboxes, MCP credentials (tmcp_…) and SMTP credentials (tmtp_…) are separate namespaces that never cross-authenticate. Only a hash of each is stored; each is scoped — a single inbox, a fixed permission set, an expiry you choose — and each can be revoked in one click from the account page. Account sign-in itself is Google or GitHub OAuth: Tempx stores no passwords.

The SMTP gateway is a trap, on purpose

The gateway developers point their apps at (smtp.tempx.uk:587, STARTTLS) accepts every message and captures it into the credential's paired inbox. It never relays onward — there is no code path that delivers to the outside world — so a misconfigured test run cannot email a real person. Credentials are validated live against the API on each authentication attempt; the password itself is not stored on the gateway machine.

Site hardening

The site serves a strict content-security policy, security headers, and sandboxed rendering everywhere; machine-to-machine secrets fail closed when unset. Inbox and account surfaces are excluded from indexing (robots and HTTP headers), and raw message sources are only reachable through signed, expiring URLs.

What this does not protect against

It is not end-to-end encrypted. Mail arrives over standard channels and is stored briefly in plain form, because it has to be displayed. Anyone able to read the storage can read the mail.
Named inboxes are readable by design. Anyone who knows or guesses the name — right now, or before the retention expires.
The sender still sees delivery. A temporary address hides your real one; it does not make you anonymous to the platform you gave it to.

The practical rule follows directly: use temporary email for verification links, one-time codes and throwaway signups. Do not route secrets, 2FA for accounts you value, or anything confidential through it.

Reporting a problem

Abuse (spam, phishing, harassment via a Tempx address): abuse@tempx.uk, with the address involved and the message headers if you can. Security issues: security@tempx.uk, or /.well-known/security.txt for the current details. Reports about mail content describe messages that will expire on their own — include headers, not just a description.