Temp Mail, Aliases, and Catch-Alls: A Guide to Email Privacy in 2026

Email is the single most common identifier on the internet, and it earns that position by design. It is unique on purpose, it is entered by hand into nearly every account anyone creates, it is required rather than optional, and it is passed between companies as a routine part of doing business. If you were asked to design the ideal key for joining databases across organisations, you would design an email address.

Which means the address you sign up with is not a contact detail. It is the primary key that every service you use has agreed to share.

The first thing worth dismissing is plus-addressing. Appending a tag to the local part of your address feels like compartmentalisation and provides none. The tag is trivially stripped — it is a documented convention, the normalisation is a single line of code, and any system in the business of deduplicating users is already doing it. Worse, it advertises the base address in plain sight, so a tagged address is not merely no better than the plain one, it is a plain address with a label on it explaining where you used it.

Catch-all domains are a real improvement and a real commitment. A domain of your own gives you unlimited unique addresses that do not obviously share a stem. It also means every address you hand out points at a domain whose WHOIS, hosting, and history are one lookup away from each other, and that keeping mail flowing is now your operational problem. It is the right answer for some people and considerably more work than they expected.

Aliasing services sit in between, and are a genuine step forward for ordinary personal use. The limitation is that they are usually built around one person forwarding into one real inbox. That is a fine model for reducing spam and hiding your address from a retailer. It is a poor fit when the point is that the identities are supposed to be separate, because the arrangement's whole design is a funnel with you at the bottom.

Temp mail fails in a different and more expensive way. It solves the signup and then expires, taking with them every recovery path the account will ever need — the password reset, the device confirmation, the re-verification after a breach. The account is not locked, it is orphaned. And a large share of disposable domains are on public lists that signup forms consume, so the address either fails at the door or marks the account as low-trust from its first day.

What you actually want per identity is an address that is unique, unconnected to your other addresses, genuinely able to receive mail, and still working in eighteen months. That is the shape Persona Kit's inbox takes: each persona can be given its own address on a Persona Kit domain, and that address really receives mail, for as long as the persona exists.

The posture is per persona rather than global, which is what makes it survivable at scale. A persona can have no address at all, which is right for anything that never needs to receive anything. It can have an inbox, which receives and holds mail you read when you have a reason to. Or it can forward to an address you actually watch, which is right for the small number of personas that own something you cannot afford to notice late.

The reason that choice matters is that the failure mode of compartmentalised email is not leakage, it is abandonment. Thirty mailboxes that each demand attention become thirty mailboxes nobody opens, and an unread inbox is functionally the same as no inbox when a verification code is sitting in it. Mail across every persona is readable from one place — read, star, archive, and search across all of them — and digests summarise the quiet ones, daily, or hourly on Pro. The aim is that adding the thirtieth persona does not add a thirtieth thing to check.

Deletion is the part that is genuinely hard to assemble yourself. When a persona is deleted, its mail goes with it. A collection of third-party throwaway mailboxes has no such property: they expire on somebody else's schedule, and whatever passed through them was handled by an intermediary you have no relationship with and cannot ask about afterwards.

A few rules cover most situations. Never reuse an address across compartments, including for a recovery contact, which is the leak people most often overlook because it does not feel like using the address at all. Never use a real address as the recovery contact for a persona's account. Assume any address you give a service will end up in a dataset somewhere, and choose it on that basis. And apply the eighteen-month test before you type anything into a signup form: if this account asks me to prove I own this inbox a year from now, can I?