Email aliasing on separate page

Continuing the discussion from Avoiding the next Skiff:

Honestly wondering if we should move email aliasing providers to their own page and really focus on promoting the benefits of those much more. I’d probably argue that using an aliasing provider is more critical to most people’s privacy, by blocking passive email correlation attacks across websites/marketers, than having a secure inbox.


than having a secure inbox.

I agree, but does this mean a change in security criteria for alias services?

Yes in favour!

But… perhaps this should move to a page about identity management in combination with password managers. We already see that the integrations there are getting closer and closer which makes a lot of sense.

1 Like

Yes, I would like to see Aliasing moved to its own page. I think that would be more clear.


Me too, looks good to me.

1 Like

Definitely! And describe why it is important.

Both important. Even if you will use top alias services, if you email will be hacked all aliases will be breached too (because they redirect email to main email address)

Can you clarify?

@jonah, “secure inbox” like a very good security like google, that won’t be hacked or a very good privacy like proton and tuta ? @Heuristic-X and other and myself might be talking about different stuff.

In this case for protecting content of mail and alias, good security > good privacy
Both is better, but the spam control and privacy improvement of alias over gmail is still better than no alias.

Well I think alias services and password managers are essentially not that different. It’s all based on managing your identities.

You should always store all information you give to companies in your password manager. This so you can remember what you told them, what they know about you and so you can also be verified. Also, that will help to know what is exposed in case of a data breach. It keeps you in control. That’s definitely a recommendation to make regardless of the structure.

Then I see proton pass which is basically an aliasing service as well (sure it currently relies on simplelogin in background, but it has full management control).

My expectation is that this will become the standard for all password managers. They will basically become identity managers who store your passkeys, email addresses, passwords, perhaps dedicated phone numbers, etc. Even Apple with iCloud has this to some extent.

I am making the prediction that also Bitwarden will improve management capabilities over aliases and likewise the collaboration between Fastmail and 1password.

I am not saying it should be on one place on the website, but I think it should be considered. Likewise, I do believe that eventually you will just have one place to manage this all. If we keep it seperate we might end up having to change it because for example SimpleLogin gets fully integrated in Proton Pass, which I think is super likely to happen.

1 Like

This is completely off-topic. And nothing is 100% secure as @Heuristic-X pointed out nicely. Google also managed to lose people their documents in Google Drive which was only partially fixed. This is why you need backups, and you must encrypt data securely. Not saying google is bad in security, but don’t expect to be safe. You should always take precautions and frankly the most easy way to do that is using a provider who enables you to do so easily like proton does.

Message to the mods: feel free to remove/move cuz this is completely unrelated, but I do think this message needed to be debunked.


Eye opening read. Many thanks :slight_smile:

Most of those aren’t actually to do with google mail or in some cases google products, seems like blogspam with bunch of articles shilling proton with a referral link.

1 Like

That’s just a draft, suggest improvements if you want :

Great to see this making progress! Glad to see these paragraphs:

Email aliasing can act as a safeguard in case your email provider ever ceases operation…however, you are placing trust in the aliasing service to continue functioning

However, using a custom domain can have privacy-related drawbacks…

Could we consolidate these related points into a section focusing on this and add a couple points to it?

Of all the types of services that PG recommends, email alias service is one of the most difficult to deal with ceasing operation or becoming non-recommendable.

Could we also add a sentence to be more explicit about how using a custom domain can help with migration? The disadvantages are already mentioned. We could also include ways of mitigating those disadvantages. Here’s a draft section based on what @rollsicecream already drafted.

Planning for portability

When an email/alias service provider ceases operation, changes its policies or a better service provider becomes available, it can be challenging to switch providers since many contacts/companies might need to be informed of the change in your email/alias address. When selecting an alias or email provider, consider the following trade-offs and how you will migrate away from the service when the time inevitably comes.

  • Advantage Aliasing can act as a safeguard in case your email provider ever ceases operation. In that scenario, you can easily re-route your aliases to a new email address.
  • Disadvantage In turn, however, you are placing trust in the aliasing service to continue functioning.

Custom domain

  • Advantage Using a custom domain(s) can greatly improve portability since you can move the domain to a new alias/email provider and help avoid the trade-offs of aliases mentioned above.
  • Disadvantage However, using a custom domain can have privacy-related drawbacks: if you are the only person using your custom domain, your actions can be easily tracked across websites simply by looking at the domain name in the email address and ignoring everything before the at (@) sign.
  • Compounded disadvantage To some extent, using a single alias-provider subdomain (e.g. or has both privacy disadvantages and portability disadvantages.
  • Mitigation If warranted, using a combination a custom domain and an alias-provider domain might mitigate the disadvantages of each approach. Using multiple domains to separate personas could also help if warranted by your threat models.

Thanks for your suggestion!

What we can do is making another entire page titled “Email Aliasing overview” in the knowledge base of the site. In this page, we can explain how email aliasing works, advantages and disadvantages and maybe even some tips and tricks. I don’t know if it’s the right approach, though.

We should also talk about criteria as there isn’t any, for now, in my draft. Maybe we should take the “Email Criteria” and change some words here and there :smile:


Looks like there will be a rework on the email page. @jonah So I think PG should emphasis more the benefits of using your own domain for email.

Some great discussions:

A disadvantage of moving email aliasing providers to a separate page is that people who only know that they want an email service might miss the information about email aliasing. However, this could be mitigated by including on the Email Services page a strong recommendation to consider email aliasing along with links to more info about it.


That article is a bit shitty.

One of my concerns is that, if I were unable to renew my domain (e.g., in case of death), someone else could register it and start receiving my emails.

Considering you can register a domain for 5-10 years, that would have to mean you like went to prison or something. In any case you could make arrangements with family or something beforehand.

Another concern is privacy. Using a unique domain name for email stands out, especially when it has your name.

This is why aliasing services exist. You can have multiple domains, and they don’t necessarily have to have your name in them.

One concern there that wasn’t mentioned was, what happens if your email provider shuts down/demands ridiculous fees, etc etc. Without your own domain, you have no options.

whois will show owner’s name?

Some domain registrars protect you from whois