Private Email Without the Hype: Proton Mail vs Tuta vs Fastmail

Private email is not one technology. It is a chain: device, account recovery, provider storage, message content, addressing metadata, recipient, network transport and whatever happens after delivery. Proton Mail, Tuta and Fastmail draw that chain's trust boundary in different places.

The right choice depends less on which homepage says privacy most often than on who you communicate with, which clients you require, whether you control a domain, how you will migrate, and which failure would be hardest to recover from.

The short answer

• Choose Proton Mail when zero-access mailbox storage, automatic end-to-end encryption with other Proton users and a broader privacy-service ecosystem matter more than direct mobile-client interoperability.
• Choose Tuta when an encrypted, provider-controlled client and calendar are the priority and you accept that ordinary IMAP clients are outside the design.
• Choose Fastmail when standards-based clients, custom-domain operations, migration and strong everyday workflow matter more than zero-access message content.
• Choose none yet when your current provider is not the main risk. A unique password, multifactor authentication, clean recovery settings and fewer forwarding rules may produce the larger immediate improvement.

These are fit statements, not universal rankings. If the recipient uses ordinary email and you do not add a separate encrypted-delivery mechanism, no provider can make the recipient's mailbox adopt your storage model.

First locate the encryption boundary

Transport encryption protects a connection between devices and servers or between mail servers when supported. Encryption at rest protects stored disks or databases against some forms of physical or infrastructure compromise. Zero-access encryption is designed so the provider does not hold the key required to read stored message content. End-to-end encryption protects content between participants' endpoints under the relevant key scheme.

These terms are not interchangeable. End-to-end protection also does not necessarily conceal sender, recipient, time, size, subject or IP-related metadata. Official Proton documentation, for example, distinguishes message bodies and attachments from subject lines and addressing fields. Read the boundary, not the adjective.

Proton Mail: encrypted storage with a bridge to some desktop clients

Proton says messages and attachments in the inbox use zero-access encryption. Messages between Proton addresses are end-to-end encrypted in transit. Mail arriving from an external service is stored with zero-access protection after Proton receives it, but ordinary delivery from a non-Proton sender is not retroactively end-to-end encrypted across the whole route.

For desktop clients, Proton Mail offers Bridge on paid plans. Bridge runs locally and presents IMAP/SMTP to supported desktop software while handling Proton's encryption workflow. Proton's mobile support pages state that third-party mail apps on iOS and Android do not integrate in the same way; use Proton's own mobile apps if that matters.

Paid plans support custom domains, with limits varying by plan. Proton provides Easy Switch for importing from IMAP services and an Export Tool available to everyone for decrypted local exports. That exit route is valuable, but test it with your real folder volume and filenames before treating migration as solved.

Best fit: people who want provider-side zero-access content storage and can work inside Proton's web/mobile clients or supported desktop Bridge workflow. Poor fit: people who require frictionless native IMAP across many mobile and niche clients.

Tuta: an encrypted client ecosystem that rejects IMAP

Tuta Mail says messages between Tuta users are automatically end-to-end encrypted. For external recipients, a sender can create a shared password and the recipient opens the protected conversation through Tuta's system. Ordinary unprotected mail to outside providers still crosses the conventional email network.

Tuta does not support IMAP or POP. Its published reason is architectural: it wants message handling to remain inside its encryption-aware web, desktop and mobile clients. This is a meaningful tradeoff, not a missing checkbox. It reduces interoperability with standard mail clients and automation that expects IMAP.

Tuta's support documentation says paid subscriptions support custom domains. It also uses a recovery code for account recovery. Store that code offline and test the recovery instructions before moving a primary address. Import and export capabilities are changing product surfaces, so inspect the current support instructions for the data types and account tier you actually need.

Best fit: people willing to use one provider's clients to keep encrypted mail and calendar functions within a defined system. Poor fit: people whose workflow depends on Apple Mail, Thunderbird, Outlook, server-side IMAP tools or broad third-party integration.

Fastmail: privacy-minded operations and open mail standards

Fastmail requires encrypted connections for its webmail, official apps and standards-based IMAP, POP and SMTP access. Its storage architecture documentation says partitions use native ZFS encryption. It supports app-specific passwords that can be restricted by data type, as well as custom domains, imports and exports.

