This seems roughly in-line with how most people probably handle and manage their emails. I personally use aliases with important accounts too, since I have custom domains that I own and use with SimpleLogin. Temporary inboxes are used on services I’m testing out or if I have little reason to trust them or if they serve an ephemeral or unimportant purpose.
Personally, I only ever give out my “real” inbox to things that are both critical and directly adjacent to Government stuff, eg taxation, voter registration.
Everything else goes on an alias unless I don’t care about signing in again or the ability to receive emails again. Some temporary inbox providers will still let you reuse the address (eg: altaddress) so in a pinch you can receive a password reset email or similar.
I was thinking about the idea of having separate emails for personal life vs internet life, but that might be a bit much for me to juggle.
It’s always good to check with your specific apps, but no bank, crypto or government service I’ve used allowed restoring an account by email alone. It’s usually email + something else (phone, password). I’ve also never experienced losing access to an alias. So I don’t see a reason to use a real email in any of those cases.
temporary inbox
Just not sure there are any common use cases where these should be preferred over an alias.
The difference between a “real” email and an alias is more about reuse for me. If I want my email to be shareable I use a real address — I don’t use aliases for work, for example, since it would be weird and inconvenient if every coworker used a different alias. But for services, having one address per service is very convenient.
I think I was using “real inbox” too broadly. A better split may be:
an address I own/control
an alias that forwards to an address I own/control
a temporary inbox that I do not expect to keep
Your point about aliases makes sense. For many sensitive or long-term services, an alias can be perfectly reasonable if I control the alias provider/domain and can keep receiving mail later.
So maybe the real boundary is not “real inbox vs alias”, but “durable address I control vs temporary address I may lose.”
For temporary inboxes, I agree they are probably not preferred over aliases for most privacy-focused users. The only cases where I still see them fitting are workflows where there is no long-term relationship to preserve, such as:
downloading a one-off resource
checking a newsletter before deciding whether to subscribe
event/webinar access where I do not need future recovery
testing signup or email delivery flows
product evaluation where losing the inbox later would not matter
If I may need password resets, refunds, account recovery, records, or future login, then it should be an alias or an address I own — not temporary email.
So my updated rule would be:
Use an owned address or alias for anything durable.
Use an alias by default when privacy plus future access matters.
Use a temporary inbox only when the task truly ends and losing the address is harmless.
That framing is clearer to me than my original “real inbox” wording.
I use real email address only for a cloud-based password manager and 2FA, in case I lose access to my phone, computer, and the recovery codes I’ve written down on paper. I aim for 100% aliasing.
The thing is, there’s no such thing as an address you fully control.
I’ve never been banned by an email provider, but it’s entirely possible Microsoft/Google/Proton will ban my account someday for some reason. It’s unlikely, but it’s also not clear why “owning” a real address is more solid than an alias. Even though I have my own domain, I don’t use it for aliases much, since I suspect I’ll decide to stop paying for it one day
One more obvious thing I forgot: banks, government services, and the like are among the few places where you have to write your address on a form or spell it out over the phone. That’s probably the main reason I still don’t use aliases everywhere, as my aliases are usually random words I can’t remember
I think the better wording is “an address or alias with planned continuity,” not something I literally control forever. Any provider or domain setup can fail; the difference is whether I expect to keep receiving mail there and have some recovery/migration path.
So an alias can be fine even for important accounts if the alias setup is durable enough. A temporary inbox is different because I’m assuming from the start that losing access later is acceptable.
The memorability point also makes sense. For banks/government/forms/phone calls, a stable address may be useful simply because it is easier to remember and spell.
Partly, yes — I used AI/translation help to clean up the wording, but the question and reasoning are mine.
I’m not trying to spam; I’m trying to understand where people draw the line between a temporary inbox, an alias, and a long-term mailbox.
If anything sounds unclear or too polished, I’m happy to rephrase it.
I’d recommend using alias emails for stuff that you want to keep and then tempmail things for one time use or throwaway stuff. Tempmail can also be good for more anonymous usage I suppose. It depends on the use case. These days I find myself mostly using addy.io because the free plan is so generous.
I use Proton pass (SimpleLogin) for stuff I think might be more frequent and take up quite a bit of bandwidth as thats where addy is limited, or things I may need to reply to. Then I use tempmail for junk stuff, a newsletter I want once, a site that is paywalled by email only sorta thing.
Tempmail is also more anonymous, as it’s not linked to any of your IRL accounts in any way. Never use a tempmail inbox for something you would not want to be public information. Literally anyone could access it.
Just different tools really. Nails and screws hold wood together. Both are useful.
The “never use tempmail for anything you would not want to be public” point is probably the clearest boundary for me. I was thinking about temporary inboxes mostly as a short-lived convenience/privacy tool, but the “potentially public inbox” risk makes the rule much sharper.
So my current framing would be:
If I need future access, replies, resets, records, refunds, or recovery: use an alias or durable mailbox.
If the account is sensitive or identity/billing-related: use something with a clear continuity/recovery plan.
If it is one-time, low-risk, and I would be fine losing the inbox or having the message exposed: temporary inbox can be acceptable.
I also like the “nails and screws” analogy. It sounds like tempmail is not really a replacement for aliases; it is more for workflows where there is intentionally no long-term relationship.
Are there any cases where you would consider tempmail better than an alias, other than one-off/junk/paywall/newsletter-type use?
Main benefit is a quick throwaway for non sensitive information, burner accounts you’ll use once, and to have a totally anonymous email not linked to you.
You can make anonymous proton accounts with them for example. Proton requires a recovery email so you can supply a burner and then remove afterwards. No ties to you in that respect then.
Yeah, different tools for different jobs. I use both frequently.
Small update after trying to map this to real workflows: I think I was using “temporary email” too broadly.
A single disposable inbox is fine if I only need one verification email and never come back. But for repeated testing, the useful thing is not just the temporary address itself — it is having a more organized tempmail workflow.
For example, when testing newsletters, signup forms, email-gated downloads, or trial accounts, it helps to have separate inboxes for separate tests, some inbox history, and addresses that look closer to normal Gmail/Outlook-style addresses instead of random disposable domains. That makes it easier to see which signup created which email, without mixing test messages into my real inbox.
So I think the line is something like this:
alias: when I may need continuity, replies, resets, or records
temporary email: when the relationship is intentionally disposable
temp mail workspace: when I’m doing multiple low-risk tests and need separation/organization
I still agree with the warning above: any gmail temp inbox, outlook temp mail, or other temporary email should be treated as disposable and potentially public. I would not use it for private, recoverable, billing, or long-term accounts.
But for low-risk QA/testing workflows, I can see why an organized temp mail workspace is more practical than either reusing a real inbox or creating aliases for every throwaway test.