Private Email Services Compared: What Happens When Your “Zero-Access” Provider Gets a Court Order

Three activists. Three different countries. Three encrypted email accounts. All three got identified anyway.

That’s not a hypothetical warning about privacy tools, it’s a documented pattern involving the most recommended encrypted email provider on the internet. If you’ve read any “best private email” article, you’ve seen Proton Mail listed first, usually with language like “not even Proton can read your emails.” That claim is technically true. It’s also not the whole story, and the gap between those two things is exactly what this guide is about.

This isn’t another feature checklist comparing storage limits and pricing tiers. It’s a breakdown of what “private email” actually protects, and what it doesn’t, based on documented legal cases, not marketing pages. By the end, you’ll understand why encryption alone was never enough to protect three real people, what Tuta does structurally differently that would have changed those outcomes, and how to pick the provider that actually matches what you’re trying to protect.

What “Zero-Access Encryption” Actually Promises (and Doesn’t)

Every encrypted email provider in this guide uses some form of end-to-end or zero-access encryption, meaning the company’s own servers cannot read the content of your messages. This is a real, cryptographically verifiable claim, and it’s meaningfully different from Gmail or Outlook, where the provider can and does scan message content.

Here’s the definition worth pinning down precisely: zero-access encryption means the provider stores your data in a form only your private key can decrypt, so even a government order compelling the company to hand over everything it has would produce unreadable ciphertext for message bodies.

What it does not mean is that the provider has nothing useful to hand over. Sender and recipient addresses, timestamps, IP addresses, subject lines (on some providers), device information, and payment details are metadata, information about the communication rather than its content, and metadata is exactly what identified all three activists in the cases below.

Quick takeaway: “They can’t read your emails” and “they can’t identify you” are two separate promises. Most privacy marketing conflates them. This guide keeps them separate, because the real-world cases below show why that distinction determined the outcome for real people.

The Pattern: Three Activists, Three Countries, One Encrypted Provider

This is the part most comparison articles either skip or bury in a single line. It deserves the full context, because it’s the clearest evidence available of what “private email” means in practice when a government actually asks.

Case One: The French Climate Activist (2021)

In the summer of 2021, French police were investigating an anti-gentrification group occupying buildings near Place Sainte Marthe in Paris. They wanted to identify the person behind a Proton Mail account linked to the group. France doesn’t have direct jurisdiction over a Swiss company, so French authorities routed the request through Europol to Swiss authorities, who approved it under Swiss law.

As TechSpot reported, Proton was then legally compelled to begin logging the IP address of that specific account going forward, something it doesn’t do by default. The logged IP, combined with a recovery email address Proton also provided, led investigators to an Apple ID, which led to the activist’s identification and arrest.

The detail worth sitting with: this wasn’t a hack, a leak, or a security failure. It was the system working exactly as designed under Swiss law. Proton’s own website had claimed “we do not keep any IP logs”, a claim that quietly disappeared from the site shortly after the case became public.

Case Two: The Catalan Independence Activist (2024)

Three years later, the pattern repeated with a different jurisdiction and a different account. Spanish authorities requested data connected to a Catalan independence activist’s account through the same kind of international legal assistance channel. Proton provided a recovery email address that authorities used to complete the identification.

Case Three: The Stop Cop City Protester (Disclosed 2024, Reported 2026)

The most detailed case became public more recently, though the underlying events happened earlier. 404 Media’s March 2026 investigation revealed a court record showing that on January 25, 2024, Swiss authorities, acting on an FBI request submitted through the US-Switzerland Mutual Legal Assistance Treaty (MLAT), compelled Proton Mail to disclose subscriber payment data for the account defendtheatlantaforest@protonmail.com, tied to the “Defend the Atlanta Forest” and Stop Cop City protest movement, which the FBI’s Domestic Terrorism squad was investigating over alleged arson, vandalism, and doxing connected to the protests. Proton provided a credit card payment identifier, which the FBI traced through the issuing bank to a named individual.

Proton’s public response to the reporting is worth including because it illustrates the exact distinction this guide keeps returning to. Proton’s head of communications told 404 Media that “Proton did not provide any information to the FBI, the information was obtained from the Swiss justice department via MLAT”, a technically accurate description of the legal chain. 404 Media’s reporting noted that, functionally, the data still reached the FBI regardless of which agency handed it over last. As of the March 2026 report, the identified individual did not appear to have been charged with a crime connected to the account.

