Email Encryption Explained: TLS, PGP, and End-to-End in Plain English

Is your email actually private? Mostly, no.

Here is the uncomfortable truth that the word "encryption" tends to paper over: the email you sent this morning was almost certainly readable by your email provider, and possibly by the recipient's provider too. Not because anyone hacked anything, and not because you did something wrong. That is simply how the email most people use is built. The padlock in your client, the "secure connection" your browser reports, the sense that modern email is locked down — all of it is real, and almost none of it means what most people assume.

This guide exists to close that gap. Email encryption is a topic where a little knowledge is genuinely dangerous, because the surface-level version ("my email is encrypted, so it's private") is confidently wrong in a way that leads people to send things they shouldn't and skip protections they need. By the end, you will understand the three layers of email encryption, what each protects and leaves exposed, why almost no mainstream email is end-to-end encrypted, who offers the real thing, and how to decide whether you need it. No cryptography degree required.

Start with the mental model that makes everything else click. When you send an email, it does not teleport from your screen to your recipient's. It travels: from your device to your provider's outgoing server, across the internet to the recipient's provider, where it sits until the recipient opens it and it travels to their device. That journey has distinct stages, and encryption can be applied — or absent — at each one. Confuse the stages and you will misjudge your privacy every time.

Three questions decide how private any given email actually is. Is it encrypted while it moves between servers (in transit)? Is it encrypted while it sits stored on a server (at rest)? And is it encrypted so that even the servers handling it cannot read it (end-to-end)? Most email gets a confident "yes" to the first two and a flat "no" to the third — and that third answer determines whether your provider, a subpoena, or a rogue employee can read your words. We will take each layer in turn.

One more framing note. "Secure email" is not a single switch you flip. It is a stack of overlapping protections, each guarding against a different threat, each with gaps the next layer is meant to cover. The goal here is not to scare you off email — billions of perfectly fine messages go out daily over ordinary, non-end-to-end email. The goal is to make you fluent enough to look at any "encrypted email" claim and ask the right follow-up: encrypted where, against whom, and who still holds the key?

What are the three layers of email encryption?

Email encryption is not one thing. It is three different protections that operate at three different points in a message's life, and they are routinely confused — including by people selling "encrypted" products. Getting these three straight is ninety percent of understanding email security, so we'll define them cleanly here and then spend the rest of the article going deep on each.

The first layer is encryption in transit, which protects your message while it is moving — from your device to your provider, and from one mail server to the next. The dominant technology here is TLS (Transport Layer Security), often initiated by a command called STARTTLS. In-transit encryption is like an armored truck carrying a letter between buildings: while the letter is on the road, nobody can read it. But the moment the truck arrives and the letter is unloaded, it is a plain letter again, readable by whoever runs the building.

The second layer is encryption at rest. This protects your message while it sits stored on a server's disks — in your inbox, in the recipient's inbox, in backups. Providers encrypt stored data so that if someone physically steals a hard drive or breaches the storage layer, they get scrambled bytes instead of your mail. But here is the catch that trips everyone up: the provider holds the keys to that encryption. They have to, in order to show you your inbox and run features like search and spam filtering. At-rest encryption stops a thief with a stolen disk; it does not stop the provider itself.

The third layer is end-to-end encryption (E2EE). This is the only layer that hides your message from the servers handling it. With true end-to-end encryption, the message is scrambled on your device before it leaves, and it can only be unscrambled on the recipient's device. No server in between — not yours, not the recipient's — can read the content, because none of them has the key. The two classic standards here are PGP (and its open variant, OpenPGP) and S/MIME. This is the layer that delivers what most people imagine when they hear "encrypted email," and it is also the layer that almost no mainstream email actually uses.

Hold those three apart and a lot of marketing becomes legible. "We encrypt your email in transit and at rest" — what Gmail, Outlook, and nearly every major provider say — describes layers one and two. It is genuinely good security against outside attackers, but it says nothing about whether the provider can read your mail, because layers one and two do not even try to keep the provider out. Only the third layer does that. The table below summarizes the split; the sections that follow unpack each layer.

How does TLS (encryption in transit) work, and what does STARTTLS do?

TLS — Transport Layer Security — is the same family of encryption that puts the padlock in your web browser and the "s" in https. For email, it does one specific job extremely well: it encrypts the connection between two mail servers (or between your client and your provider) so that anyone tapping the wire in between sees scrambled gibberish instead of your message. When people say email is "encrypted by default" in 2026, this is almost always what they mean.

