What Is Email Encryption? TLS, PGP, S/MIME, and End-to-End Explained

Email feels private. You type a message, address it to one person, hit send, and it lands in their inbox — so it is natural to assume the words traveled in a sealed envelope, seen only by you and them. That assumption is mostly wrong. By default, an email is closer to a postcard than a sealed letter: it passes through a chain of servers on its way from you to the recipient, and at several points along that chain the contents can, in principle, be read, logged, scanned, or stored by parties who are not you and not the person you wrote to.

This is not a flaw someone introduced; it is how email was designed. The core protocols were written in an era when the network was small, trusted, and academic, and confidentiality was not a goal. Encryption was bolted on later, in layers, by different groups solving different problems — which is exactly why "is my email encrypted?" has no single yes-or-no answer. It depends on which layer you mean, which providers are involved, and whether anyone set up the stronger options that exist but are off by default.

This guide is the plain-English map of all of it. You will learn what email encryption actually is, the three distinct layers it comes in — in transit, at rest, and end-to-end — and why those are not the same thing even though people use the word "encrypted" for all of them. We will walk through how TLS and STARTTLS quietly protect most modern mail, what end-to-end encryption adds and why it is rarer, how PGP and S/MIME work as the two real end-to-end standards, how Proton and Tutanota built whole products around this, where S/MIME fits in the enterprise, and the practical steps that actually move the needle on your privacy.

We will keep it concrete: at least one comparison table laying the encryption types side by side, a worked example of a message traveling from sender to recipient so you can see exactly where it is and is not protected, and a clear-eyed account of what each layer does and does not defend against. Near the end, a short note on how an AI-native email client like AI Emaily relates to all of this — what it encrypts, what it does not change, and the privacy posture behind the AI features.

What is email encryption, in plain English?

Email encryption is the practice of scrambling the contents of a message so that only authorized parties can read it. In its unencrypted form, an email is plaintext — ordinary, readable text and data that anyone who intercepts it can understand at a glance. Encryption runs that plaintext through a mathematical process, using a key, that turns it into ciphertext: a scrambled blob that is meaningless without the corresponding key to reverse it. Decryption is the reverse — applying the right key to turn the ciphertext back into the original readable message.

The whole point is access control through math rather than trust. Instead of hoping that every server, network, and intermediary your email passes through chooses not to read it, encryption makes the contents unreadable to anyone who does not hold the key. If a message is properly encrypted and an attacker captures it mid-flight or copies it off a stolen hard drive, what they get is ciphertext — useless without the key. That is the promise: confidentiality that does not depend on the good behavior of the systems in the middle.

Two related guarantees often ride along with encryption, and it helps to name them so we do not conflate them. Confidentiality means others cannot read the contents. Integrity means others cannot alter the contents without detection — a tampered message fails its check. Authenticity means you can verify who actually sent it. Some encryption schemes (like the end-to-end standards) bundle digital signatures that provide integrity and authenticity alongside confidentiality; basic transport encryption mainly provides confidentiality on a single hop. When someone says an email is "encrypted," they could mean any of these, which is the first source of confusion this guide untangles.

The most important thing to understand up front is that "encrypted email" is not one thing. There are three fundamentally different layers where encryption can happen, and a message can be protected at one layer, all three, or — by default — barely any. The rest of this guide is, in large part, about telling those three layers apart, because the difference between them is the difference between "reasonably private" and "only the recipient can ever read this."

Why is standard email not private by default?

To see why email needs encryption, you have to see how a message actually travels — because it is nothing like the sealed-envelope mental model most people carry. When you hit send, your message does not go straight to the recipient. It goes from your email client to your provider's outgoing mail server, which looks up the recipient's domain, finds the responsible mail server, and hands the message off across the public internet. The receiving server accepts it, files it into the recipient's mailbox, and waits for them to fetch it with their own client. Several independent machines, often run by different companies, touch your message between "send" and "read."

The protocols that move mail between those machines — SMTP for sending between servers, IMAP and POP for retrieving it — were standardized decades ago, and in their original form they carried everything in plaintext. SMTP, the protocol that hands your message from server to server, had no built-in confidentiality at all: the message body, the subject line, the sender and recipient addresses, all of it crossed the wire as readable text. Anyone positioned on the network path — a malicious actor on the same Wi-Fi, an internet provider, a compromised router — could read it. That is the "postcard" problem: the contents are exposed to everyone who handles the card.

