How Temp Mail Works: From MX Records to Your Inbox
No mailbox account is created when TempMailPortal shows you a new address. The address works because the receiving domain accepts mail for many local parts, and the open page knows which one to ask for. Follow one message from the sender to the screen and the setup becomes much less mysterious.
Step 1: The browser asks for a fresh address
Opening the site triggers a request for an inbox. The Worker creates a random local part—the characters before the @—and pairs it with an active disposable-mail domain. An address might look like g9j4pdiyx9@namesgeneratorhub.com. There is no permanent user record, password or recovery profile behind it. The response contains the address and a private mailbox credential, which the browser keeps locally for later reads.
The browser now creates private random inboxes only; it no longer opens legacy public names. Address access lasts separately from message retention. Keep the browser profile and pairing codes secure, and use temporary mail only for permitted messages you can afford to lose.
Step 2: The sender finds the receiving servers
The website sending the email treats the temporary address like any other destination. Its mail server looks up the domain's MX records in DNS to find out where incoming mail should go. Think of an MX record as the delivery sign for email: it tells the sender which receiving service handles mail for that domain. Here, the records point to Cloudflare Email Routing for the disposable domain. The sender does not need to know that the destination is temporary; it only needs a valid domain whose receiving servers accept the message.
This is why the brand domain and mailbox domains are kept separate. tempmailportal.com hosts the website and API, while disposable mail is received on domains intended for that purpose.
Step 3: A catch-all passes the message to the Worker
A conventional mail server often rejects an address it has never seen. A disposable domain instead uses a catch-all: mail for an otherwise unnamed local part is accepted and routed to application code. Cloudflare documents this behavior in its Email Routing address reference.
The Worker checks that the recipient belongs to a configured mailbox domain, parses the raw MIME message and separates the sender, subject, text, HTML and attachment details. Unsafe HTML features are removed before the body is returned to the browser. The remaining message data is stored against the exact mailbox local part with an expiration time.
The catch-all routes mail to application code. The Worker then applies recipient, access, retention and usage checks; routing a message to the Worker does not guarantee it will be stored.
Step 4: The open page checks for new mail
The inbox page sends its private credential to the internal service on a short interval and asks for message envelopes. Once a message has been stored, its sender, subject and preview appear without a manual refresh. Opening that row triggers a second request for the full body. In ordinary conditions the visible delay is the sender's delivery time plus whatever remains before the next poll; it is not a guaranteed instant-delivery service.
Knowing a new private mailbox address alone does not grant access. The browser needs the corresponding credential, and paired sessions also grant inbox access. These internal requests are not a public developer integration; the access policy explains supported use through the website and Android app.
Step 5: Scheduled cleanup removes old messages
Every stored message carries an expiration timestamp. A scheduled Worker task deletes expired database rows and any retained attachment objects. New private inboxes offer 10-minute, one-hour or 24-hour message lifetimes. Expired messages are excluded from reads before scheduled storage cleanup. There is no archive or restore button after cleanup, and clearing an inbox with its controls can remove its messages sooner.
The address itself is not a permanent asset either. A browser may remember the current address and token for convenience, but clearing that local state or switching devices can leave you without the token you were using. If a message or account will matter tomorrow, a temporary inbox is the wrong place for it.
Historical Worker test evidence
On 28 August 2026 we passed a crafted MIME message through the same email() handler used by Email Routing. The fixture deliberately contained useful text alongside a script, an iframe, a form and password-style input, an inline event handler, a javascript: link and an ordinary HTTPS link.
| Check | Observed result |
|---|---|
| Mailbox-domain boundary | namesgeneratorhub.com was accepted; the brand domain was rejected |
| Stored expiry | The stored expiry was exactly 24 hours after receipt |
| Active and embedded content | The script and iframe were removed |
| Credential-capture markup | Form tags and the input element were removed |
| Attribute-based execution | The inline event handler was removed and the javascript: URL became # |
| Legitimate content | The message text and ordinary HTTPS link remained |
This historical fixture predates the private-inbox update and used the then-default 24-hour lifetime. It is an application-layer check, not a claim that an email is harmless after sanitisation. A safe-looking link can still lead to a phishing site, and this fixture did not measure delivery from an outside mail provider through DNS and MX routing.
Questions people reasonably ask
How quickly should a message appear? There is no fixed delivery time: it depends on the sender, DNS, the receiving path and the next browser poll. The implementation check above tested parsing and storage, not external delivery latency. If nothing arrives, first confirm that the sender used the exact address and that its own system actually sent the message.
Can somebody else read the inbox? A new random inbox requires its private access credential; guessing the address alone is insufficient. Anyone using your browser profile or an authorised paired session may still have access. Never send personal documents, recovery links or important credentials to a throwaway inbox.
Can TempMailPortal send or reply? No. The service is receive-only. A message may show a reply-to address, but there is no composer or outbound delivery path in the product.
Is this the same as an email alias? No. An alias normally forwards to a permanent mailbox and stays useful for future mail. A temporary inbox stores mail separately and is designed to be abandoned. The broader choice is covered in disposable email vs. aliases.