STARTTLS is the mechanism that usually turns TLS on for email. Historically, mail servers talked to each other over SMTP in plain text. STARTTLS is an SMTP command that says, in effect, "let's upgrade this plaintext conversation to an encrypted one before we exchange the actual message." If both servers support it, they negotiate a TLS-protected channel and the email crosses that hop encrypted. The Electronic Frontier Foundation describes STARTTLS as the command that initiates TLS encryption on top of an otherwise plaintext SMTP session — a bolt-on upgrade rather than something baked in from the start.

And that bolt-on nature is exactly where the limitations live. STARTTLS is opportunistic: it encrypts if both sides support it, but classically it falls back to sending the message unencrypted if the other server doesn't offer TLS or if the negotiation is tampered with. Encryption is not guaranteed unless it is actively enforced with newer policies like MTA-STS or DANE, which tell servers "refuse to deliver in plaintext" rather than "encrypt if convenient." Email travels across multiple hops, and TLS only protects each hop if that hop cooperates. One weak link in the chain and the message can cross it in the clear.

But here is the limitation that matters most, and it is structural, not a bug: TLS is hop-to-hop, not end-to-end. The armored-truck analogy from earlier is precise. At each stop along the route, the message is decrypted, sits readable inside that server, and is re-encrypted for the next leg. Your provider receives your message in readable form, processes it, stores it, and re-encrypts it to send onward. TLS protects the road between buildings; it does nothing to stop the people who run the buildings from reading the letter while it's inside. As one encryption guide puts it bluntly, transport-level encryption like TLS secures your email while it travels between servers — and that is all it does.

None of this makes TLS worthless — far from it. TLS is the essential baseline, and email without it is genuinely exposed to casual interception on shared networks; security professionals universally recommend enforced TLS for all mail. The mistake is thinking it does more than it does. TLS answers "can someone eavesdrop on the wire?" with a solid no. It says nothing about "can my provider read my mail?" — and for most people, the provider is the entity with the most access to their entire email history.

What does at-rest encryption protect, and why doesn't it keep your provider out?

Once your email arrives at a provider and lands in storage, a different protection takes over: encryption at rest. Major providers encrypt the data sitting on their disks, so that a stolen drive, a misconfigured backup, or a breach of the raw storage layer yields encrypted blobs rather than readable mail. This is real, valuable security, and it is now standard practice across reputable providers. If a data center is physically compromised, at-rest encryption is what stands between the intruder and your inbox.

The crucial subtlety is who holds the keys. For at-rest encryption to be useful as a feature — to show you your inbox the instant you log in, to search ten years of mail in milliseconds, to filter spam and detect malware — the provider must be able to decrypt your stored mail on demand. So the provider holds the keys. That is not a flaw in the design; it is the design. At-rest encryption in a normal email service protects your mail from outsiders who reach the disks; it does not protect it from the provider, which decrypts it constantly to operate the service.

This is why standard Gmail, for instance, encrypts your mail in transit and at rest yet Google can still scan it — for spam, for malware, for the features it builds. The encryption is keyed to Google, not to you. Privacy-focused providers improve on this with what's called zero-access (or zero-knowledge) encryption, where mail is stored under a key derived from your password that the provider genuinely cannot use. Proton describes zero-access encryption as ensuring the provider has no way to read your stored messages, scan them, or hand them over. That is a meaningful upgrade over ordinary at-rest encryption — but, as we'll see, even zero-access storage has a gap that only end-to-end encryption closes.

There is also a timing gap worth naming. Even with strong at-rest or zero-access encryption, a newly arriving email typically exists in readable form for a moment before it is encrypted into storage — the server has to receive the plaintext to process and then encrypt it. As one analysis of provider limits notes, new mail can still be intercepted at that moment unless it was end-to-end encrypted to begin with, because the provider handles the unencrypted version before sealing it away. A court order served at the right time, or a rogue employee, could capture a copy. At-rest encryption protects mail that is already sitting still; it cannot protect mail at the instant it arrives.

So at-rest encryption earns its place in the stack: it defends against the disk-theft and breach scenarios that genuinely happen. But it shares TLS's fundamental limitation in a different costume. TLS keeps eavesdroppers off the road; at-rest encryption keeps thieves out of the warehouse. Neither keeps out the company that owns the road and the warehouse. For that — for keeping the provider itself out — you need the third layer.

What is end-to-end encryption, and how do PGP and S/MIME deliver it?