What Connects All Three Cases

None of these cases involved Proton’s encryption being broken. Message content stayed unreadable in every single one. What got each person identified was metadata the encryption was never designed to protect: an IP address, a recovery email, a payment identifier.

Proton’s own transparency report shows the company received over 9,000 legal requests in a single recent year and complied with roughly 89% of them, which the company frames as compliance with Swiss law, and which is, factually, exactly that. Swiss law requires it. Proton is not lying when it says it complies with valid Swiss court orders. The gap is between that fact and the marketing language that leads users to assume “Swiss privacy laws” means immunity from all government requests.

The Numbers Behind the Pattern: Proton’s Legal Compliance Trend (2021–2025)

The three cases above aren’t isolated incidents, they’re data points in a measurable trend. Proton’s own transparency reports, compiled year over year, reveal a pattern most comparison articles never quantify:

Two things stand out. First, the contest rate, how often Proton pushes back against an order, dropped from 21.2% in 2021 to just 5.9% in 2024, before partially recovering to 10.6% in 2025. Second, the total volume nearly doubled between 2022 and 2024, reflecting both Proton’s growing user base (now exceeding 100 million accounts) and increasing government awareness that encrypted email providers are reachable through proper legal channels.

This doesn’t mean Proton became less privacy-focused, it likely means incoming orders became more legally precise, leaving less room for procedural challenges. But the practical outcome for users is the same: a legal order targeting your specific account has, statistically, an 89–94% chance of producing whatever metadata Proton holds about you.

The Same Company, Two Opposite Outcomes: Why Proton VPN Rejected Every Single Order

Here’s a detail that crystallizes the entire architecture argument better than any abstract explanation: In 2025, Proton received 59 legal orders targeting Proton VPN users. It complied with zero of them,  a 0% compliance rate, compared to 89.4% for Proton Mail in the same year.

Same company. Same Swiss jurisdiction. Same legal team. Completely opposite outcomes. The difference isn’t intent or policy, it’s architecture. Proton VPN was designed to never know which user was connected to which server at any given time. When a court order arrives demanding that information, Proton can truthfully respond: “We don’t have it. It was never generated.”

Proton Mail, by contrast, must know your account exists, must route messages to it, and must maintain enough metadata for the email system to function. That’s not a flaw, it’s a structural requirement of email as a protocol. But it means the question “does this company protect my privacy?” has two completely different answers depending on which product you’re asking about.

This is the clearest possible demonstration that architecture determines outcome, not company values, not jurisdiction, not policy language. What was never collected cannot be compelled.

Why This Happened: The Technical Reason Metadata Survived Encryption

This is the part almost no comparison article connects back to the actual cryptography, and it’s the single most useful technical fact in this entire guide.

Proton Mail is built on OpenPGP, the decades-old open encryption standard. OpenPGP encrypts message bodies and attachments. It does not encrypt email headers, because headers, sender, recipient, subject line, routing information, need to remain readable for the email system itself to function and for compatibility with the broader PGP ecosystem. This isn’t a flaw Proton introduced; it’s a structural property of the standard Proton chose to build on, as Proton’s own comparison documentation acknowledges.

Tuta (formerly Tutanota) made a different architectural choice specifically to close this gap. Rather than using OpenPGP, Tuta built a proprietary encryption system that encrypts the subject line, the entire address book, and calendar metadata, data points that OpenPGP-based providers, including Proton, leave in plaintext. Tuta also does not collect IP addresses at all, by design, rather than only ceasing to log them until legally compelled otherwise.

Look back at the three cases above with this distinction in mind. Case one required Proton to begin IP logging, something structurally possible because Proton’s architecture supports IP logging when compelled. Cases two and three depended on recovery email addresses and payment data, metadata categories that exist because of how the account and billing system connects to the encrypted mailbox. A provider that doesn’t collect IP addresses by architecture, not just by policy, removes that specific vector before a court order can ever compel it to appear.

This doesn’t mean Tuta is unconditionally safer, its subject-line encryption uses proprietary cryptography that hasn’t received the same decades of open academic scrutiny that OpenPGP has, which is its own trade-off, discussed further below. But the connection between architecture and outcome is real and specific: what a provider chooses not to collect can’t be subpoenaed, no matter how strong the legal order.

Beyond IP and Subject Lines: The Metadata You Don’t Know You’re Leaking

