🔑 Key Takeaways
- Email encryption stacks three layers: TLS transport, S/MIME or PGP content, and RMS rights.
- PGP works for a stable partner list but breaks on ad hoc patient sends needing prior key swap.
- S/MIME is the enterprise standard when PKI already exists; certificate lifecycle is the real cost.
- Microsoft Purview labels apply encryption plus do-not-forward from one dropdown in Outlook.
- TLS covers most outpatient sends; message-level encryption still sits on top for HIPAA PHI.
Encryption for email splits into three layers: transport, message body, and rights protection. Each layer solves a different problem, and each has a different cost profile.
Business teams and regulated teams like healthcare, legal, and finance all need to know which layer fits which send. This guide walks the three layers, the standards behind each, and how they combine into a workable stack. For teams that want a simpler encrypted email path without managing certificates, the last section covers the dedicated service option.
Start with what encryption actually does and where it does not do enough.
The Three Layers of Encryption for Email
Transport Layer Security protects the connection between two mail servers. When both Microsoft 365 and Google negotiate TLS, the wire hop is encrypted. Anyone tapping the network sees ciphertext.
Message body encryption protects the actual content. S/MIME and PGP both encrypt the payload with a key pair. Only the recipient with the matching private key can decrypt. The message stays encrypted at rest on the receiver side.
Rights management sits on top. Microsoft Purview and its predecessor RMS apply policy controls like block forwarding, block printing, and enforce expiration. Rights management works alongside encryption to enforce how the recipient can use the message.
A complete stack usually uses TLS by default, message body encryption for sensitive mail, and rights management templates for regulated policy enforcement. Sibling coverage on the concept sits at email encryption.
PGP Encryption for Email in Practice
PGP, short for Pretty Good Privacy, and its open standard OpenPGP, uses a key pair for each user. The public key encrypts to that user. The private key decrypts.
Thunderbird ships with OpenPGP support since version 78. Users generate a key pair inside Thunderbird, export the public key, and share it with recipients. Encrypted messages send through any IMAP or POP mailbox.
Mailvelope is a browser extension for Chrome, Firefox, and Edge. It layers PGP on top of Gmail, Outlook on the web, and other webmail providers. Users generate a key pair in the extension and encrypt or decrypt inside the webmail interface.
PGP works well for a stable set of technical counterparties. It does not scale to ad hoc sends because each new recipient needs a key exchange before the first encrypted message. That rules out one off patient or client mail.
S/MIME as the Enterprise Standard
S/MIME, short for Secure/Multipurpose Internet Mail Extensions, is the enterprise message encryption standard. Certificates come from a public certificate authority or an internal PKI.
Outlook desktop, Outlook for Mac, Apple Mail, and Google Workspace with hosted S/MIME all support the standard. The sender needs a valid certificate installed in the local certificate store. The recipient needs a matching public certificate exchanged in advance.
Certificate lifecycle is the operational cost. Certificates expire, keys need backup, and revocation lists need updates. Large enterprises staff a PKI team to handle this. Small teams struggle with the overhead.
Sibling reading on the S/MIME format sits at s mime email encryption. For file level encryption tied to email, see the guide on how to encrypt a file for email.
RMS Templates and Microsoft Purview Labels
Rights Management Services, or RMS, applies policy controls on top of encryption. Microsoft Purview sensitivity labels are the modern successor and the current best practice for Microsoft 365 tenants.
Default templates include Encrypt Only, Do Not Forward, Confidential, and Highly Confidential. Each template applies a defined set of controls: encryption, forwarding restriction, printing restriction, expiration, and watermarking.
Senders pick a label from a dropdown in Outlook or Word. The template applies the encryption and policy in one action. Staff do not configure encryption settings per send. That reduces training and errors.
Administrators create custom templates in the Purview admin center. A custom template can encrypt with a tenant key, restrict access to a security group, and apply a specific expiration. Learn more at Microsoft Learn on sensitivity labels.
TLS as the Transport Baseline
Every serious mail server supports TLS today. Microsoft 365 and Google Workspace negotiate TLS 1.2 or TLS 1.3 on outbound by default.
TLS is opportunistic in the default configuration. When the receiving server does not offer TLS, the message can fall back to plain text. Mail flow rules can force TLS on outbound connectors or block the delivery.
TLS does not encrypt the message at rest. Once the message lands in the recipient inbox, anyone with access to that mailbox reads it. TLS covers the wire between servers only.
For HIPAA sends, TLS is the floor and not the ceiling. Auditors expect message level encryption on top of TLS. See the NIST guide on Trustworthy Email for the transport security context.
Email Encryption for Office 365 Users
Microsoft 365 tenants on Business Premium, Enterprise E3, Enterprise E5, or the E5 Compliance add on can use Microsoft Purview Message Encryption without adding a separate service.
Senders click Options, then Encrypt in the Outlook ribbon and pick a policy. External recipients open the message through the Microsoft encrypted message portal with a Microsoft, Google, or one time passcode sign in.
Administrators can add mail flow rules in the Exchange admin center that apply encryption automatically. A rule can encrypt any message with the word confidential in the subject, or any message to a defined partner domain.
Tenants on Business Basic or Business Standard do not include the Encrypt button. The options are upgrading the plan or adding a dedicated encrypted email service. Sibling coverage on the RMS template question sits at which rms template do i use for email encryption.
Email Encryption for Businesses of Different Sizes
Business size drives the sensible choice. A five person practice does not need the same stack as a thousand seat enterprise.
- 1 to 25 seats. A dedicated hosted service like Mailhippo layered on the existing Gmail or Outlook mailbox. BAA included, one click recipient open, minimal training.
- 25 to 250 seats. Microsoft 365 Business Premium with Purview Message Encryption, or Google Workspace Enterprise Standard with hosted S/MIME. Native integration inside the platform.
- 250 to 2500 seats. Microsoft Purview with custom sensitivity labels tied to the internal classification schema. Central compliance team owns the label taxonomy.
- 2500 seats and up. Enterprise appliance from Cisco, Proofpoint, or OpenText Voltage tied to inbound email security. Full change management, dedicated security team ownership.
Match the deployment to the team that will run it. Overbuying leads to shelfware. Underbuying leads to workarounds that break compliance. Sibling coverage on the MSP side sits at best solutions for email encryption.
Encryption for Email at Law Firms
Law firms use encryption for email to protect attorney client privilege, comply with state bar rules on client communication, and meet client audit requirements.
Small firms usually pick a dedicated service like Mailhippo or Virtru. The service adds a send workflow on top of Outlook or Gmail and provides one click recipient delivery. That matches the ad hoc client communication pattern.
Mid size firms lean toward Microsoft 365 Business Premium or E3 with Purview Message Encryption and sensitivity labels. The label taxonomy matches internal document classification and travels between mail and documents in Word and Excel.
Large firms deploy enterprise appliances tied to a broader security stack. Cisco Secure Email Encryption Service and Proofpoint Encryption dominate that segment. Adoption follows the firm wide security architecture.
Encrypting Files and PDFs Sent by Email
Email encryption protects the message. Files attached to the message can carry their own encryption in addition, which travels with the file after download.
PDF encryption is the most common file layer. Adobe Acrobat, Microsoft Word export to PDF, and macOS Preview all support password protected PDFs. The recipient enters the password to open the file.
Office documents support encryption from File, Info, Protect Document, Encrypt with Password in Word, Excel, and PowerPoint. The document stores the password protection and travels encrypted with the message.
Password sharing is the friction point. Deliver the password on a separate channel like a phone call or SMS. Never send the password in the same email. Sibling coverage on the PDF path sits at how to encrypt a pdf for email.
Picking the Right Encryption for Email Stack
Match the encryption stack to the workflow. Ad hoc external mail needs a portal or one click service. Fixed partner exchanges tolerate S/MIME or PGP. Regulated policy enforcement needs sensitivity labels.
Start with the platform license. If Microsoft 365 or Google Workspace already includes the encryption path, use it. Add sensitivity labels for policy control. If the platform license does not include encryption, add a dedicated secure email service that includes a BAA.
Test the recipient experience on real inboxes before the first live send. Send to a personal Gmail, a personal Outlook, a Yahoo, and one enterprise domain. Measure time to open and confirm the message renders correctly on each.