End-to-end encryption is the layer that does what people picture when they hear "encrypted email." The message is scrambled on your device before it ever leaves, and it can only be unscrambled on the recipient's device. Every server in between — yours, the recipient's, and anything in the middle — handles only ciphertext. None of them holds the key, so none of them can read the content, even if compelled, breached, or staffed by someone curious. This is the only layer that treats the providers themselves as part of the threat model.

The magic that makes this work without the two parties having to secretly agree on a password is public-key cryptography. Every user has a pair of keys: a public key, which they share freely, and a private key, which never leaves their device. Anything encrypted with someone's public key can only be decrypted with their matching private key. So to email you securely, I encrypt the message with your public key; from that moment, only your private key can open it — not mine, not the servers', only yours. Proton summarizes the mechanism cleanly: messages are encrypted with the recipient's public key and can only be decrypted with their private key, which only they hold.

Two standards implement this for email, and the difference between them is mostly about trust and management. PGP (Pretty Good Privacy), and its open-standard cousin OpenPGP, builds trust from the bottom up: users generate their own key pairs and vouch for each other's keys directly, in what's historically called a "web of trust." It is decentralized, free, and powerful — and, as we'll discuss, notoriously fiddly for ordinary people to manage. PGP encrypts the email content itself, giving true end-to-end protection even from the mail providers.

S/MIME (Secure/Multipurpose Internet Mail Extensions) does the same cryptographic job but organizes trust from the top down. Instead of users vouching for each other, identities are certified by trusted Certificate Authorities — the same kind of organizations that issue the certificates behind https. That centralized model makes S/MIME easier to deploy and manage inside large organizations, which is why it dominates in enterprise and government settings. Encryption guides generally land on the same recommendation: S/MIME tends to fit corporate environments better thanks to easier management and enterprise support, while PGP appeals to individuals and technical users who want decentralized control.

Both share the same defining property and the same operational cost. The property: the content is unreadable to everyone except the intended recipient, full stop. The cost: both parties need compatible setup. To send you an end-to-end encrypted message, I need your public key (PGP) or certificate (S/MIME), and you need the private key and software to decrypt it — without it, I fall back to ordinary, non-end-to-end email. That mutual-setup requirement is small for two prepared parties and a genuine wall for everyone else, which is the single biggest reason the most private layer of email is also the least used. The next section unpacks why.

What does email encryption NOT hide? (Metadata and subject lines)

Here is the limitation that surprises even people who set up end-to-end encryption: encrypting the body of your email does not hide who you're talking to, when, or about what. Email's metadata — the sender address, the recipient address, the timestamp, and crucially the subject line — generally stays exposed even when the message content is fully end-to-end encrypted. This is not a weakness of any one provider; it is baked into how the email protocol routes messages.

The reason is mechanical. Mail servers need to read the envelope to do their job — they have to see the recipient address to deliver the message and the sender to handle bounces and replies. So the "to," "from," and "date" fields ride along in readable form by design, because the routing infrastructure has to act on them. PGP and S/MIME encrypt the body; they were never designed to encrypt the envelope. As security researchers note, there is no provision in the PGP protocol to hide the metadata — the sent-from, sent-to, and date fields stay visible.

The subject line is the sharpest edge of this, because people intuitively treat it as part of the message. It is not, cryptographically. The subject line is part of the email header, and it is not end-to-end encrypted in Gmail even when using S/MIME. The same holds across most of the ecosystem. Even Gmail's own client-side encryption, by Google's documentation, leaves the header — subject, timestamps, recipients — without the additional encryption applied to the body. So "Q3 layoff list — confidential" or "Re: your HIV test results" or "Wire $40,000 to this account" can sit in plaintext as a subject even when the body is locked tight. Encrypt the contents, leak the headline.

Why does this matter so much? Because metadata is enormously revealing on its own. A pattern of encrypted emails between a journalist and a known whistleblower, timestamped around a leak, tells a story no one needs to read the bodies to follow. Frequent late-night messages between two people, or a sudden flurry between a company and a bankruptcy law firm, or repeated contact with a specific medical clinic — the envelope alone can expose relationships, timing, and intent. Intelligence agencies have long understood that metadata is often more analyzable than content, precisely because it's structured and unencrypted.

There are partial answers, but they're narrow. Tuta is notable for encrypting the subject line along with the message body, going further than most providers that leave subjects readable. But even Tuta cannot fully hide the sender and recipient routing information, because the mail still has to be delivered. The honest takeaway: end-to-end encryption protects what you say, not the fact that you said it, to whom, or when. If hiding the relationship itself is your goal, email is structurally the wrong tool, and you should reach for a system designed for metadata privacy instead.

