SPF, DKIM, and DMARC solve the authentication problem—verifying that email comes from who it claims to be from. But they do nothing about confidentiality. An authenticated email can still be read by anyone who intercepts it.

Email was designed in an era when the internet was a trusted academic network. The original SMTP protocol transmits messages in cleartext—readable by any system along the delivery path. This includes:

• Network operators at every hop
• Government surveillance systems
• Hackers who compromise intermediate servers
• Malicious insiders at email providers

The analogy is a postcard versus a sealed envelope. SMTP emails are postcards—anyone handling them can read the contents. Email encryption provides the sealed envelope.

This page covers two categories of encryption:

1. End-to-End Encryption (E2EE): S/MIME and PGP encrypt message content so only the intended recipient can decrypt it
2. Transport Encryption: TLS encrypts the connection between mail servers, protecting against network-level interception

Both have roles in a defense-in-depth strategy for email security.

Before diving into specific technologies, let's establish the cryptographic concepts that underpin email encryption.

Symmetric vs. Asymmetric Encryption

Symmetric Encryption

• Single shared key for encryption and decryption
• Fast and efficient for large data
• Challenge: Secure key distribution
• Examples: AES, ChaCha20

Asymmetric Encryption

• Key pair: public key (encrypt) and private key (decrypt)
• Anyone can encrypt with public key; only private key holder can decrypt
• Slower than symmetric; used for small data or key exchange
• Examples: RSA, ECDH, X25519

Hybrid Encryption in Email

Email encryption systems use hybrid encryption:

1. Generate a random session key (symmetric)
2. Encrypt the message body with the session key (fast, handles any size)
3. Encrypt the session key with the recipient's public key (small data, secure)
4. Send both: encrypted message + encrypted session key
5. Recipient uses private key to decrypt session key
6. Recipient uses session key to decrypt message

Digital Signatures for Email

Encryption provides confidentiality. Digital signatures provide integrity and non-repudiation:

1. Sender creates a hash of the message
2. Sender signs the hash with their private key
3. Signature is attached to the message
4. Recipient verifies signature with sender's public key
5. Valid signature proves: message wasn't modified, sender possessed private key

Both S/MIME and PGP support signing, encryption, or both. A signed-and-encrypted message provides confidentiality, integrity, authentication, and non-repudiation.

S/MIME (Secure/Multipurpose Internet Mail Extensions) is the dominant email encryption standard in enterprise environments. Defined in RFC 8551, it leverages X.509 certificates—the same PKI infrastructure used for HTTPS.

How S/MIME Works

Certificate Acquisition

1. User generates a key pair
2. User requests certificate from a Certificate Authority (CA)
3. CA verifies user identity (email address control, organization validation)
4. CA issues X.509 certificate binding public key to email address
5. Certificate is installed in user's email client

Signing Process

1. Email client hashes the message
2. Signs hash with user's private key
3. Attaches signature and certificate to message as PKCS#7 structure
4. Recipients can verify without prior key exchange

Encryption Process

1. Sender must have recipient's certificate (containing public key)
2. Generates session key, encrypts message
3. Encrypts session key with recipient's public key
4. Only recipient's private key can decrypt

PGP (Pretty Good Privacy) was created by Phil Zimmermann in 1991, during a time when strong encryption faced export restrictions. Today, the OpenPGP standard (RFC 4880) and its implementations (GnuPG/GPG) provide an alternative to S/MIME.

Key Differences from S/MIME

Trust Model: Web of Trust Instead of Certificate Authorities, PGP uses a decentralized Web of Trust:

• Users generate their own key pairs (no CA needed)
• Users sign each other's public keys to vouch for identity
• Trust is transitive: If I trust Alice, and Alice signed Bob's key, I can trust Bob
• No central authority; trust decisions are personal

Key Distribution PGP keys are distributed via:

• Public keyservers (e.g., keys.openpgp.org)
• Direct exchange (in person, verified via fingerprint)
• Key repositories in LDAP directories
• Attached to emails or published on websites

PGP Key Structure

A PGP key is more complex than an X.509 certificate:

Primary Key: Used for signatures (certifying other keys)

Subkeys: Separate keys for encryption, signing, authentication

• Allows key rotation without changing primary identity
• If encryption subkey is compromised, revoke only that subkey

User IDs: Multiple email addresses can be associated with one key

Key Signatures: Attestations from other users (Web of Trust)

Revocation: Keys can be revoked; revocation certificates should be generated at creation

Selecting between S/MIME and PGP depends on organizational requirements, user base, and use case. Understanding their differences enables informed decisions.

Recommendation Matrix

Choose S/MIME when:

• Enterprise environment with IT management
• Integration with Microsoft/Apple ecosystems required
• Regulatory compliance mandates verifiable identity
• Users are non-technical; need transparent operation
• Budget allows certificate costs