There is a second, separate exposure: storage. Even if every hop were perfectly protected, your email does not vanish after delivery. It sits on the recipient's mail server, in their mailbox, often indefinitely. It also sits on your own provider's server in your sent folder. If that stored mail is kept as plaintext and the server is breached, or accessed by an insider, or handed over under legal compulsion, the contents are right there to read. Protecting the journey does nothing for the resting place, and vice versa — which is exactly why "in transit" and "at rest" are different problems with different solutions.

The metadata problem is worth naming on its own, because it survives most encryption schemes. Even when a message body is fully encrypted, the envelope information — who sent it, who received it, when, the subject line in many setups, the size, the routing path recorded in the headers — frequently remains visible. Encryption that protects the contents may leave a rich trail of who-talked-to-whom-and-when. For many privacy questions, that metadata is nearly as revealing as the contents. No mainstream email encryption fully solves metadata exposure, and any honest explanation of email privacy has to say so plainly.

What are the three layers of email encryption?

The single most useful frame for understanding encrypted email is that protection happens at three distinct layers, each defending against a different threat. Mixing them up is the root of nearly every misconception about email privacy, so it is worth holding them clearly apart. The three are: encryption in transit, encryption at rest, and end-to-end encryption.

Encryption in transit protects the message while it moves between machines — your client to your server, your server to the recipient's server, their server to their client. The standard mechanism is TLS (Transport Layer Security), usually negotiated for email via a command called STARTTLS. It builds an encrypted tunnel for each hop, so a network eavesdropper sees only ciphertext on the wire. Crucially, the protection is hop-by-hop: at each server along the path, the message is decrypted, handled, and re-encrypted for the next leg. The servers themselves can read it.

Encryption at rest protects the message while it is stored — sitting in a mailbox on a server or cached on a device. The provider encrypts the data written to disk, so a stolen drive or a raw database dump yields ciphertext rather than readable mail. But the provider holds the keys and decrypts the data to serve it to you (and to scan it for spam, search, and features), so at-rest encryption protects against physical theft and certain breaches — not against the provider itself.

End-to-end encryption (E2EE) is the strongest layer and the genuinely different one. The message is encrypted on the sender's device and can only be decrypted on the recipient's device. No server in between — not even the sender's or recipient's email provider — ever holds the keys or sees the plaintext. The contents are readable only by the two endpoints, which is precisely what "end to end" means. This is the layer people imagine when they say "encrypted email," but it is the layer that is off by default and requires extra setup or a provider built specifically for it. Here is how the three compare directly.

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

Encryption in transit is the layer doing the quiet, invisible work behind almost all modern email, and it is built on TLS — the same Transport Layer Security protocol that puts the padlock on your web browser. When two systems speak TLS, they negotiate a shared secret and use it to encrypt everything they exchange, so anyone watching the network sees only ciphertext. For email, TLS gets applied to each leg of the journey: your client to your outgoing server, that server to the receiving server, and the receiving server to the recipient's client.

The mechanism most often used to turn on TLS for server-to-server mail is STARTTLS. It is a command rather than a separate secure port: two mail servers begin a normal, plaintext SMTP conversation, and one issues STARTTLS to say "let's upgrade this connection to encrypted before we send anything sensitive." If both support it, they perform a TLS handshake and the rest of the exchange — including the message itself — travels encrypted. This is opportunistic encryption: it protects the connection when both ends agree to, and the upgrade happens transparently in the background.

The strength of in-transit encryption is that it is broadly deployed and requires nothing from you. The major providers — and most well-run mail servers — use TLS between each other as a matter of course, so the typical message between two large providers is encrypted on every hop without anyone lifting a finger. That defeats the classic postcard threat: a person sniffing traffic on a shared network, or an intermediary tapping a link, sees scrambled data rather than your words. For the everyday risk of casual interception, TLS is genuinely effective.

