Email encryption: how it works and the methods compared

Email encryption is the practice of scrambling a message so that only the intended parties can read it, turning readable text into ciphertext that is worthless to anyone who intercepts it. In email there are two very different layers where this happens, and confusing them is the single biggest source of false confidence about privacy. Transport encryption protects mail while it moves between servers on the network, but the provider still decrypts and stores your message in the clear. End-to-end or content encryption is the stronger layer: only the sender and the recipient hold the keys, so the servers in the middle relay ciphertext they cannot open. This guide explains both layers, compares the main methods (S/MIME, PGP, and modern JOSE), and shows how to encrypt a message in practice, including how automated systems and AI agents do it.

Transport encryption: TLS and STARTTLS

Transport encryption is what Gmail, Outlook, and almost every mainstream provider do by default. When one mail server hands a message to the next, the two negotiate a TLS session, often started with the STARTTLS command on an existing plaintext connection, and encrypt the bytes for that single hop. This protects the message on the wire against anyone passively sniffing the network, and it is close to universal today.

The critical limit is that TLS is hop-by-hop, not end-to-end. At every server along the path the message is decrypted, processed, and re-encrypted for the next hop. That means the provider sees the full plaintext and, in almost every case, stores it that way at rest so it can index, search, and display your mail. This is why the common question "is Gmail encrypted" has a nuanced answer: yes, Gmail uses TLS in transit and encrypts messages at rest, but Google holds the keys and can read your message content, which is exactly what makes server-side search and spam filtering work. Encrypted in transit is not the same as private from your provider.

End-to-end encryption: the content stays sealed

End-to-end encryption (E2EE) moves the boundary. Instead of protecting each network hop, it encrypts the content on the sender's device and decrypts it only on the recipient's device, because only the two endpoints ever hold the decryption keys. Every server in between, including the sending and receiving providers, carries ciphertext it structurally cannot read.

The test is simple: who holds the private keys. If the provider can produce a plaintext copy of your mail, the message is not end-to-end encrypted, no matter what the label says. Under transport encryption the provider is a trusted middleman that can read everything; under end-to-end encryption it is a blind relay. That difference is what defends a message against a breach of the provider, a subpoena served to the provider, or a curious insider. For a full walkthrough of the key exchange and the encrypt-to-recipient envelope, see end-to-end encrypted email.

The methods compared

Three families of technology implement content encryption for email. They differ mainly in how you obtain and trust public keys.

S/MIME uses X.509 certificates issued by a certificate authority (CA). Your identity is vouched for by a trusted CA, which makes it the default in corporate and government mail and the reason it is built into Outlook and Apple Mail. See S/MIME email encryption for setup and tradeoffs.

PGP, standardized as OpenPGP, skips central authorities in favor of a web of trust where users sign each other's keys directly. It is powerful and provider-independent, but the manual key management is famously where consumer adoption stalled. PGP encryption and its modern alternatives covers why.

Modern JOSE (JSON Object Signing and Encryption) uses JWE for encryption and JWS for signatures over published JSON Web Keys (JWK). It is the format that web and API systems already speak, which makes it the natural fit for programmatic mail between services.

All three encrypt the body and attachments, but be aware of a shared gap: standard S/MIME and PGP leave the Subject header in the clear, so it travels as plaintext even when the content is sealed.

Zero-knowledge encryption

The strongest form of end-to-end encryption is zero-knowledge: the private key is generated on your device and never touches the server, so even the platform operator cannot decrypt your content. This is a property of key custody, not of the cipher. Two systems can use identical AES-256 encryption, yet one is zero-knowledge because it never holds your key and the other is not because it does. If a provider can generate, escrow, or reset your keys, it can read your mail. Zero-knowledge is what makes a "we cannot read your messages" claim technically true rather than a policy promise. More in zero-knowledge email.

How to encrypt an email in practice

How you actually encrypt a message depends on whether a human or a program is doing it.

For people, S/MIME is built into Outlook and Apple Mail: once your organization installs a certificate, encrypting a message is a toggle in the compose window. For PGP, you generate a keypair with GnuPG on the command line, or use a browser extension like Mailvelope that adds PGP to Gmail and other webmail without leaving the browser. In both cases you must exchange public keys with your recipient before the first encrypted message.

For developers and automated systems, manual keyrings do not scale. Here you want an API with an SDK or CLI that handles key generation, publishing, encryption, and decryption for you, so encryption becomes a config flag rather than a research project. That is the model of an encrypted email API, and how to send encrypted email walks through it end to end.

Email encryption for AI agents

An AI agent cannot sit at a mail client managing keyrings and clicking an encrypt toggle. It needs encryption that is programmatic and automatic, applied the same way on every send without a human in the loop.

AgenticEmail is API-first email infrastructure for AI agents, and its end-to-end encryption is built for exactly this. It uses standards-based JOSE: a JWE envelope with ECDH-ES key agreement over the P-256 curve and AES-256-GCM content encryption, wrapping an Ed25519 JWS that signs the payload under a sign-then-encrypt construction. It is zero-knowledge, so the private key is generated and kept client-side by the SDK or CLI and never reaches AgenticEmail's servers. Peers are found by address through published-key discovery, so an agent resolves a recipient's key and encrypts to it with no manual key exchange.

Be clear-eyed about the boundaries. Encryption is opt-in and plaintext is the default, exactly like a normal transactional email API. It works only between two AgenticEmail inboxes that have each published a key, so it is an agent-to-agent feature, not a consumer product. You cannot end-to-end encrypt to an external Gmail or Outlook address, because that mailbox has no key on the discovery endpoint, so mail to the outside world goes as plaintext. And because the private key lives only on your side, losing it means old encrypted mail is unrecoverable, since there is no server-side copy to restore from. Those constraints are the honest cost of real zero-knowledge encryption. See encrypted email for AI agents for the agent-to-agent patterns, and the docs for the full endpoint reference.

Frequently asked questions

What is the most secure email encryption?

The most secure setup is zero-knowledge end-to-end encryption, where the message is encrypted on your device, relayed as ciphertext, and decrypted only by the recipient, with private keys that never touch the server. S/MIME, PGP, and modern JOSE all provide strong content encryption. What makes any of them most secure in practice is key custody, meaning the private key stays on the endpoint, not the name of the cipher.

Is Gmail end-to-end encrypted?

No. Gmail uses TLS in transit and encrypts messages at rest, but Google holds the keys and can read your message content, which is what powers search and spam filtering. That is transport and at-rest encryption, not end-to-end encryption. True end-to-end would require the keys to live only on the endpoints.

What is the difference between TLS and end-to-end encryption?

TLS, often started with STARTTLS, encrypts each network hop between mail servers, so the message is decrypted and re-encrypted at every server along the way and the providers see plaintext. End-to-end encryption keeps the content sealed from the sender's device to the recipient's device, so no server in the middle can read it. TLS protects the connection, while end-to-end protects the message itself.

How do I encrypt an email?

For people, use S/MIME built into Outlook or Apple Mail, or PGP through GnuPG or a browser extension like Mailvelope, after exchanging public keys with your recipient. For software, use an email API with an SDK or CLI that handles key generation, publishing, encryption, and decryption for you. How to send encrypted email covers both paths.

Can AI agents send encrypted email?

Yes. With AgenticEmail an agent sends end-to-end encrypted mail programmatically using JOSE, specifically JWE with ECDH-ES over P-256 and AES-256-GCM plus Ed25519 signatures, with the private key kept client-side. It is opt-in and works between two AgenticEmail inboxes that have published keys, not to external addresses like Gmail.