Choose PGP when:

• Privacy and decentralization are priorities
• Communicating with security-conscious communities
• Budget constraints prohibit certificates
• Users are technically capable of key management
• Central authority trust is unacceptable

Consider alternatives when:

• Need end-to-end encryption for casual use → Signal, WhatsApp
• Web-based email required → ProtonMail, Tutanota
• Automatic encryption without user action → Use TLS + gateway encryption

While S/MIME and PGP provide end-to-end encryption, they require explicit action from senders and recipients. Transport Layer Security (TLS) provides opportunistic encryption of the connection between mail servers—transparent to users.

STARTTLS: Upgrading SMTP to TLS

Modern SMTP supports TLS via the STARTTLS extension:

1. Client connects to server on port 25/587 (plaintext)
2. Server advertises STARTTLS capability in EHLO response
3. Client issues STARTTLS command
4. TLS handshake occurs (certificate exchange, key agreement)
5. All subsequent communication is encrypted
6. SMTP session continues over encrypted channel

Implicit TLS (SMTPS)

Port 465 was originally assigned for SMTPS (implicit TLS):

• Connection is TLS from the start (no plaintext EHLO)
• More efficient (no upgrade step)
• Re-standardized in RFC 8314 for email submission

TLS Limitations

Critical understanding: TLS is hop-by-hop, not end-to-end

• Encrypts connection between YOUR server and NEXT server
• At each intermediate server, message is decrypted, processed, re-encrypted
• Servers can read message content
• Only protects against network-level interception

Man-in-the-Middle Risk (Opportunistic TLS)

• If STARTTLS isn't required, attackers can strip the capability
• Client falls back to plaintext, never knowing TLS was available
• Solution: MTA-STS and DANE (discussed below)

Opportunistic TLS has a fatal flaw: attackers can perform TLS stripping attacks. Two protocols address this by allowing domains to declare TLS requirements.

MTA-STS (Mail Transfer Agent Strict Transport Security)

Concept: Domain publishes a policy file declaring that connections MUST use TLS with valid certificates. Sending servers cache this policy and refuse plaintext delivery to the domain.

How it works:

1. Domain publishes TXT record: _mta-sts.example.com → v=STSv1; id=202601011200
2. Domain hosts policy file at: https://mta-sts.example.com/.well-known/mta-sts.txt
3. Sending MTA fetches policy via HTTPS (authenticated channel)
4. Policy specifies: required TLS version, valid certificate hostname, max-age
5. Sender caches policy and enforces for all future messages

DANE (DNS-based Authentication of Named Entities)

Concept: Use DNSSEC to publish certificate information in DNS. Senders verify the receiving server's certificate matches the DNS record, preventing CA compromise and MITM attacks.

How it works:

1. Domain enables DNSSEC (cryptographically signs DNS)
2. Domain publishes TLSA record with certificate hash
3. Sending MTA queries TLSA record via DNSSEC
4. Sender validates received certificate matches TLSA
5. Even if CA is compromised, wrong cert would not match TLSA

TLSA Record Format:

_25._tcp.mail.example.com. TLSA 3 1 1 <hash>

• 3 = Certificate usage (DANE-EE: End Entity certificate)
• 1 = Selector (1 = subject public key)
• 1 = Matching type (1 = SHA-256)
• <hash> = SHA-256 hash of public key

Deploying email encryption involves technical, organizational, and usability challenges. Understanding these helps plan realistic implementations.

End-to-End Encryption Deployment

Gateway Encryption as Alternative

For organizations where user-side encryption is impractical, email encryption gateways provide centralized encryption:

• Sits between internal mail server and internet
• Automatically encrypts outbound messages based on policy
• Decrypts inbound encrypted messages
• Supports S/MIME, PGP, TLS, and proprietary formats
• Can provide "pull" delivery: recipient accesses message via web portal

Trade-off: Messages are plaintext inside the organization. Gateway sees all content. But dramatically simpler deployment for users.

Key Archival and Recovery

Critical for compliance and business continuity:

• Encryption key archival: If user leaves or loses key, encrypted messages become inaccessible
• Signing key separation: Signing keys prove identity—should NOT be escrowed (non-repudiation)
• Legal discovery: Courts may require decryption of archived messages

Email encryption provides the confidentiality layer that completes the security picture started by authentication protocols. Let's consolidate the key concepts:

Module Complete:

You have now completed the Email Security module. You understand:

• Spam and Phishing: The threat landscape and detection methods
• SPF: IP-based sender authorization
• DKIM: Cryptographic message signing
• DMARC: Policy alignment and enforcement
• Email Encryption: S/MIME, PGP, and transport-layer protection

Together, these technologies form a comprehensive defense protecting email—the most ubiquitous and attacked communication medium in the world. Proper implementation dramatically reduces phishing success, prevents domain spoofing, and protects sensitive communications from interception.