But in-transit encryption has two structural limits you must understand. First, it is hop-by-hop, not end-to-end: at every server on the path the message is decrypted, processed, and re-encrypted for the next hop. Each of those servers — your provider, the recipient's provider, any relay in between — handles the plaintext. TLS hides your mail from the network, not from the mail systems. Second, opportunistic STARTTLS can, in principle, be stripped: a network attacker positioned between two servers can interfere with the upgrade so the connection silently falls back to plaintext, unless stricter policies (like MTA-STS or DANE) are in place to require encryption and refuse to downgrade. So TLS is necessary, widely present, and worth having — but it is not the same as "only the recipient can read this."

How does encryption at rest work, and what does it not protect?

Encryption at rest covers your message during the long stretches when it is not moving — sitting in a mailbox on a server, or cached in a local database on your laptop or phone. The provider (or your device) encrypts the data as it is written to storage, so the bytes on disk are ciphertext. If a drive is stolen, a backup tape is lost, or someone obtains a raw dump of the storage system, what they recover is scrambled rather than your readable mail. That is the threat at-rest encryption is built to handle: physical theft of media and certain kinds of infrastructure breach.

Most large, reputable providers encrypt stored mail at rest as standard practice, and modern devices encrypt their local storage too. It is a sensible baseline and you should expect it. But its protection is bounded by a fact you cannot wish away: in standard, provider-managed at-rest encryption, the provider holds the keys. They have to — they decrypt your mail to display it to you, to index it so search works, to filter spam, to power features, and increasingly to drive AI assistance. The data is encrypted on disk but routinely decrypted in normal operation, with keys the provider controls.

That control is what at-rest encryption does not protect against, and it is essential to be honest about it. Because the provider holds the keys, at-rest encryption does not stop the provider's own systems or staff from accessing your mail, does not prevent the provider from scanning contents for the features they offer, and does not by itself shield your mail from a legal demand served on the provider, who can decrypt and hand it over. It defends the data against outsiders who grab the storage; it does not put the provider on the outside. That is the precise line between at-rest encryption and end-to-end encryption.

It is worth separating at-rest encryption from one stronger variant: zero-access (or zero-knowledge) encryption, which some privacy-focused providers offer. There, mail is encrypted so that even the provider cannot decrypt the stored contents — the keys are derived from the user and not retained by the provider in usable form. That moves the provider to the outside of the trust boundary for stored mail, but it constrains features that need to read your content (server-side full-text search, for instance, has to be re-engineered or limited). Most mainstream at-rest encryption is provider-managed, not zero-access — a distinction worth checking when privacy matters.

What is end-to-end encryption (E2EE) and how does it work?

End-to-end encryption is the layer that delivers the privacy most people picture when they imagine "encrypted email." The message is encrypted on the sender's device before it leaves, and it can only be decrypted on the recipient's device. Every machine in between — the sender's mail server, the recipient's mail server, any relay, any backup system — only ever sees ciphertext. They route and store a scrambled blob they cannot read. The contents are legible only at the two ends, the sender and the recipient, which is the literal meaning of "end to end."

The trick that makes this work without the two parties having to secretly share a password is public-key (asymmetric) cryptography. Each person has a pair of mathematically linked keys: a public key, which they hand out freely to anyone, and a private key, which they guard and never share. The two keys are linked so that anything encrypted with the public key can only be decrypted with the matching private key. That asymmetry is the whole foundation — it lets a stranger send you a message only you can open, without either of you ever transmitting a shared secret.

Walk through one message. You want to send Maria an encrypted email. You obtain Maria's public key (she publishes it, or sends it to you). Your software encrypts the message with Maria's public key, producing ciphertext. That ciphertext travels through all the servers as usual — they see only the scramble. When it reaches Maria, her software uses her private key — which never left her device and which no server ever had — to decrypt it back into the readable message. Because only Maria's private key can undo what her public key locked, only Maria can read it. To reply, she encrypts with your public key, and only your private key can open it.

In practice, the encryption layers two techniques for speed: the software generates a random one-time symmetric key to encrypt the actual (potentially large) message body quickly, then encrypts just that small symmetric key with the recipient's public key. The recipient uses their private key to recover the symmetric key, then uses it to decrypt the body. This hybrid approach is invisible to users but is how every real E2EE email system works under the hood. The two standards that implement all this for email are PGP and S/MIME, which the next section compares.

PGP vs S/MIME: what is the difference?

