Most people assume email is private, and it is not. A message is readable by every server that handles it, and by anyone who can read those servers' storage. Transport encryption now covers most hops, but the message itself is usually plaintext at each stop. To understand why, it helps to look at how email was designed and what it was asked to do.
Designed for relaying, not privacy
The Simple Mail Transfer Protocol, described in RFC 821 in 1982, moves messages from one server to the next. Each server accepts a message, stores it, and forwards it toward the destination. This store-and-forward model lets mail reach hosts that are not online at the same time, and it lets a message travel through several relays. The model assumes every relay will read the message's envelope and headers in order to route it, and in the early network that was a reasonable assumption among trusted institutions.
SMTP has no built-in authentication and no encryption. A server announces itself, accepts the mail, and the protocol trusts what it is told. Identity and privacy were not part of the core design.
Encryption arrived in layers
- PGP, 1991. Pretty Good Privacy brought public-key encryption and signing to the masses. It encrypts the message body and attachments end to end, but it is a separate step, and the message headers, including the subject line, stay in plaintext.
- MIME, 1996. The Multipurpose Internet Mail Extensions standard let messages carry non-text content and multiple parts. It made encrypted and signed parts possible, but did not change routing.
- S/MIME, 1999. S/MIME uses X.509 certificates and is built into many clients. It depends on a certificate infrastructure, which many individuals found difficult to set up and manage.
- STARTTLS, 1999 to 2002. The SMTP extension defined in RFC 2487 and then RFC 3207 lets two servers upgrade a connection to TLS. It protects the hop, not the message at rest on each server.
Each layer solved part of the problem, and each left gaps. Transport encryption is opportunistic in most server-to-server delivery, which means an attacker who can interfere with the connection can often force a fallback to plaintext. Strictly enforcing TLS requires policy on the receiving side, such as MTA-STS, which is designed to tell senders when TLS is required.
Why end-to-end encryption is hard for mail
Several design features of email make end-to-end encryption difficult to deploy for everyone:
- Key discovery. A sender needs the recipient's public key before encrypting. Email has no built-in directory, so keys must be published, fetched, verified or trusted through some other mechanism.
- Multiple recipients. A message to a group must be encrypted for each recipient's key, or be wrapped for all of them. Adding or removing recipients changes the message.
- Mailing lists and forwarding. Lists modify headers and bodies, such as adding footers. Forwarding and autoresponders re-send content. Each change can break a signature or make the content unreadable.
- Search, filtering and spam control. Server-side filters and spam classifiers read content. Encrypting everything removes that ability unless it is done on the client, which shifts the work to each device.
- Metadata remains. Even with encrypted bodies, the sender, recipient, time and size are visible to the relays that route the message. That is discussed in metadata is the leak.
Why the defaults stayed plaintext
Encrypting by default would have broken much of what made email useful. Interoperability depends on every server being able to read and route the message. A plaintext body allows any compatible client to read it without a key exchange. Many users never managed keys, and a system that produced unreadable messages for them would have been abandoned. The tradeoff favored broad reach and simplicity, and security was added where it could be added without breaking that reach.
What this means today
A reasonable mental model is three separate protections. Transport encryption protects the connection between servers and between a client and its server. Server encryption at rest protects stored mail from some threats, depending on how keys are managed. End-to-end encryption, such as PGP or S/MIME, protects the content from every server, and it leaves the envelope visible. Each one answers a different question.
ITProMail uses TLS for connections, encrypts mail at rest, and supports PGP keys with Web Key Directory publication. The PGP guide explains setup, and PGP in practice covers day-to-day use. Encryption that you control end to end works best when both sides use it, which is why the adoption question matters as much as the cryptography.
Email was not built to be private, and no single feature retrofits that. Understanding the layers lets you choose which protection matters for a given message, rather than assuming that a padlock icon means the whole path is protected.