Email encryption protects different parts of a message

1. Device to provider

TLS encrypts the connection. PKI certificates help confirm the server's identity.

2. Provider to provider

Opportunistic TLS can fall back to plaintext. MTA-STS and DANE can require authenticated TLS.

3. Stored on disk

At-rest encryption protects stolen disks. Providers usually hold the keys.

4. Message content

S/MIME or OpenPGP can restrict reading to endpoints. Email headers stay visible.

Key question: Who holds the key, and at which stage can they read the message?

Transport encryption protects links, with different server guarantees

Device to provider

  • TLS 1.3 encrypts traffic between your device and mail service.
  • PKI certificates help confirm you reached the right server. Certificate Transparency makes issued certificates auditable.
  • HSTS and TLS-only ports discourage or prevent unencrypted connections.

Between mail servers

  • Opportunistic TLS encrypts when available, but may fall back to plaintext. A man-in-the-middle can try to force that downgrade.
  • MTA-STS can require TLS with a valid certificate. Delivery may pause or fail when the policy cannot be met.
  • DANE binds TLS records through DNSSEC, reducing CA dependence while adding deployment and availability risk.

Encryption on a connection ends at the server. It does not make stored mail unreadable to that provider.

Stored-mail protection depends on who controls the keys

Encryption at rest

Key holder: Mail provider.

Helps against: Stolen or retired disks.

Does not prevent: Provider access, a valid legal request, or compromise of a live server where keys are available.

Zero-access storage

Key holder: User's password-derived key, unlocked locally.

Helps against: Provider insiders and access to stored content.

Still exposed: Metadata, sender copies, and new mail before end-to-end encryption protects it. A compromised web app may alter decryption code.

Functionality trade-off

When the provider cannot read mail, server search, standard IMAP/JMAP clients, account recovery, support, and some security scanning can be constrained.

End-to-end encryption can shield content from mail providers

Sender device

Encrypts with the recipient's public key.

Mail servers

Carry the encrypted body. To, From, and Date remain visible.

Recipient device

Decrypts with its private key.

S/MIME

Uses certificates from Certificate Authorities. It fits organisations with established internal key directories.

OpenPGP

Uses a Web of Trust. The article highlights key discovery, verification, metadata leakage, and rotation as barriers.

Trade-off and takeaway

End-to-end encryption limits server search and content scanning. The article frames email security as a spectrum, and recommends dedicated encrypted messaging for high-risk communication.

Format document
General
px
Colors
▶ Headings
▶ Blocks

Default for code blocks, blockquotes, and charts. Override individually below.

▶ Code
▶ Blockquote
▶ Charts
▶ Tables
Headers
▶ General h1–h4
em
▶ H1 h1
em
▶ H2 h2
em
▶ H3 h3
em
▶ H4 h4
em
Paragraph
em
Lists
em
em
Links
Code
Blockquote
px
em
Save as default styles
  • Requires sdocs-dev CLI
    • Install: npm link from project root
  • Saves to ~/.sdocs/styles.yaml
  • Paste the command below in your terminal

        
      
Export document
100% private Open source: verify server CLI for you & your agents: Copy install promptcurl -fsSL https://smalldocs.org/install | sh Discord GitHub For business You agree to our Terms