The three cases above involved obvious metadata, IP addresses, recovery emails, payment identifiers. But email metadata extends far beyond these commonly discussed categories, and most of it survives encryption regardless of provider:

• Hidden email headers: Every message you send contains 15–30 hidden headers revealing your device type, operating system, email client software, timezone, and sometimes your local network name. These are generated automatically by your mail client before the message reaches your provider’s encryption layer.

• MIME structure fingerprinting: The way your email client organizes message parts (plain text, HTML, attachments) creates a structural fingerprint. Two messages with identical content but sent from different clients produce different MIME structures, potentially linking anonymous accounts to known identities.

• Timing correlation attacks: If you consistently send emails at 9:00 AM Cairo time, that pattern identifies your timezone regardless of IP masking. Combined with message frequency and recipient patterns, timing metadata alone can narrow an anonymous sender to a small group of candidates.

• Behavioral fingerprinting: Message length distributions, response latency patterns, vocabulary choices, and activity windows create a behavioral signature that machine learning can use to correlate supposedly separate accounts operated by the same person.

What each provider actually protects against:

The uncomfortable conclusion: no provider in this guide, or anywhere, fully protects against timing, behavioral, or structural metadata analysis. These require operational discipline from the user, not technical features from the provider. The provider choice determines the floor of your metadata exposure; your operational habits determine the ceiling.

Quick takeaway: Zero-access encryption protects content. It says nothing about metadata unless the provider specifically architected the system to minimize what metadata exists in the first place. That architectural choice, not the strength of the encryption, is what determined the outcome in all three documented cases.

Proton Mail: The Full Ecosystem, With an Honest Anonymity Caveat

Proton Mail remains the most complete option in this category, and dismissing it because of the cases above would be an overcorrection. With over 100 million users, open-source clients, independent security audits, and a full ecosystem, Proton Drive, Proton VPN, Proton Pass, Proton Calendar, it’s the closest thing to a genuine, privacy-respecting replacement for the entire Google suite.

Is Proton Mail Actually Safe to Use?

Yes, for the threat model most people actually have. Proton’s zero-access encryption for message content is real and independently verified; the company has never been shown to have broken that specific promise. The three cases above involved metadata, not message content, and metadata exposure happened only when Proton was legally compelled to act against a specific, named account under a valid Swiss court order, not through mass surveillance or routine data mining. For a user whose concern is corporate profiling, casual snooping, or advertising-based data collection, Proton Mail is excellent.

Under Article 271 of the Swiss Criminal Code, Proton’s transparency documentation confirms, the company may not transmit data directly to foreign authorities, all requests must pass through Swiss courts first, adding a genuine legal barrier compared to a US-based provider directly subject to US subpoenas. That barrier held in none of the three cases above, because Swiss authorities approved the international requests each time. The barrier is real; it is not the same thing as immunity.

Best for: Users who want a complete, polished privacy ecosystem and whose threat model is data-mining and advertiser profiling rather than state-level targeting of a specific identity.

Tuta: The Metadata-Minimalist Choice

Tuta’s entire design philosophy is visible in the choice covered above: encrypt as much as technically possible, and don’t collect what you don’t need. Beyond subject-line encryption and no IP logging, Tuta has implemented post-quantum cryptography (Kyber/ML-KEM) alongside traditional algorithms, protecting against “harvest now, decrypt later” attacks where an adversary stores encrypted traffic today, waiting for future quantum computers to break it.

Does Tuta’s Custom Encryption Have Downsides?

Yes, and it’s worth being direct about the trade-off rather than presenting Tuta as strictly superior. Because Tuta doesn’t use OpenPGP, it can’t natively exchange end-to-end encrypted mail with users on other PGP-compatible services, Proton, Mailfence, or a standalone PGP client, without falling back to password-protected messages. Proton has also publicly disputed some of Tuta’s security claims, pointing out that Tuta’s encryption has not always required authenticated encryption, a cryptographic detail that in theory could allow message tampering by a compromised server, though Tuta has since added mitigations.

This is a legitimate technical criticism from a competitor, not proof of a practical exploit, but it’s a real trade-off: Tuta’s proprietary approach means less independent academic scrutiny than the decades-old, IETF-standardized OpenPGP protocol Proton uses.

Tuta has also won legal battles against German surveillance orders, with courts affirming that its encryption architecture makes certain backdoor compliance technically impossible, a tested legal precedent rather than a theoretical claim.

