Being built

Methmailprivate email

Which email is the most secure?

Updated: · Sources checked:

In short. No email provider is the most secure for everyone: it depends on what you need protection from. But you can check any provider against the same list of questions. Here are 17 of them, with hints on where to find the answers.

What makes email secure and private

Secure email keeps your messages from being read by anyone but you and the people you write to. With end-to-end encryption, only the sender and the recipients can read a message; with zero-access encryption, the provider stores your mail encrypted with a key it doesn’t have, but it still sees mail from other services at the moment it arrives. Private email also keeps little about you: even when messages are encrypted, metadata, who writes to whom and when, can stay visible. And it matters who stores your data, where, and under which country’s laws: the 17 questions below check all of this.

First, decide what you are protecting against

A hijacked account, a leak at the provider, the provider itself reading your mail, a request from the authorities: these are different threats, and email services handle them differently. Before you compare providers, answer three of the questions from EFF’s security plan for yourself [2]:

  • What needs protecting? The content of your messages, who you talk to, or the fact that you talk at all.
  • From whom? Random attackers, the email provider itself, or the authorities of some country.
  • What are you willing to pay for it? Convenience, money, time.

If your main concern is the provider reading your mail, pay most attention to the encryption questions. If it is what the provider knows about you, focus on the questions about your data.

Encryption

  1. Who holds the keys to your stored mail? Ideally, your messages are stored encrypted with a key the provider does not have [1]. If the provider holds the keys, it is technically able to read your mail, even when it says “everything is encrypted”. More in What is end-to-end encryption?
  2. What exactly is encrypted? Only the text and attachments, or also subject lines, senders, recipients and contacts? Whatever is not encrypted, the provider can see.
  3. Can you exchange encrypted mail with people on other services? That takes compatibility with the open OpenPGP standard [3]. It helps if your contacts’ keys are found automatically.
  4. Does the provider run its own infrastructure? A service built on top of another email provider hands your mail to one more company [1].

Your data

  1. What does it take to sign up? Ideally a username and a password, nothing more [1]. A phone number or another email address ties the mailbox to you.
  2. Does the provider hide your IP address in the emails you send? Every message carries technical headers. If your IP address ends up there, the recipient can tell where you wrote from [1]. It is easy to check: send a message to another address of yours and look at the Received lines in its headers.
  3. Is there a clear list of what the provider keeps, and for how long? The privacy policy should answer that plainly, not in general terms [1, 11].
  4. Can you leave with your mail? Ideally, messages export to standard MBOX or EML files [4, 5]. Services do shut down sometimes, and then the export is your insurance.
  5. Can you use your own domain? Then your address stays yours even if you change providers [1].

Account security

  1. What second factor is offered? A code from an authenticator app [6] is stronger than SMS, and security keys and passkeys [7] are stronger than codes. NIST classes verification over the phone network, meaning SMS and calls, as restricted [8].
  2. How well is the provider’s domain protected? DNSSEC, SPF, DKIM, DMARC, MTA-STS and DANE make it harder to forge mail in the provider’s name or intercept it on the way [9]. You can check any mail domain for free at internet.nl [10].

Trust

  1. Is it public who is responsible for the service, and under which countries’ laws it can be made to hand over data? That decides which court can demand something from the provider [1].
  2. Is the app code open? Open code lets anyone check that encryption in the app works as described. But app code does not prove what the server stores: an independent audit can show that. More in Open-source email: what you can check, and what you can’t.
  3. Was there an independent audit, and is the report published? “Checked by experts” means nothing without a link to the report.
  4. Does the provider publish a transparency report? It shows how many requests came from the authorities and what was handed over [1].
  5. Does the provider say what its protection cannot do? Every protection has limits. It is a bad sign when a service promises that its security cannot be broken or that no one could ever identify you from your mail [1].
  6. Does the provider’s own website track you? Third-party trackers and ad pixels on an email provider’s site say more about its attitude to privacy than its promises do [1].

How to read the answers

  • A provider does not have to answer “yes” to everything. What matters is that the answers are honest and can be checked.
  • If an answer is not public, that is an answer too.
  • Check the dates. “Best email provider” lists go stale fast, and services change.

What about Methmail?

Methmail is still being built, so we can’t yet answer “yes, check for yourself” to any question on this list. There is no audit, and no audit report, yet. How we plan to answer these questions is on the Who makes Methmail, Security and Privacy pages. When an answer becomes checkable, we will mark it here.

Sources

  1. Privacy Guides: Email Services, Criteria section (updated June 28, 2026). https://www.privacyguides.org/en/email/#criteria
  2. EFF, Surveillance Self-Defense: Your Security Plan. https://ssd.eff.org/module/your-security-plan
  3. RFC 9580: OpenPGP. IETF, July 2024. https://www.rfc-editor.org/rfc/rfc9580
  4. RFC 4155: The application/mbox Media Type. IETF, September 2005. https://www.rfc-editor.org/rfc/rfc4155
  5. RFC 5322: Internet Message Format. IETF, October 2008. https://www.rfc-editor.org/rfc/rfc5322
  6. RFC 6238: TOTP: Time-Based One-Time Password Algorithm. IETF, May 2011. https://www.rfc-editor.org/rfc/rfc6238
  7. W3C: Web Authentication Level 3. https://www.w3.org/TR/webauthn-3/
  8. NIST SP 800-63B, revision 4 (2025): Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63b.html
  9. RFC 4033 (DNSSEC, March 2005) https://www.rfc-editor.org/rfc/rfc4033, RFC 7208 (SPF, April 2014) https://www.rfc-editor.org/rfc/rfc7208, RFC 6376 (DKIM, September 2011) https://www.rfc-editor.org/rfc/rfc6376, RFC 9989 (DMARC, May 2026) https://www.rfc-editor.org/rfc/rfc9989, RFC 8461 (MTA-STS, September 2018) https://www.rfc-editor.org/rfc/rfc8461, RFC 7672 (DANE for SMTP, October 2015) https://www.rfc-editor.org/rfc/rfc7672.
  10. Internet.nl: mail domain test. https://internet.nl/
  11. Regulation (EU) 2016/679 (GDPR). https://eur-lex.europa.eu/eli/reg/2016/679/oj