Not all "encrypted email" works the same way under the hood. Two broad approaches show up across the industry: PGP, an older, widely interoperable standard, and proprietary encryption built by an individual provider. Understanding the difference helps explain some real trade-offs.

What PGP generally offers

PGP (Pretty Good Privacy) is an open, decades-old standard supported across many different email clients and services. Its main strength is interoperability — in principle, PGP-encrypted mail can move between different providers and tools, rather than being locked into one company's ecosystem.

Where PGP is commonly criticized

PGP has a reputation for being difficult to use correctly for average users — managing keys manually is a common pain point. It also typically leaves the email subject line unencrypted, since PGP was designed around encrypting message bodies and attachments, not headers.

What proprietary encryption generally offers

A provider building its own encryption system (as Tuta's documentation describes doing) can integrate encryption more seamlessly into the product, often with less manual key management for the user. It can also potentially cover more of the message, including the subject line, since the provider controls the entire system end to end.

The trade-off: interoperability

The flip side of a proprietary approach is generally reduced interoperability — a message encrypted with one provider's custom system typically isn't natively compatible with a different provider's system, unlike PGP's shared standard. This can matter if you regularly need to exchange encrypted mail with people using different tools.

Easier for the average user versus broadly interoperable with other systems is a real trade-off, not a solved problem either approach gets entirely right.

Questions worth asking

  • Do I mostly email people on the same encrypted service, or a mix of providers?
  • How much do I value ease of use versus broad standard-based interoperability?
  • Does subject-line encryption specifically matter for my use case?
  • Am I comfortable with the key-management model a given approach requires?

For more general background, see our guides on encryption basics and privacy & security basics.