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@ynoxa.com. There is no permanent user record, password or recovery profile behind it. The response contains the address and a signed mailbox token, which the browser keeps locally for later reads.
A custom local part can also be requested, but that convenience makes the mailbox easier to reproduce. For anything beyond a controlled test, the random address is the less guessable option. Neither choice turns a temporary inbox into a confidential account.
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 service does not pre-register thousands of mailboxes. The catch-all accepts mail first, and the Worker sorts each message into the mailbox named in the recipient address.
Step 4: The open page checks for new mail
The inbox page sends its signed token to the API 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.
The token limits an API request to one local part, but it should not be confused with private account authentication. Someone who deliberately requests the same custom local part can reproduce access. That is why the interface is suitable for low-stakes mail and test traffic, not secrets or account recovery.
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. The current message lifetime is about 24 hours. There is no archive or restore button after cleanup, and deleting an inbox through the API 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.
Questions people reasonably ask
How quickly should a message appear? Often within seconds, but delivery depends on the sender and the receiving path. The open page polls on a short loop, so a small wait is normal. 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? Treat that as possible. Random addresses are harder to guess, but the service has no private user account behind the mailbox. 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.