This is not the same claim as zero-access message-content encryption. Fastmail's service needs server-side access for features such as search, filtering and standards-based delivery. Its value proposition is a mature email workflow with privacy and security practices, not an end-to-end encrypted island.

For many families and small organizations, interoperability is itself a resilience feature. Standard clients, documented ports, export functions and domain control can make a future move less dependent on one application. That flexibility expands the number of trusted components, so protect every app password and remove it when a device or client is retired.

Best fit: people who want a custom-domain email service, excellent conventional mail workflow and third-party client support. Poor fit: people whose threat model requires the provider to be technically unable to read stored message content.

Compare the jobs, not the brands

• Encrypted conversations inside the same service: Proton and Tuta make this central. The benefit is strongest when both participants use the compatible encrypted path.
• Ordinary internet email: all three must interoperate with outside mail systems. Check what is protected before arrival, during transport, in provider storage and at the recipient.
• Third-party clients: Fastmail supports standard protocols directly; Proton uses Bridge for supported desktop clients on paid plans; Tuta uses its own clients and does not support IMAP.
• Custom domains: all three offer them on qualifying paid plans. Owning the domain can preserve your public address when changing providers.
• Migration: Proton and Fastmail document import/export paths. Tuta provides migration support but its current capabilities should be verified against your source and plan. Always run a sample.
• Recovery: encryption increases the importance of recovery material. A system that protects content from the provider may also limit what support can restore for you.

What no comparison table can erase

Email was built to route messages, so addresses and delivery information remain operationally important. Even when content is strongly encrypted within a provider, correspondents, timestamps, account identifiers, device logs and recipient behavior can reveal a great deal. A private mailbox is not anonymous communication.

The recipient can copy, forward, screenshot or disclose a message after decryption. Malware on an endpoint can read content when the user can. Recovery accounts and domain registrars can become takeover paths. Backups can reintroduce plaintext. Your threat model must include endpoints and people, not just server storage.

A migration protocol that preserves exit

1. Define the threat: advertising profiling, provider access, account takeover, abusive access, data breach or jurisdictional concern require different controls.
2. Inventory dependencies: aliases, calendars, contacts, forwarding, filters, devices, shared accounts and services that use the address for recovery.
3. Choose address portability: consider a domain you control if you can maintain registration and DNS securely.
4. Export first: create a local archive and open a sample outside the old provider.
5. Secure recovery: record recovery codes, enable strong multifactor authentication and protect the registrar separately.
6. Pilot: move a noncritical address or a small mail sample before the primary inbox.
7. Test delivery: send in both directions across several major providers; check spam, SPF, DKIM and DMARC results for a custom domain.
8. Overlap: keep the old service long enough to discover missing senders and imports.
9. Test the exit: export from the new provider before the old account is closed.

The no-buy option

If the main risk is account takeover, switching providers without fixing authentication merely moves the vulnerable account. Use a unique generated password, enable phishing-resistant multifactor authentication where available, save recovery codes offline, review forwarding rules and active sessions, and remove old recovery addresses. Then decide whether the provider's content-access model remains a material risk.

If sensitive conversation is occasional, a dedicated end-to-end encrypted messenger may fit better than forcing every correspondent through an email portal. If email is mostly receipts and account recovery, a custom domain plus aliases can improve separation and portability even without zero-access storage.

What not to buy for

• Do not switch because a provider calls itself private without naming which data it can access.
• Do not buy a long plan before testing clients, exports, recovery and domain setup.
• Do not assume a protected message remains protected after the recipient opens it.
• Do not route a high-risk situation through email merely because the mailbox is encrypted.
• Do not give up a working recovery path in pursuit of an abstract maximum-security score.

Official documentation checked September 7, 2026

• Proton, How Proton Mail messages are encrypted, Mail support, custom domains, and Export Tool.
• Tuta, Security at Tuta, product support, and desktop client and IMAP architecture.
• Fastmail, How Fastmail provides a secure service, storage architecture, app passwords, and migration and export settings.
• CISA, Turn on multifactor authentication.