Post-Quantum Encryption: Who’s Actually Ready for “Harvest Now, Decrypt Later”?

Intelligence agencies and well-resourced adversaries are known to store encrypted communications today, waiting for quantum computers capable of breaking current encryption standards. This “harvest now, decrypt later” strategy means messages you send today could become readable in 10–15 years if your provider doesn’t implement quantum-resistant algorithms now.

Here’s where each provider stands:

• Tuta: Deployed ✅ Tuta has implemented hybrid post-quantum encryption using Kyber/ML-KEM (now standardized by NIST as the primary key encapsulation mechanism) alongside traditional algorithms. This means Tuta emails are protected against both current computers and future quantum attacks, today, not as a roadmap item.

• Proton Mail: Announced, partially implemented ⚠️ Proton has announced post-quantum encryption plans and has begun implementation in some services, but full deployment across all Proton Mail communications is not yet complete as of mid-2026.

• Mailfence: No public timeline ❌ Mailfence relies on standard OpenPGP, which does not yet include post-quantum algorithms in its widely deployed implementations. No public roadmap for post-quantum migration has been announced.

• Posteo: No public timeline ❌ Posteo does not offer end-to-end encryption by default, making post-quantum encryption a secondary concern behind implementing basic E2E first.

Why this matters now, not later: If your communications have long-term sensitivity, legal strategy, journalistic sources, trade secrets, political organizing, the encryption protecting them needs to be resisted not just today’s computers but tomorrow’s. A message encrypted with only classical algorithms today may be readable by a quantum computer in 2035. Only Tuta currently closes that window by default.

Best for: Users whose primary concern is metadata exposure specifically, journalists, activists, or anyone whose threat model includes exactly the scenario that unmasked the three activists above, and who don’t need PGP interoperability with non-Tuta contacts.

Mailfence: OpenPGP Interoperability from a Third Jurisdiction

Mailfence, based in Brussels, occupies a specific niche: standards-based OpenPGP encryption (like Proton) combined with Belgian jurisdiction (unlike either Proton or Tuta). Belgium sits outside the Five Eyes, Nine Eyes, and Fourteen Eyes intelligence-sharing alliances, and Mailfence’s own documentation notes that Belgian law requires a local judge’s court order for any data request, a legal bar the company describes as rarely triggered in practice.

Mailfence’s interoperability is a genuine advantage for users who need to exchange encrypted mail with contacts on other PGP-based services without the password-protected-message workaround Tuta requires. In 2020, Russian authorities blocked Mailfence’s SMTP servers after the company refused a data demand, a real-world demonstration of the company’s stated position, not just a policy claim.

The honest caveat: independent review from ProPrivacy notes that Mailfence logs more metadata by default than Tuta, including IP addresses, message IDs, and timestamps, and GPG encryption isn’t enabled by default, requiring users to activate it manually.

Best for: Users who specifically want OpenPGP interoperability with contacts on other encrypted providers, combined with a third legal jurisdiction outside the Swiss/German axis.

Posteo: Maximum Anonymity at Signup, Minimum Encryption by Default

Posteo takes a different approach entirely: instead of maximizing encryption, it maximizes anonymity at the point of account creation. As multiple reviews confirm, Posteo requires no identifying information to sign up, no name, no phone number, no recovery email, and even accepts anonymous cash payment by mail for users who want to leave zero payment trail. The service runs on 100% renewable energy and has a strong reputation for minimal logging.

The Trade-Off Nobody Highlights

Here’s the detail that gets lost in most “best private email” roundups: Posteo does not provide end-to-end encryption by default. It offers full-disk encryption on its servers and strips metadata where it can, but message content is not end-to-end encrypted the way Proton, Tuta, or Mailfence’s PGP implementations are, unless the user manually sets up PGP themselves. This makes Posteo a fundamentally different tool than the other three: it’s optimized for not knowing who you are, not for making your message content unreadable even to Posteo itself.

Best for: Users whose primary concern is anonymous signup and payment, leaving no identity trail at account creation, who are willing to configure their own PGP encryption on top for message content protection.

The Regulatory Wildcard: EU Chat Control and What It Means for Every Provider Here

Every comparison above evaluates providers against current law. But a single regulation currently in trilogue negotiations could reshape the entire landscape, and no amount of architectural minimalism can encrypt away a legislative mandate.

