Email Encryption: TLS, S/MIME, PGP
Encryption in Transit and End-to-End Encryption
Email encryption is the use of cryptography to stop messages being read by anyone other than their intended recipients. It takes two main forms: encryption in transit, which protects messages while they travel between servers and devices, and end-to-end encryption, which protects them from the sender's device to the recipient's.
Much email is now encrypted in transit, but only where both servers support it. Transport Layer Security (TLS) is the protocol that does this. When two servers connect, they may agree to upgrade the connection to TLS using a command called STARTTLS. The encryption is opportunistic: if the other server does not support it, the message may still be sent in plain text.
Transport encryption has a limit. Each mail server on the route receives the message in decrypted form, so the operators of those servers can read it, and the stored copy is only as protected as the provider's own storage. It guards against eavesdropping on the network, not against the mail providers themselves.
S/MIME and PGP: Two End-to-End Options
S/MIME uses X.509 certificates, issued by a certificate authority, to identify users. It is built into many mail clients. The sender encrypts a message with the recipient's public certificate, and only the recipient's matching private key can decrypt it. S/MIME can also sign messages, which proves who sent them and that they were not changed.
PGP (Pretty Good Privacy) and its open standard, OpenPGP, use key pairs that users create themselves. Trust is established by checking that a key really belongs to the person, either directly or through people who vouch for it. PGP is common among developers and privacy-minded users, but it takes more effort to set up than the defaults in most mail clients.
Both systems need each party to hold a key or certificate, and that is the main barrier to adoption. In practice, a message is only end-to-end encrypted when both sides have set it up.
Protecting Server-to-Server Delivery
Because opportunistic TLS falls back to plain text when the upgrade fails, an attacker on the network path can block the upgrade and force unencrypted delivery. Standards such as MTA-STS let a domain require that mail is delivered to it only over verified TLS.
Ports matter as well. Mail clients usually connect to their server, and retrieve mail from it, over TLS on dedicated ports. The email ports explained article covers which ports carry encrypted connections and why they differ.
Frequently asked questions
Does email encryption prove who sent a message?
Not by itself. Encryption hides the content from people who should not read it, while a digital signature proves who sent it and that it was not changed. S/MIME and PGP can do both. TLS only protects the connection between two servers, so it says nothing about the identity of the person who wrote the message.
Is TLS enough to protect sensitive email?
It protects the connection, but not the message as it is stored on each server or handled by the people who run those servers. For highly sensitive content, many organizations add end-to-end encryption or use a different channel altogether. The right choice depends on the risks involved and on what the recipient is able to use.