Why isn't most email end-to-end encrypted by default?

If end-to-end encryption is so clearly more private, why does the email that billions of people use every day skip it? The answer is not that providers are careless or that the technology doesn't exist — PGP has been around since 1991. The answer is a tangle of usability, economics, and incentives that has resisted solution for over three decades. Understanding why E2EE didn't win is the key to setting realistic expectations for your own email.

The first reason is usability, and it is brutal. PGP, the original end-to-end standard, is widely described as simply too complex for mainstream adoption. To use it, an ordinary person had to generate a key pair, grasp the difference between public and private keys, distribute their public key, manage key revocation when keys were compromised, and verify other people's keys to be sure they were genuine. Each of those steps is a place to make a catastrophic, silent mistake. Decades of research keep reaching the same conclusion: the friction of key management, not any flaw in the cryptography, is what killed mass adoption.

The second reason is the network effect, a chicken-and-egg trap. End-to-end encryption requires both parties to be set up. If your colleague, your doctor, or your mother doesn't use PGP, you simply cannot send them an encrypted message — you fall back to ordinary email. The value of encryption to you depends on everyone you email also having it, but they won't adopt it until enough people they email do. So almost no one does, the default stays unencrypted, and the ecosystem settles into the lowest common denominator: TLS in transit, plaintext to the provider.

The third reason is that providers have strong incentives to read your mail — and several of those incentives genuinely serve you. Spam filtering, malware and phishing detection, full-text search, smart categorization, calendar and travel extraction, and (for ad-supported services) targeting all require the provider to access the plaintext of your messages. End-to-end encryption, by definition, takes that access away. As analyses of the email ecosystem point out, providers that place high value on spam and malware filtering — which require plaintext access — are implicitly opposed to end-to-end encryption. You can't have a provider scan an email it cannot read.

The fourth reason is that the modern features people expect from email are fundamentally hard to deliver over end-to-end encrypted content. If the server can't read your mail, the server can't search it server-side, can't categorize it, can't power the AI summaries and smart replies people increasingly rely on. The industry's center of gravity has moved toward making email more intelligent, not more opaque — and intelligence requires access. That tension between privacy and capability is the central design problem of modern email, and most providers have resolved it firmly on the side of capability.

Even the recent push by big providers into end-to-end encryption underlines how niche it remains. In 2026, Gmail expanded its end-to-end encryption to mobile, but it is gated to specific enterprise and education tiers — Enterprise Plus, Education Plus, Education Standard — not switched on for the billions of ordinary accounts. And as covered above, even that implementation leaves headers and subject lines unencrypted. The signal is clear: end-to-end encryption is treated as a specialized feature for organizations with a specific need, not as the default state of email. For most of us, the default remains "encrypted on the wire, readable by the provider."

Which providers actually offer end-to-end encrypted email?

A handful of providers are built around end-to-end encryption from the ground up, rather than bolting it on. The two best known are Proton Mail and Tuta (formerly Tutanota), and both make E2EE the default for messages between their own users. If you and your correspondent both use Proton, your mail is end-to-end encrypted automatically, with no key juggling on your part — the apps handle the public-key exchange behind the scenes. That seamless experience is the thing classic PGP never delivered, and it's why these providers exist.

Proton Mail uses the OpenPGP standard under the hood. Messages between Proton users are end-to-end encrypted automatically; messages to non-Proton users can be sent end-to-end encrypted via a password-protected link, or sent as ordinary email if you choose. Critically, Proton also applies zero-access encryption to everything stored on its servers — even the non-encrypted mail you receive from outside — so that Proton itself cannot read your stored messages, scan them for ads, or hand them over. The honest caveat, which Proton documents, is that subject lines and the sender/recipient addresses are encrypted at rest but not end-to-end, because the server must read the metadata at the moment it encrypts it.

Tuta takes a comparable approach with a notable advantage: it encrypts the subject line along with the message body, closing one of the metadata gaps that Proton and nearly everyone else leave open. Tuta is fully open source, which lets independent researchers audit its code and verify the encryption works as claimed — a meaningful trust signal in a field where you otherwise have to take a company's word. Tuta also offers a free tier and has rolled out post-quantum cryptography, positioning itself for a future where today's encryption could be threatened by quantum computers. The tradeoff with Tuta is that to keep everything encrypted, it uses its own apps and a non-standard implementation, so classic interoperability with PGP tools is limited.