The EU’s Child Sexual Abuse Regulation (CSAR), known as “Chat Control,” has been the most contentious digital rights battle in Europe since 2022. Here’s where it stands as of mid-2026:

What happened:

• The European Commission originally proposed mandatory scanning of all communications, including end-to-end encrypted messages, for child sexual abuse material (CSAM).
• In October 2025, a Council vote failed to secure a qualified majority, with Germany’s opposition proving decisive.
• On April 3, 2026, the temporary voluntary scanning regime (Chat Control 1.0) expired after Parliament voted 311–228 to reject extending the ePrivacy derogation.
• Trilogue negotiations continue with a target deal aimed for July 2026.

What was dropped: Mandatory scanning of encrypted messages, the most extreme version, was removed from the current Council position. Strong encryption protection language was added.

What remains: Age verification requirements that critics warn could end online anonymity, plus “voluntary” detection measures listed as risk mitigation obligations, creating a legal contradiction where “voluntary” activities become formal requirements.

Why this matters for your provider choice: If a future version of this regulation passes with client-side scanning requirements, analyzing messages on your device before encryption, it would bypass every architectural protection discussed in this guide. 

Tuta’s subject-line encryption, Proton’s zero-access design, Mailfence’s PGP implementation: none of these protect against scanning that happens before the message reaches the encryption layer.

The practical implication: jurisdiction matters not just for current law, but for which legislative body controls your provider’s future obligations. A provider under EU jurisdiction (Tuta in Germany, Mailfence in Belgium) faces this regulatory risk directly. A provider in Switzerland (Proton) faces it only if Switzerland adopts equivalent legislation, which, historically, it has been slower to do.

This doesn’t change today’s recommendation, but it adds a forward-looking dimension most comparisons ignore entirely: the provider that’s most private today may not remain so if the regulatory environment shifts beneath it.

Threat Model Decision Matrix: Match Your Adversary to Your Provider

The right provider depends on who you’re protecting against and what specifically needs protecting. This matrix maps real adversary capabilities to concrete provider + configuration recommendations:

Key insight: As you move down this table, the provider matters less and your operational discipline matters more. Against a state-level adversary with international legal cooperation, the difference between providers is marginal compared to the difference between careful and careless operational security.

Five Mistakes That Undo Your Email Privacy Setup

Assuming “end-to-end encrypted” means “anonymous.”

As shown across all three documented cases, encryption protects content. It says nothing about your identity unless the provider specifically minimizes metadata by architecture. Conflating these two guarantees is the single most common, and most consequential, misunderstanding in this space.

Providing a real recovery email or phone number when anonymity matters

Case two above depended entirely on a recovery email address. If your threat model requires anonymity, any recovery method that ties back to your real identity defeats the purpose before a single email is sent.

Paying with a personal credit card when payment anonymity matters

Case three above was resolved through a payment identifier traced through a bank. If anonymity is part of your threat model, providers accepting cash-by-mail (Posteo) or cryptocurrency remove this vector entirely.

Emailing an unencrypted provider and assuming the conversation is protected

End-to-end encryption between two encrypted-provider users breaks down the moment either party emails someone on Gmail or Outlook. The message may be encrypted in transit, but it arrives readable on the other end, fully visible to that provider and subject to that provider’s own data practices.

Not checking whether your specific threat model needs anonymity or just privacy

Most users conflate these. Corporate data mining and advertiser profiling are privacy problems every provider in this guide solves well. State-level identification of a specific person is an anonymity problem, and as the cases above show, only a subset of these tools, used correctly, with careful operational choices, meaningfully address it.

Quick takeaway: The encryption is the easy part; every provider in this guide gets that right. The harder part is understanding exactly what metadata still exists around that encryption, and whether your specific situation depends on that metadata staying hidden.

Your 30-Second Privacy Audit: Check These Right Now

Before you switch providers or change anything about your setup, answer these six questions about your current encrypted email account. Each “yes” represents a metadata vector that exists regardless of how strong your encryption is:

