Securing the Email Flow: Implementing Encrypted Email in Microsoft 365, Exchange, and Onward

Most information security and IT teams know the risks involved when sending unencrypted email. However, outside of those groups, it is still not clear to many email users why encrypting sensitive email messages is so important and the extent of risks associated with unencrypted email communications. Encrypted email adoption still remains low across many industries. There is no shortage of mature email technologies as well as regulatory pressure to use encrypted email, but most email messages still aren’t protected beyond basic transport-layer encryption (TLS).

Why Secure Email Still Isn’t More Widespread

A number of common reasons prevent broader encrypted email adoption. User friction is often cited. Essentially, many are concerned that encryption isn’t automatic, it won’t be used, and that external recipients will have trouble opening encrypted messages and that they will go unread. In addition, encryption key management is another often-cited barrier, with manual certificates and encryption key exchange viewed as unsustainable at scale.

Building and maintaining encryption services in-house requires skilled staff and time, creating the perception that it requires too much operational overhead. Also, many organizations believe they’ve solved email encryption simply by requiring TLS, creating a false sense of security.

Conflating TLS with true email encryption is one of the most persistent misunderstandings in enterprise security.

Requiring TLS does not constitute email encryption. TLS protects the channel between two mail servers, not the message itself. TLS encrypts email communication in transit – like HTTPS (HTTP over TLS) does for web traffic. Once the message reaches its destination server, it is stored as cleartext aka unencrypted (unless additional protection is applied). For more information watch our video on how encryption in transit and end-to-end encryption work.

Email encryption, by contrast, means the message itself is encrypted, end-to-end – from sender to recipient – and remains unreadable even if intercepted after delivery. TLS alone does not prevent email contents from being read at rest on the recipient server because the TLS encryption protecting the message only exists while in transit. The message can still be intercepted if the recipient’s mail server is compromised. Forwarded unencrypted emails are also a risk, at which point custody of the cleartext email is lost. Not to forget, access by admins, insiders, or attackers with privileged access also increases the risk of unauthorized access to sensitive emails. Furthermore, message harvesting through archiving systems, backup snapshots, or even AI also puts unencrypted email messages at risk. Watch our video on encryption at rest for more information.

It is not uncommon for organizations to say, “We’re good … we’ve enforced TLS.” I have been told this many times before when working on client engagements. Unless the message itself is encrypted (e.g., with s/MIME, PGP, or policy-enforced service like Microsoft Purview), the data is still exposed. One way to describe this is that TLS protects the envelope, not the letter. Once delivered, if the messages are not encrypted the contents are fair game.

Why Organizations Buy Encrypted Email Products Instead of Building One

There are a number of reasons organizations default to buying an encrypted email product rather than implementing their own solution:

• The primary reason is speed. Platforms like Proofpoint or Mimecast can be deployed quickly, with polished user workflows and integrations. Buying a solution also delegates encryption, delivery, and key management to the vendor, so it reduces the risk of misconfigurations and the workload for internal teams.
• The secondary reason is that third-party products frequently offer access via secure portals or browser-based tools, eliminating the friction of PGP key exchange or S/MIME certificate requirements.
• Most commercial platforms are designed with regulatory frameworks in mind, offering out-of-the-box logging, audit trails, and data retention configurations.

With all that said, although there are some advantages to buying an encrypted email solution, buying isn’t always the best option. Key tradeoffs with purchased solutions include recurring costs as well as the potential for vendor lock-in.

Perhaps the most critical tradeoff with commercial encrypted email products is reduced key sovereignty. When you purchase an encrypted email solution – especially a cloud-based SaaS offering – you are often ceding control of your encryption keys to the vendor. This is a common tradeoff in platforms like Microsoft Purview Message Encryption, Proofpoint, or Zix.

It’s true that some purchased encrypted email solutions do support customer-managed keys (CMKs) but with caveats regarding how much actual control you retain, which vendors support it, and how securely it is implemented in practice. In practice, CMKs reduce the risk of unauthorized decryption, but only full key custody eliminates it.

With these solutions, the providers usually manage key generation, key storage, key rotation and lifecycle, and access to encryption key material under special operational or legal circumstances. Overall, the design of these solutions makes customer adoption easy, reduces operational overhead, and supports seamless recipient experiences. These are all beneficial things. However, they also introduce trust dependencies and inherent risk. When your provider holds the keys, your messages are just a legal request away from being read.

Implementing Encryption in Microsoft 365 (M365)

For organizations using M365, Microsoft Purview Message Encryption is one of the fastest and most scalable ways to deploy secure encrypted email without additional vendors. To this end, encryption is enforced by policies based on data classification, recipients, and/or DLP triggers. It is applied automatically without user action needed and supports external recipients via browser-based decryption with OTP (One-Time Password) or federated login.

Purview’s integration with classification labels, mail flow rules, and audit logging makes it enterprise-ready and compliant out-of-the-box.

Exchange Server Environments

Organizations still using Exchange Server on-premises or in a hybrid environment rely on a combination of TLS for secure transport and S/MIME message-level encryption. However, it comes with a cost of high friction (especially for external recipients), as well as key management overhead (as discussed earlier).

S/MIME offers strong security. Adoption is limited by the complexity of certificate provisioning and poor user experience, particularly for external recipients.

Hybrid environments can mitigate this by routing outbound mail through Microsoft 365, allowing for the application of Purview encryption policies even if mailboxes are on-premises. This does, however, require a very specific configuration to work. Importantly, with this hybrid approach, Purview encryption is applied only when mail exits via Exchange Online. As a result, it won’t protect intra-organization messages that stay on-premises.

Self-Hosting Encrypted Email

For organizations with unique sovereignty, privacy, or zero-trust requirements, self-hosted encrypted email remains a viable option. These setups often include full TLS enforcement, end-to-end encryption using PGP or S/MIME, secure webmail or desktop clients with built-in decryption, and gateway appliances that enforce outbound encryption policies.

This model provides full control including key custody and data residency but comes with significant complexity in the areas covered above, namely, certificate/key lifecycle management, external recipient interoperability, cross-device compatibility, and secure user onboarding and revocation. It is a viable option for government, defense, or privacy-first organizations but is often overkill for most business cases.

Focus on Encrypted Messages, Not Just Secure Channels

Email encryption only works when the actual message itself is protected, not just the network communication channel through which it is being delivered. TLS is essential, but it’s not enough, and it’s irrelevant in many breach scenarios. Here’s the good news: encrypted email is now more achievable than ever.

Whether using built-in solutions like Microsoft Purview, a third-party platform, or a custom architecture, the priority should be:

• Encrypting messages, not just connections.
• Removing friction from user workflows.
• Enforcing policies to ensure consistent application.
• Ensuring recipients, whether internal or external, can seamlessly decrypt messages.

If your organization assumes TLS equals encryption, it’s time to update your understanding and start operating from an improved, security-centered baseline. Data-in-transit protections are only a single thread in the tapestry of email information security practices. Without message-level encryption, there is a significant risk that message content could be breached, and sensitive information disclosed. Read my blog on data encryption best practices for more information, or contact our expert team for a security controls assessment, policy development guidance, or fractional vCISO guidance services.