Email Encryption: What Actually Gets Protected

Most email is already protected by transport encryption (TLS) as it moves between mail servers. TLS encrypts the connection between servers, so someone tapping the network can't read the email in transit. But TLS has limitations: it doesn't protect the message once it's stored on a server, and it doesn't protect the message if it's forwarded to another system that doesn't use TLS.

Message encryption is different. It protects the email content itself so only the intended recipient can read it, regardless of how many servers the message passes through or how long it's stored. S/MIME and OpenPGP/GPG encrypt the message body and attachments using the recipient's public key. The recipient uses their private key to decrypt. This protection persists through storage, forwarding, and archiving.

The distinction matters because TLS is already widely deployed and mostly invisible to users. Message encryption requires explicit setup, key management, and recipient coordination. TLS protects the pipe; message encryption protects the payload. You need both for comprehensive protection, but they solve different problems.

The three main approaches to email encryption each have different strengths and failure modes. The right choice depends on your ecosystem, your technical capacity, and who you're communicating with.

The interoperability mess

Email encryption suffers from fragmentation. S/MIME works well in Microsoft 365 and Outlook environments but may not integrate smoothly with other platforms. OpenPGP/GPG is more flexible but requires plugins or separate clients. Portal delivery works everywhere but creates dependency on the portal vendor. There's no universal standard that "just works" across all email systems, which is why many organizations fall back to secure links or encrypted attachments for external communication.

Key distribution is the hardest problem

All message encryption approaches face the same fundamental challenge: how do you get the recipient's public key in a way you can trust? S/MIME uses certificate authorities to provide trust anchors, but you still need to verify the certificate belongs to the right person. OpenPGP/GPG uses a web of trust model that works at small scale but becomes complex as organizations grow. Portal delivery sidesteps the key problem by shifting the burden to identity providers, but this creates new friction points.

Portal-based secure email delivery seems like an elegant solution: send an email with a link, recipient logs in to a secure portal to view the message. No keys, no certificates, no crypto setup. But portals introduce a different kind of complexity: identity friction.

Archiving and legal hold complications

Portals create archiving gaps. When the sensitive content lives in a portal rather than in your mail system, your email archive may only contain the link notification, not the actual content. This complicates legal hold workflows, e-discovery requests, and compliance audits. You need separate processes to capture portal content, verify retention, and produce it when requested. Some organizations address this by having the portal send a copy to an archiving system, but this adds complexity and may not capture all portal interactions.

Portal vendor dependency

Portal delivery creates dependency on the portal vendor's availability, security posture, and business continuity. If the portal goes down, recipients can't access messages. If the vendor has a security incident, your sensitive content may be exposed. If the vendor changes pricing or terms, you may face migration costs. These risks are manageable but require vendor due diligence and contingency planning.

Message encryption is powerful but impractical for many real-world scenarios. When you're sending sensitive information to external parties who don't have encryption keys or certificates, secure links or encrypted attachments are often the more pragmatic choice.

Decision framework

Use message encryption (S/MIME or OpenPGP/GPG) for ongoing communication with recipients who have the technical capacity and governance to manage keys or certificates. This includes internal teams, long-term business partners, and regulated counterparties where encryption is a contractual requirement.

Use secure links for one-time exchanges with external parties, large file transfers, or when the recipient's technical capacity is unknown. Secure links work well for sending sensitive documents to vendors, customers, or partners where you don't have an ongoing encryption relationship.

Use encrypted attachments as a last resort when recipients lack any other secure channel. This is better than sending sensitive content in plaintext, but the password transmission problem makes it weaker than proper encryption or secure links. If you use encrypted attachments, send the password through a different channel (phone call, SMS, separate email) and avoid reusing passwords.

Where you host secure email portals and what domain they use affects trust, operational complexity, and risk containment. The email authentication guide covers domain strategy in depth for SPF/DKIM/DMARC, but similar considerations apply to encryption portals.

Main domain vs. branded subdomain vs. vendor-owned domain

Hosting a secure portal on your main domain (secure.example.com) creates the most trust with recipients because they recognize your brand. But it also means any portal security issue affects your primary domain reputation. Using a branded subdomain (portal.example.com or secure-mail.example.com) provides containment: if the portal has a problem, the impact is limited to that subdomain. Vendor-owned domains (securemail.vendor.com) are fastest to set up but create trust issues because recipients may not recognize the domain.

When subdomains make sense for portals

Branded subdomains are often a good choice for secure email portals. Use portal.example.com or secure.example.com to clearly signal the purpose while maintaining brand recognition. This provides operational clarity and makes it easier to apply specific security policies to the portal without affecting your primary domain. The caveat is that subdomains still need governance: moving the problem to a subdomain without managing it just relocates the failure mode.

Key management is the operational backbone of any message encryption system. Without processes for distribution, rotation, revocation, and backup, encryption becomes a liability rather than a protection.

Distribution and verification

Getting public keys to recipients in a trustworthy way is harder than it sounds. For S/MIME, you need a process to distribute certificates and verify they belong to the right person. For OpenPGP/GPG, you need a process to exchange keys and establish trust. Many organizations solve this with a directory service or internal key server, but this adds infrastructure and requires ongoing maintenance.

Rotation and revocation

Keys and certificates don't last forever. They need rotation on a schedule (typically every 1-3 years) and immediate revocation if they're compromised or an employee leaves. Revocation is particularly tricky: you need a way to notify all parties who might have the old key that it's no longer valid. Certificate authorities handle this for S/MIME through CRLs (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol), but these mechanisms have their own reliability and performance challenges.

Backup and recovery

Lost keys mean lost data. If an employee loses their private key and you don't have a backup, any encrypted messages sent to them become permanently unreadable. This is a serious problem for organizations with regulatory retention requirements. You need a secure backup process for private keys, with strict access controls and clear documentation of who can recover keys and under what circumstances.

Email encryption is one layer of a broader email security strategy. It works alongside several related controls to provide comprehensive protection.

Email authentication (DMARC, DKIM, SPF) protects against spoofing and impersonation, but it doesn't protect content confidentiality. Encryption and authentication are complementary: encryption protects the message content, authentication proves who sent it. You need both for complete protection.

Secure email archiving (SEAS) preserves email history for disaster recovery, compliance, and investigation. Encrypted messages create archiving challenges: you need to ensure encrypted content is captured in a way that remains searchable and discoverable. Some archiving systems can decrypt messages using a master key, but this introduces its own security considerations.

Business email compromise (BEC) prevention relies on process controls and identity safeguards. Encryption doesn't stop BEC, but it does reduce the damage if an account is compromised: the attacker can read encrypted messages only if they also obtain the recipient's private key.

Data retention policies define how long encrypted messages must be preserved and when they can be deleted. Encryption adds complexity to retention because you need to ensure keys remain available for the entire retention period. If a key is lost before the retention period expires, you may not be able to produce required messages for legal holds or audits.