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

Most organizations have email encryption on their security checklist, but the term covers three fundamentally different technologies that protect different things. TLS encrypts the connection between mail servers. S/MIME and PGP encrypt the message content itself. Understanding which threat each addresses — and where each falls short — determines which combination your organization actually needs.

The Threat Model: What Are You Protecting Against?

Before choosing an encryption approach, be clear about what you are trying to stop:

• Network interception — an attacker capturing email traffic between servers
• Compromised mail server — an attacker reading stored messages on an email provider's infrastructure
• Provider access — your email provider reading message content
• Forwarded or leaked messages — a recipient sharing message content with unauthorized parties

No single email encryption technology addresses all of these. Each has a specific threat model and meaningful gaps.

Transport Layer Security (TLS)

What TLS protects

TLS encrypts the SMTP connection between two mail servers, preventing passive interception of messages in transit. It is analogous to HTTPS for web traffic — the content is encrypted while moving across the network, but it is decrypted and re-encrypted at each hop.

How it works

When your mail server connects to a recipient's mail server, the servers negotiate a TLS handshake before transmitting the message. The message is encrypted in transit. Once it arrives, it is stored in plaintext on the receiving server.

Modern mail servers support two modes:

• Opportunistic TLS (STARTTLS) — the server attempts TLS but falls back to plaintext if the receiving server does not support it
• Enforced TLS (MTA-STS or DANE) — the connection is rejected if TLS cannot be established, preventing downgrade attacks

Enabling enforced TLS

MTA-STS (Mail Transfer Agent Strict Transport Security) publishes a policy via DNS and a well-known HTTPS endpoint telling sending servers to require TLS:

_mta-sts.yourcompany.com  TXT  "v=STSv1; id=20260309120000Z"

Host a policy file at https://mta-sts.yourcompany.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.yourcompany.com
max_age: 604800

DANE (DNS-based Authentication of Named Entities) uses DNSSEC-signed TLSA records to pin the mail server's TLS certificate, preventing certificate substitution attacks.

TLS limitations

TLS does not protect messages at rest on the server. It does not prevent your email provider from reading messages. It does not protect against a compromised mail server. TLS is a baseline that every organization should have, but it is not sufficient on its own for sensitive communications.

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

What S/MIME protects

S/MIME (Secure/Multipurpose Internet Mail Extensions) encrypts the message body and attachments end-to-end. The message is encrypted before it leaves the sender's mail client and can only be decrypted by the intended recipient's private key. Mail servers, providers, and intermediaries cannot read the content.

S/MIME also provides digital signatures, allowing recipients to verify that a message came from the claimed sender and was not altered.

How S/MIME works

Each user has a certificate containing their public key, issued by a Certificate Authority (CA). To send an encrypted message:

1. The sender obtains the recipient's certificate (public key)
2. The mail client encrypts the message using the recipient's public key
3. Only the recipient's private key can decrypt it

To sign a message:

1. The mail client signs the message using the sender's private key
2. The recipient's mail client verifies the signature using the sender's public key (from the certificate)

Obtaining S/MIME certificates

• Enterprise CA — issue certificates from your internal PKI (Active Directory Certificate Services, for example)
• Commercial CA — Sectigo, DigiCert, and GlobalSign offer S/MIME certificates; cost ranges from free personal certificates to paid organization-validated certificates
• Free options — some CAs offer free personal S/MIME certificates (verify current offerings as availability changes)

Deploying S/MIME in an organization

For organizations using Microsoft 365:

1. Deploy certificates via Microsoft Intune or Group Policy
2. Enable S/MIME in Outlook settings
3. Publish certificates to the Global Address List so Outlook can find recipients' public keys automatically

For Google Workspace (Business Plus and above):

1. Upload S/MIME certificates in the Admin Console under Gmail > User settings > S/MIME
2. Users can then enable encryption in Gmail settings

S/MIME limitations

S/MIME requires both sender and recipient to have certificates. External parties without certificates cannot receive encrypted mail. Certificate management at scale — issuance, renewal, revocation — adds operational overhead. If a user loses their private key, encrypted messages in their mailbox become permanently unreadable.

PGP/GPG: Web of Trust Encryption

What PGP protects

Pretty Good Privacy (PGP) and its open-source implementation GNU Privacy Guard (GPG) provide end-to-end encryption similar to S/MIME, but using a decentralized trust model rather than a CA hierarchy. Users generate their own key pairs and establish trust by signing each other's keys.

How PGP works

1. Each user generates a key pair: a public key (shared freely) and a private key (kept secret)
2. Public keys are published to keyservers (keys.openpgp.org, for example) or shared directly
3. Senders encrypt messages using the recipient's public key
4. Recipients decrypt using their private key

Key generation

# Generate a new key pair
gpg --full-generate-key

# Select RSA and RSA, 4096 bits, 2-year expiry
# Enter your name and email

# Export your public key for sharing
gpg --armor --export your@email.com > publickey.asc

# Upload to a keyserver
gpg --keyserver keys.openpgp.org --send-keys YOUR_KEY_ID

Integrating PGP with email clients

• Thunderbird — built-in OpenPGP support since version 78
• Apple Mail — GPGTools (GPG Suite) plugin
• Outlook — Gpg4win with GpgOL plugin
• Web clients — Mailvelope browser extension for Gmail and Outlook Web

PGP limitations

PGP's web of trust model is complex for non-technical users. Key discovery and verification require manual steps. Large organizations find PGP difficult to manage at scale. The lack of centralized certificate management means there is no revocation infrastructure equivalent to S/MIME CAs.

Choosing the Right Approach for Your Organization

Scenario	Recommended approach
Baseline protection for all email	TLS with MTA-STS enforcement
Internal sensitive communications in Microsoft/Google environments	S/MIME via enterprise certificate deployment
High-security communications with known technical recipients	PGP/GPG
Healthcare or legal with regulatory requirements	S/MIME with documented certificate management
Developer or open-source community communications	PGP
Communications with untrusted external parties	TLS only (S/MIME/PGP impractical without pre-coordination)

What Email Encryption Cannot Do

All three technologies share important limitations:

• Metadata is not encrypted — subject lines, sender, recipient, and timestamps are typically visible even with S/MIME or PGP encryption
• Recipient systems — once decrypted on the recipient's device, the message is only as secure as that device
• Key compromise — if a private key is stolen, all past messages encrypted to that key may be compromised (PGP does not provide forward secrecy by default)
• Endpoint security — encryption in transit or at rest does not protect against keyloggers or screen capture malware on the endpoint

For organizations with the highest security requirements, consider encrypted messaging platforms (Signal for Business, Wickr) for sensitive real-time communications, and use email encryption as a complement rather than a complete solution.