There are two real standards for end-to-end encrypting email, and they solve the same problem with different trust models. PGP (Pretty Good Privacy), in its open form OpenPGP, and S/MIME (Secure/Multipurpose Internet Mail Extensions). Both use the public-key approach described above; the difference is in how you come to trust that a given public key really belongs to the person you think it does — the key-distribution and identity problem, which is the genuinely hard part of any encryption system.

PGP uses a decentralized trust model often called the web of trust. There is no central authority. You generate your own key pair, publish your public key (to a keyserver or directly to contacts), and trust is established peer-to-peer: people vouch for each other's keys by signing them, and you decide whom to believe. This is flexible, free, and beholden to no company — which is why it is popular with journalists, activists, developers, and privacy advocates. The cost is friction: you manage keys yourself, you have to obtain and verify each correspondent's key, and the user experience has historically been notoriously fiddly.

S/MIME uses a centralized trust model built on certificate authorities (CAs), the same hierarchy that issues website certificates. Your identity is bound to your key by a certificate that a trusted CA issues and vouches for. Because the trust is anchored in recognized authorities and integrates cleanly with managed environments, S/MIME is the standard that dominates the enterprise: it is built into Outlook and Apple Mail, and organizations can issue and manage certificates for all employees centrally. The trade-off is that you depend on the CA system and typically on an organization to provision and manage the certificates — less suited to a lone individual, well suited to a company.

A practical wrinkle: PGP and S/MIME do not interoperate. A message encrypted with one cannot be read by a client set up only for the other, so in practice both sender and recipient need to be using the same standard with each other's keys already exchanged. That mutual-setup requirement — both sides equipped, keys traded in advance — is a large part of why neither standard ever became the default for ordinary email. Here is the comparison side by side.

How do Proton Mail and Tutanota approach encrypted email?

Because classic PGP and S/MIME are too fiddly for most people, a category of privacy-first providers grew up to make end-to-end encryption something you get by default rather than something you assemble yourself. The two best-known are Proton Mail and Tutanota (now Tuta). Both are built on the same core promise: the provider stores your mail in a form it cannot read, so the trust model that defines mainstream email — "we hold your keys and could read your mail" — is inverted.

Proton Mail is built on OpenPGP, but it hides the hard parts. Key generation, key exchange, and encryption happen automatically inside the client, so a user does not manually wrangle keys. When you email another Proton user, the message is end-to-end encrypted between you without any setup. Your stored mailbox is held with zero-access encryption — encrypted so that Proton itself cannot read the contents at rest. Proton is also explicit about what its model does and does not cover: the message body is protected, but some metadata (such as subject lines in certain cases, and sender/recipient routing) is more exposed than the body, an honest limit that applies to essentially every email system.

Tutanota built its own encryption rather than adopting PGP, which let it encrypt more of the mailbox — including, notably, subject lines and the address book — but at the cost of standard interoperability: it does not speak PGP or S/MIME to outside clients in the usual way. Both providers solve the universal problem of "how do I send encryption to someone who isn't on my secure provider?" with the same clever fallback: the recipient gets a notification and opens the message through a secure web page, unlocking it with a password the sender shares with them out of band. That bridges E2EE to people who are not set up for it, at the cost of a small extra step.

What these providers really sell is a different default. With a standard provider, your mail is private from outsiders but readable by the provider; with Proton or Tutanota, the contents of stored mail are readable only by you and your correspondents, with the provider designed to be unable to decrypt them. That is a meaningful upgrade for people who need it. The honest trade-offs: encrypted mail to non-users still relies on the password-protected web fallback, server-side features that require reading content (like deep full-text search) are constrained, and metadata is still not fully hidden. The model is stronger privacy in exchange for a few accommodations — exactly the kind of trade you should make deliberately rather than by accident.

Where does S/MIME fit in the enterprise?

While PGP found its home with individuals and Proton-style providers serve privacy-conscious consumers, S/MIME is the encryption standard that quietly runs inside large organizations. The reason is structural: S/MIME's certificate-authority trust model maps cleanly onto how companies already work. An organization can stand up its own certificate infrastructure or buy certificates from a CA, then issue one to every employee, binding each person's identity to their key automatically. Individuals never touch the cryptography; IT provisions it centrally, the way it provisions everything else.