A few practical realities apply to all of these. First, the seamless end-to-end experience generally only holds within the provider's own ecosystem or via their special link mechanism; email to the outside world still crosses the normal, provider-readable plumbing unless you've both done the setup. Second, choosing one of these providers usually means giving up some of the deep search, AI, and integration features that ad-supported giants offer — that's the privacy–capability tradeoff again, made concrete. Third, none of them escape the metadata limits we covered: who you email and when remains visible to some degree, because email delivery requires it.

If you're weighing a switch, our companion guide on the most secure email providers compares these and others in depth, and our breakdown of how to send an encrypted email walks through the mechanics in Gmail, Outlook, and dedicated clients. The short version: if you want end-to-end encryption to be the effortless default rather than a per-message chore, a purpose-built provider like Proton or Tuta is the realistic path — within the limits of what email can structurally protect.

Do you actually need end-to-end encrypted email?

Now the practical question, the one that should drive your decision: do you need end-to-end encryption, or is the ordinary TLS-plus-at-rest baseline genuinely enough? The honest answer for most people, most of the time, is that the baseline is enough — and pretending otherwise leads to either paralysis or expensive, awkward setups that don't get used. The right answer depends entirely on your threat model: who you're protecting against, and how bad it would be if they read your mail.

Start by naming the threat. In-transit (TLS) and at-rest encryption protect you well against the threats most people actually face: someone snooping on shared Wi-Fi, a thief who steals a server's disks, a random breach of the storage layer. If your concern is "I don't want my email readable by strangers on the network or by some hacker who grabs a hard drive," the standard baseline already handles that, and you don't need to do anything special. Security guides agree: TLS provides adequate protection for routine business communication and anything not subject to strict regulatory requirements.

End-to-end encryption becomes necessary when the provider itself, or anyone who can compel or breach the provider, is part of your threat model. The clearest cases are well established. Healthcare providers transmitting protected health information often need E2EE to meet regulatory requirements like HIPAA. Lawyers discussing client matters use it to preserve attorney-client privilege. Companies handling trade secrets use it against corporate espionage. And journalists protecting sources, activists in hostile jurisdictions, and anyone facing a sophisticated, motivated adversary genuinely need it — for them, "the provider can read this" is an unacceptable risk, not a theoretical one.

There's a sharper version of the test that cuts through a lot of hand-wringing: is the receiving organization itself a threat? If you're emailing a company and you'd be harmed if that company — or anyone who breaks into its email system — read or altered your message, then end-to-end encryption is the answer, because nothing else keeps it out of their readable inbox. If you trust the recipient to handle your mail responsibly once it arrives, the baseline is usually fine. The decision comes down to that one honest assessment.

Weigh the cost against the need, because E2EE is not free in effort. It imposes setup work on both you and your recipient — keys, certificates, compatible software — and that cost is only justified when communication is frequent or the message is genuinely sensitive. For a one-off truly secret document, a password-protected link (which Proton, Tuta, and others offer) is often the pragmatic middle path: end-to-end protection for that message without committing both parties to a permanent PGP setup. The use case below maps the common situations to a clear recommendation.

How do the email encryption types compare side by side?

We've covered each layer and standard in depth; here is the consolidated comparison to keep as a reference. Read it with the three guiding questions in mind — encrypted where, against whom, and who holds the key — and notice how the answer to "who can still read your mail" sharpens as you move down the rows. That last column is the one that actually matters for your privacy.

The pattern to internalize: TLS and at-rest encryption keep outsiders out, and nearly every reputable provider gives you both for free, automatically. End-to-end encryption keeps the provider itself out, and it requires a purpose-built service or deliberate setup with your correspondent. They are not alternatives — a fully protected email uses all three at once. Most email stops at the first two, which is fine for most messages and inadequate for genuinely sensitive ones.

How does AI Emaily protect your mail — and work with E2E providers?

If you've followed the argument this far, you can see the bind modern email puts you in: the providers that give you powerful features tend to read your mail, and the providers that keep your mail private tend to strip those features away. AI Emaily is built to resolve that tradeoff honestly — to be a genuinely private, intelligent inbox — and the most important thing we can do here is be precise about exactly what we protect, because vague privacy claims are the very thing this article warns against.

Let's be clear about what AI Emaily is and isn't, in the vocabulary of this guide. AI Emaily is not an end-to-end encrypted email provider, and we won't pretend to be one — we don't issue you a key pair or claim your provider can't see your mail, because that would be untrue. What AI Emaily is: a private, zero-retention AI email client that sits on top of the accounts you already have, adds real intelligence, and is engineered so that we hold as little of your data as possible and never monetize what we do touch. Here is precisely how that works.

