How temp mail works (the technical version)

From the outside, temp mail looks like magic. You load a page, an address appears, and mail starts showing up. Under the hood it is a short chain of ordinary email tools joined together. This page walks through that chain step by step: the DNS record, the mail server, the fetcher, the database, the timer, and the cleanup.

×

QR Code for

Step 1: the MX record

Every email domain needs to tell the world where its mail should go. It does that with a DNS record called MX, short for mail exchanger. When a site sends a message to you, its mail server looks up the MX record for your domain, finds our mail server, and connects to it. An MX record is a signpost, nothing more.

Each domain in our pool has its own MX record pointing at the mail server. The sending side just follows the signpost, opens an SMTP connection, and hands over the message. We wrote about that handshake in detail: how disposable email services handle incoming SMTP traffic.

Step 2: the catch-all mailbox

A catch-all is a mail server rule that accepts mail for any name on the domain and drops it into one shared mailbox. On a normal domain, the server keeps a list of real users and bounces mail for names that are not on it. A temp mail domain turns that rule off.

The catch-all is what makes temp mail instant. Nothing needs to be created when you get an address, because every name already works. The only job left is to sort the shared mailbox by the name in front of the at sign.

Step 3: the website makes an address

When you load TempMail.now, the site picks a domain from the pool and builds a random name. It stores that pair as your address, along with the time it was created and how long it should live. It ties the address to a cookie in your browser so the site knows which inbox to show you on the next request. No account, no password, no personal data.

The name is random enough that guessing it is not practical. But it is not a secret in the strong sense. That is why we say to treat every temp inbox as public. See is temp mail safe for where that line sits.

Step 4: the fetcher polls over IMAP

The fetcher is a small background program that connects to the mailbox over IMAP every few seconds and asks for anything new. IMAP is the same protocol a mail app uses. The fetcher exists because the mail server holds messages, but the website needs them in a form it can query fast.

For each new message, the fetcher does a few things:

• Reads the To address and finds the random name in front of the at sign.
• Checks if that name is a live temp address. If not, the message is dropped.
• Pulls out the sender, subject, text, HTML body, and any attachments.
• Saves the whole thing in a database row tied to your address.
• Deletes the message from the mail server so it is not read twice.

Because the fetcher reads the full message, attachments come along for free. A PDF or an image is just another part of the email. It is stored with the message and shown in the message view. Nothing special has to happen for attachments to work.

Step 5: the page polls every 15 seconds

Every 15 seconds, the page asks the website for the messages tied to your address, and the inbox updates if there is anything new. Your browser never talks to the mail server; the website reads from the database. That is why a message can take a moment to appear even after the fetcher has saved it.

Put the two polls together and you get the usual delay: a few seconds for the fetcher, up to 15 seconds for the page. If a message takes longer than half a minute, the delay is almost always on the sending side. Our guide on temp mail not receiving emails covers the common causes.

Step 6: the timer deletes everything

Each address has an expiry time. When the clock passes it, the address is dropped from the active list and its messages are deleted from the database. Later mail for that name no longer matches a live address, so the fetcher throws it away. The Change Email button does the same thing early.

On top of the timer, a cleanup job runs on a schedule. It finds any expired address or orphan message that was missed and deletes it. This backstop means nothing sits in the database longer than it should. There is a longer piece on this at the technical reason temp mail inboxes auto-delete, and the retention rules are listed on how we handle your data.

Why sending is not offered

Sending is not offered because it would break the service. If anyone could send from a random name with no login, spammers would use it within hours. The domains would land on every block list, and mail to real temp inboxes would start to bounce. Receive-only keeps the domains clean.

It also keeps the code small. There is no outbound mail server to run and no sending limits to enforce. Every part of the chain above is about accepting mail and showing it to you. Nothing goes the other way.

What receive-only means for security

Receive-only means nothing here can send mail in your name, there is no account to steal, and mail is held for minutes, not years. The trade-off is that the inbox is not private in the strong sense. In detail:

• Nothing you do here can send mail in your name. There is no address to spoof from.
• There is no password to steal, because there is no account.
• Mail is held for minutes, not years. A breach would find very little.
• The inbox is not private in the strong sense. Do not use it for anything you could not post in public.

That last point matters most. Temp mail is a tool for throwaway sign-ups and one-time codes. The whole design, from the catch-all to the timer, is built around that job. If you want a fresh address to try it with, the email generator gives you one in a click, and the 10 minute mail page starts a short timer.

Frequently asked questions