Mainstream business mail clients support S/MIME natively. Microsoft Outlook and Apple Mail both handle S/MIME signing and encryption without plugins, so once certificates are deployed to devices, encrypting or digitally signing a message is a built-in action rather than an add-on. That native support is decisive for adoption — a security control that requires every employee to install and configure third-party software does not scale, while one baked into the client they already use does.

In the enterprise, S/MIME usually delivers two things at once, and the second is often the bigger draw. Encryption protects message confidentiality, but digital signing — the other half of S/MIME — provides authenticity and integrity: a signed message proves it genuinely came from the claimed sender's certificate and was not altered in transit. For organizations fighting impersonation, business email compromise, and forged internal mail, signing every outbound message so recipients can verify it is a powerful control, sometimes deployed even where full encryption is not. (Signing and encryption are independent; you can do either or both.)

S/MIME also fits the compliance and governance needs that regulated industries carry. Centralized certificate management means an organization can enforce policy, manage the lifecycle of keys, and — importantly — retain the ability to recover encrypted mail when an employee leaves or a legal hold requires it, via escrowed or organization-held keys. That recoverability is a feature for a company and a limit on absolute end-to-end secrecy, which is the deliberate trade enterprises make: strong protection against outsiders and impersonators, combined with the organizational control and auditability that running a business requires.

What practical steps actually protect your email privacy?

It is easy to come away from a topic this layered feeling that real email privacy requires a cryptography degree. It does not. The honest reality is that a handful of practical steps cover the great majority of ordinary risk, and only a narrow set of genuinely sensitive situations call for the heavy machinery of full end-to-end encryption. The right move is to match the effort to the threat, not to either ignore the problem or over-engineer it.

Start with the baseline that helps everyone. Use a reputable provider that encrypts in transit (TLS) and at rest as standard — the major ones do — so casual interception and stolen-drive scenarios are already covered. Protect the account itself, because in practice the most common way email gets read by someone unauthorized is not interception but account compromise: use a strong, unique password and turn on multi-factor authentication. All the transport encryption in the world does nothing if an attacker simply logs in as you. Be cautious on untrusted networks and keep your client and devices updated so the TLS your mail relies on is current.

Step up the protection when the contents genuinely warrant it. If you regularly handle sensitive material and want the provider out of the picture, move to a privacy-first provider like Proton or Tutanota, where end-to-end and zero-access encryption are the default and you do not manage keys. If you need to exchange truly confidential messages with specific people, set up PGP or S/MIME with them — accepting that both sides must be equipped and keys exchanged in advance. And for the most sensitive conversations, consider whether email is even the right channel: a dedicated end-to-end encrypted messenger may fit better than retrofitting email.

Finally, mind the parts encryption does not cover, because that is where false confidence lives. Remember that metadata — who you wrote to, when, and often the subject line — typically survives even strong content encryption, so encryption is not anonymity. Treat attachments with the same care as the body, since an encrypted email with the wrong attachment policy can still leak. And recognize that the endpoints are the weak link: if your device is compromised or your account is breached, encryption that protects mail in transit and at rest cannot save a message that an attacker can read right off your own screen. Good privacy is layered — encryption is necessary, but account security and device hygiene sit right beside it.

What about metadata, signatures, and the limits of encryption?

Any honest explanation of encrypted email has to spend a moment on what encryption does not do, because the gaps are where people get a false sense of security. The biggest gap is metadata. Even a perfectly end-to-end encrypted message usually still reveals the envelope: the sender and recipient addresses, the timestamp, the message size, the routing path recorded in the headers, and — depending on the system — the subject line. To anyone analyzing communications, that pattern of who-contacted-whom-and-when is often as telling as the words inside. Encryption protects the letter; it rarely hides the fact that you mailed it, to whom, and on what day.

The subject line deserves a specific call-out because it surprises people. In standard PGP and S/MIME, and even in some privacy providers, the subject line is treated as part of the routing envelope rather than the encrypted body, so it can travel in the clear or be visible to the provider. The practical rule that follows is simple: never put anything sensitive in a subject line, regardless of how the body is protected. Tutanota's choice to encrypt subject lines is precisely a response to this common leak.

On the positive side, encryption's companion feature — the digital signature — closes a different gap, and it is worth understanding as its own tool. A signature does not hide the contents; it proves authorship and integrity. Signing uses the keys in reverse: the sender signs with their private key, and anyone can verify with the sender's public key that the message genuinely came from them and was not altered. This is the backbone of authenticity in S/MIME and PGP, and it is the property that helps fight forged and tampered mail even when confidentiality is not the goal.