First, encrypted message storage. Where AI Emaily stores message content, it is held with envelope encryption — data encrypted under keys that are themselves protected by a key-management system, never left inline or written to logs. Message bodies live in encrypted object storage, referenced by ID, not sitting in plaintext in a database. This is the at-rest layer from earlier in this article, implemented seriously, so that our storage is resistant to exactly the disk-theft and breach scenarios that at-rest encryption is meant to defend against.

Second, minimum OAuth scopes. When you connect Gmail, Outlook, or any provider, AI Emaily requests the narrowest set of permissions needed to do the job — not blanket access to everything in your account. Connecting through OAuth also means we never see or store your email password; the provider issues a scoped, revocable token, and you can pull it back at any time from your provider's security settings. Least privilege is the principle, and it's enforced at the connection itself.

Third, and most important for the AI question: no training on your mail, and zero retention with model providers. AI Emaily never trains models on your email, full stop. When the AI drafts a reply, summarizes a thread, or triages your inbox, the model processes the content to produce that result and then it's done — we operate on a zero-retention basis with our model providers, so your mail isn't kept to train anyone's model or build a profile. This directly answers the fear that makes people distrust AI email: that their private correspondence becomes training data. With AI Emaily, it does not.

Fourth — and this is the part that connects back to the whole article — AI Emaily works with the provider you choose, including end-to-end encrypted ones. Because AI Emaily layers on top of your existing accounts rather than replacing them, you are free to keep your most sensitive mail on Proton or another E2EE service and connect AI Emaily to the accounts where intelligent automation helps most. You decide where each kind of mail lives. AI Emaily doesn't force you to trade your encryption choice for a smarter inbox; it's designed to respect the choice you've already made.

We pair that with security practices this article has been implicitly arguing for throughout: every send is gated for your approval before anything leaves (no autonomous sending behind your back), actions are audited, AI output is validated before it's rendered, and tracking pixels are blocked by default. The philosophy matches the threat-model thinking above: hold the least data possible, never monetize what we touch, keep you in control, and be honest about the line between what we protect and what only end-to-end encryption can. AI Emaily is free to start, with a Pro plan at $17.99/month billed annually for higher limits and advanced automation. Create an account at app.aiemaily.com/signup and connect your inbox in a couple of minutes.

What should you take away about email encryption?

Email encryption isn't one thing — it's three layers, and the difference between them decides whether your mail is actually private. TLS encrypts your message in transit, hop to hop between servers, and stops eavesdroppers on the wire. At-rest encryption protects your mail while it's stored, and stops a thief who grabs a disk. Both are standard, both are valuable, and neither keeps your provider out, because the provider holds the keys and decrypts your mail constantly to run the service. Only end-to-end encryption — PGP or S/MIME — keeps the provider itself from reading your words.

The reason this matters is that the everyday meaning of "encrypted email" quietly points at the layer most email doesn't have. When Gmail or Outlook says your mail is encrypted, they mean in transit and at rest — true, useful, and not the same as private from the company. Genuine end-to-end encryption stays a specialist choice, blocked by PGP's punishing usability, the network-effect trap, and providers' need to read your mail to filter spam and power features. And even E2EE has a hard limit: it hides what you say, never the metadata — who, when, and usually the subject line stay exposed.

So decide by threat model, not by anxiety. For routine mail, the TLS-plus-at-rest baseline that every reputable provider gives you is genuinely enough. For regulated data, trade secrets, sources, or any case where the provider or recipient organization is part of your threat, reach for end-to-end encryption — a purpose-built service like Proton or Tuta, or a password-protected link for one-off secrets. And never put the secret in the subject line. The single most useful habit you can build is the question we opened with: encrypted where, against whom, and who holds the key?

AI Emaily fits this picture without overclaiming. It won't pretend to be end-to-end encrypted, because it isn't — but it does give you encrypted message storage, minimum OAuth scopes, no training on your mail, zero retention with model providers, approval-gated sends, and the freedom to connect any provider, including E2EE ones. If you want an inbox that's genuinely intelligent and genuinely respectful of your data — and honest about the line between the two — start free at app.aiemaily.com/signup. For the mechanics, read how to send an encrypted email; to choose a backbone, see the most secure email providers; and to go deeper on the surveillance question, read is my email private.