Email Encryption Explained: TLS, S/MIME, and PGP for Business

Email was not designed with privacy in mind. The original SMTP protocol sends messages as plain text — anyone who handles them along the way can theoretically read them. That's changed significantly over the decades, but the protection you actually get depends on which type of email encryption is being used and where it applies.

This guide covers the three main approaches to email encryption — TLS for transport, S/MIME for certificate-based end-to-end encryption, and PGP as an open alternative — explaining what each protects, what it doesn't, and how businesses typically use them.

Transport Encryption vs End-to-End Encryption

Before diving into specifics, it helps to draw a clear line between two very different things.

Transport encryption (usually TLS) protects email while it's moving between servers. The message is encrypted in transit but is decrypted when it arrives at each mail server along the route. The server operators — your email host, the recipient's host — can access the content.

End-to-end encryption (S/MIME or PGP) protects the message content itself. It's encrypted by the sender and can only be decrypted by the intended recipient. Even if someone intercepts it at a mail server, they can't read it without the private key.

Both matter. For most business email, transport encryption is the baseline — end-to-end encryption is reserved for sensitive communications where even the email provider shouldn't be able to read the content.

TLS: The Baseline for Email in Transit

Transport Layer Security (TLS) is the protocol that encrypts the connection between mail servers as a message travels from sender to recipient. When both servers support TLS, the handshake happens automatically and the message travels encrypted.

The practical issue is that TLS is opportunistic by default. If one server doesn't support it, many configurations will fall back to plain text rather than reject the delivery. This is being addressed by standards like MTA-STS, which lets you declare that your domain requires TLS for inbound delivery — if a sending server can't establish a TLS connection, it should reject the delivery rather than send unencrypted.

For outbound sending, your email host and SMTP relay should enforce TLS on all client connections. MailDog's SMTP infrastructure requires TLS for all submissions and attempts TLS on all outbound deliveries to recipient servers.

S/MIME: Certificate-Based End-to-End Encryption

S/MIME (Secure/Multipurpose Internet Mail Extensions) is the standard most enterprises use for end-to-end encrypted email. It uses digital certificates issued by a certificate authority — similar to the certificates used for HTTPS websites — to encrypt messages and verify sender identity.

Here's how it works in practice:

1. Each participant obtains an S/MIME certificate containing their email address and a public/private key pair.
2. When you send an encrypted email, you use the recipient's public key to encrypt it.
3. Only the recipient's private key can decrypt it.
4. You can also digitally sign messages with your own private key, giving recipients cryptographic proof that the message came from you and wasn't altered in transit.

S/MIME is supported natively in Outlook, Apple Mail, and most enterprise email clients. The friction point is key exchange — before you can send someone an encrypted S/MIME message, you need their public key, which typically comes from a signed email they sent you first or from a directory service.

For organizations, deploying S/MIME usually means purchasing certificates for employees or using an internal certificate authority, then configuring clients to apply them automatically. It's not plug-and-play at scale, but it's the most widely supported standard for encrypted business email.

PGP: The Open Alternative

PGP (Pretty Good Privacy) and its open-source implementation GPG (GNU Privacy Guard) work on the same public/private key principle as S/MIME but use a different trust model. Instead of relying on certificate authorities, PGP uses a "web of trust" — keys are signed by people who vouch for their authenticity.

PGP is more common in technical and open-source communities than in corporate environments. It isn't natively supported in most email clients without plugins, which creates a higher setup bar for non-technical users. For protecting sensitive individual communications — a developer sending credentials, a security researcher sharing findings — PGP is a practical choice. For company-wide deployment requiring a consistent, auditable system, S/MIME is typically easier to manage.

Email Signing vs Email Encryption

Both S/MIME and PGP support two related but distinct functions: signing and encryption.

• Signing attaches a cryptographic signature to the message proving it came from you and wasn't modified. It doesn't prevent others from reading the content.
• Encryption scrambles the content so only the intended recipient can read it. Without signing, an encrypted message doesn't verify who sent it.

It's common to sign messages without encrypting them — particularly for executive communications where authenticity matters but secrecy doesn't. Combined signing and encryption provides both guarantees simultaneously.

What Email Encryption Doesn't Protect

It's important to be realistic about what encryption covers. End-to-end encryption protects message content, but it doesn't hide metadata — who sent it, when, to whom, and the subject line are often still visible to servers handling the message. TLS protects the message in transit but not once it's stored on a server. And no encryption protects against a compromised endpoint — if someone's device is infected with malware, encrypted messages can still be read after they're decrypted locally.

Encryption is one layer of a broader security posture. It works alongside multi-factor authentication, strong access controls, and regular security reviews — not as a replacement for them.

For a look at how domain-level DNS security records protect against spoofing and phishing — a different but equally important layer — visit MailDog's DNS security tools. If you have questions about configuring your email infrastructure for maximum security, our team is available to help.