The last limit to internalize is that encryption protects messages in motion and at rest, not endpoints. If your laptop is infected with malware, or someone gains access to your logged-in account, the strongest end-to-end encryption in the world does nothing — the attacker reads the decrypted message exactly as you do, on the device where it is meant to be readable. This is why security professionals insist that encryption is one layer in a stack, not a complete solution: it must sit alongside endpoint security, account protection, and careful handling of attachments and links. Encryption is essential and it is not magic, and understanding both halves of that sentence is what separates real privacy from the comfortable illusion of it.

How does email encryption relate to an AI-native client like AI Emaily?

AI Emaily is an AI-native email client — software you use to read, write, and manage the mail in your existing accounts — rather than a new mail provider, so it sits in the part of the encryption picture that touches your devices and your connections rather than replacing how your underlying mailbox is encrypted. It connects to the accounts you already have (Gmail, Outlook, and any IMAP provider), which keep their own in-transit and at-rest encryption; AI Emaily speaks to those servers over encrypted connections and protects the data it handles in transit and at rest, so the encryption posture of your mail is preserved end to end through the client, not weakened by it.

The genuinely relevant question for an AI email client is what happens to your mail when AI features read it — because the entire value of an AI assistant is that it can understand your messages, which means it processes content. AI Emaily's answer is a privacy-by-design posture: your mail is used to help you — to draft, summarize, triage, and search on your behalf — and is not used to train models for anyone else. The processing AI features require is the deliberate, scoped reading needed to do the task you asked for, with a zero-retention stance toward the model providers behind those features, rather than your correspondence becoming training data.

For people who want to keep model access in their own hands, AI Emaily supports bring-your-own-key (BYOK): you can connect your own AI provider key so the AI calls run through your account, and the broader design keeps sensitive handling isolated rather than scattered. The direction of travel for privacy-sensitive AI — and the bar AI Emaily builds toward — is processing that stays as close to your control as possible, including on-device handling where it is feasible, so that the convenience of an AI inbox does not quietly trade away the privacy this whole guide is about.

The honest framing: an AI email client does not turn a standard mailbox into an end-to-end encrypted one — if your mail lives in a conventional Gmail or Outlook account, the provider's reach over that mailbox is unchanged, and that is true of every client you could point at it. What a privacy-respecting client controls is its own behavior: encrypted connections to your accounts, careful handling of the data it touches, AI that works for you without becoming someone's training set, and key control through BYOK. If your need is mailbox-level end-to-end encryption, that is a provider choice (a Proton or a PGP/S/MIME setup); if your need is an AI inbox that treats your mail as yours, that is the line AI Emaily is built on. You can read more about the security model on the security page and how it compares on the compare page.

The bottom line on email encryption

Email encryption is the practice of scrambling a message so only authorized parties can read it — and the single most important thing to carry away is that it comes in three distinct layers, not one. In transit (TLS/STARTTLS) protects your mail as it moves between servers but leaves every server on the path able to read it. At rest protects stored mail from stolen drives and breaches but leaves the provider, who holds the keys, able to read it. End-to-end (PGP or S/MIME) is the only layer that locks the provider out, making a message readable solely by sender and recipient.

Standard email is not private by default because it was designed without confidentiality, traveling as plaintext across multiple servers and resting as plaintext at the destination. TLS now quietly protects most modern mail in transit, and good providers encrypt at rest — that baseline, plus a strong password and multi-factor authentication, covers the realistic risk for most people. End-to-end encryption, whether through a privacy-first provider like Proton or Tutanota or a deliberate PGP/S/MIME setup, is the upgrade for genuinely sensitive messages where the provider must not be able to read the contents.

Keep the limits in view: metadata and often the subject line survive even strong encryption, and no encryption protects a compromised device or a breached account, so privacy is always layered. And remember the distinction between the mailbox and the client — a provider sets your mailbox's encryption, while an AI-native client like AI Emaily preserves that encryption, talks to your accounts over encrypted connections, and treats your mail as yours rather than as training data. Match the protection to the threat, secure the account as carefully as the message, and you have understood email encryption better than most people who use it every day.