Search "temporary email" and you get hundreds of near-identical sites. They differ far more than their designs suggest. Here is what actually matters when picking one, and the point where running your own becomes the better answer.

A checklist that matters

1. Does it use HTTPS?

Your inbox contents travel over the network. A temp-mail site without HTTPS is reading your mail in plain text. Check the padlock before pasting an address.

2. How long is the mailbox kept?

Common answers: 10 minutes, 24 hours, or "until you close the tab". Longer is not automatically better — a permanent public inbox means anyone who guesses the address can read it.

3. Is the address guessable?

Random strings are fine. Sequential or dictionary-based addresses on a shared domain can be enumerated by other users of the same service.

4. Does the provider log or share mail?

Read the privacy policy. Some free services monetize by scanning message metadata; others keep only what delivery requires.

5. Is the domain blocked by the services you use?

Many sites maintain blocklists of known temp-mail domains. A public provider you did not choose may simply not work for the signup you need.

6. Ads and tracking

Free services need revenue. If the ad stack is heavy, the page itself may track you more than the mail service does.

Why public providers fall short

The business model explains most of the trade-offs: free, anonymous, ad-funded inboxes are optimized for cost, not for your control. Domains rotate when they get blocklisted, inboxes vanish when you close the tab, and the operator can read everything.

The self-hosting case

Running your own temporary mail service changes the equation:

  • Your own domain. Not on any blocklist until someone decides to add it, and you can run several domains.
  • You are the operator. No third party reads the mail; you set the retention policy.
  • Custom rules. Per-domain lifetimes, Gmail alias mode, or dual delivery that forwards unknown recipients to a real mailbox.
  • Cost. A $5/month VPS and a domain are enough; the software itself can be a single Node.js process with an embedded SMTP server and SQLite storage.

The trade-off is maintenance: DNS, mail server configuration and TLS are now your responsibility. For most people the honest answer is:

  • Occasional use → pick a reputable public provider that passes the checklist.
  • Frequent use, or developer workflows → self-host. The setup cost is a one-time afternoon, and you never worry about someone else's inbox policy again.

If you want to see what self-hosting looks like end to end, our install guide covers the full stack in one page.