1. Is your recovery email a personal address?(Gmail, work email, ISP email) → This is exactly what identified the Catalan activist. If anonymity matters, remove it entirely or use a disposable address created over Tor.
2. Did you pay with a personal credit card or PayPal? → This is exactly what identified the Stop Cop City protester. Switch to cryptocurrency, cash-by-mail (Posteo), or a prepaid card purchased with cash.
3. Do you access your encrypted email from the same IP address without a VPN or Tor? → This is exactly what identified the French climate activist. Layer Tor or a trusted VPN between your device and your email provider.
4. Is your encrypted email address linked to any social media, forums, or public profiles? → A single cross-reference destroys pseudonymity. Use different addresses for different identity contexts.
5. Do you email contacts on Gmail, Outlook, or other unencrypted providers? → Your encryption ends at their inbox. The message arrives readable, scannable, and subject to their provider’s data practices.
6. Do your subject lines contain sensitive information? → Unless you use Tuta, subject lines are plaintext metadata. Write them as if they’ll be read by someone other than your recipient, because legally, they can be.

Score: Every “yes” is a gap that no provider can close for you. The provider handles encryption; you handle operational security. Both fail without the other.

Beyond Choosing One Provider: The Compartmentalization Strategy

The question “which provider should I use?” contains a hidden assumption, that you should use only one. For users with genuine privacy requirements beyond basic anti-tracking, the more effective approach is deliberate compartmentalization: different providers for different identity contexts, with no cross-contamination between them.

1. Layer 1 — Professional identity (Proton Mail):Your real name, used for work, banking, official correspondence. Proton’s full ecosystem (Drive, Calendar, VPN, Pass) replaces Google services comprehensively. Threat model: protection from corporate data mining and casual breaches. You accept that this identity is legally linked to you.
2. Layer 2 — Pseudonymous activity (Tuta, accessed only via Tor): A separate identity for sensitive communications,  journalism, activism, research, whistleblowing. No recovery email. No payment method linked to Layer 1. Never accessed from the same IP or device as Layer 1. Tuta’s architectural metadata minimization provides the strongest foundation for this layer.
3. Layer 3 — Disposable registrations (Posteo or similar): For signing up to services, forums, mailing lists, or any context where you need a working email address but want zero connection to either Layer 1 or Layer 2. Posteo’s anonymous signup (no name, no phone, cash payment) makes this layer untraceable to either of your other identities.

The critical rules:

• Never send email between layers (this creates a metadata link)
• Never access two layers from the same network session
• Never use the same device for Layer 2 and Layer 1 without a full Tor/VPN reset between sessions
• Never reference information from one layer in another
• If one layer is compromised, the others remain isolated

Why this matters more than provider choice:The three activists in the cases above each used a single provider for everything. A compartmentalized approach means that even if one layer is legally compelled to disclose metadata, the adversary gains access to only that layer’s limited context, not your entire communication history and identity.

This is more operational discipline than most users need. But for the subset of users whose safety depends on it, compartmentalization is the single highest-value practice available,  more impactful than any individual provider feature.

Before and After: What Actually Changes

Before switching from Gmail or Outlook: Every email is scanned for advertising purposes. Content, attachments, and metadata are all visible to the provider, and in Gmail’s case, used to build an advertising profile spanning years of communication. Government requests for content require no encryption to bypass, the provider can simply hand over what it already reads.

After switching to an encrypted provider (any of the four above): Message content becomes unreadable to the provider itself, meaningfully raising the bar for casual access, data breaches, and routine corporate data mining. This is a real, substantial privacy gain for the vast majority of use cases.

What doesn’t automatically change: Metadata, who you email, when, how often, from what device or IP, and depending on the provider, even the subject line, may remain visible unless you’ve specifically chosen a provider and configuration that minimizes it. Legal jurisdiction determines who can compel that metadata to be disclosed, and under what process, but every jurisdiction in this guide has some process by which disclosure is legally possible.

The Bottom Line

Three activists, three countries, one encrypted provider, zero broken encryption, and three identities unmasked anyway. That pattern isn’t an argument against encrypted email. It’s an argument for understanding precisely what encryption protects, and choosing your provider and your operational habits based on that precision rather than marketing language.

Proton Mail remains an excellent, full-featured choice for the privacy problem most people actually have. Tuta’s architecture is the more deliberate choice if metadata minimization is specifically what you need. Mailfence offers a genuine third path with OpenPGP interoperability. Posteo solves a different problem entirely, anonymous signup, that none of the encryption-first providers address as directly.

The question isn’t “which provider is most private” in the abstract. It’s “private from what, and from whom”,  and the three cases in this guide are the clearest real-world answer available to that question.

Frequently Asked Questions