Microsoft Email Encryption: What Actually Gets Protected and What Doesn't

Microsoft email encryption is one of those features that sounds binary: it's either on or off. The reality is murkier. Microsoft layers multiple encryption mechanisms across its 365 ecosystem, each with different scopes, different licensing requirements, and different recipient experiences. The gap between "we use TLS" and "our messages are encrypted end to end" is enormous, and most organizations sit somewhere in the middle without knowing it. This piece walks through what Microsoft actually provides, what changed in 2026, and where the structural gaps are.

Key Takeaways

• Microsoft's current offering is Microsoft Purview Message Encryption, which replaced the older Office 365 Message Encryption (OME) branding. It's built on Azure Rights Management and is only included in specific plans: Business Premium, E3, E5.
• The cheap add-on path (Azure Information Protection Plan 1) that smaller tenants relied on has been retired. If you're on Business Basic or Standard, you now need a full plan upgrade or a pricier standalone bundle to encrypt outbound email.
• Opportunistic TLS, which Microsoft enables by default, protects the connection but not the message contents at rest. It is not email encryption in any meaningful sense for compliance or data-protection purposes.
• Recipient experience varies wildly: inline for Outlook/M365 users, a portal with a one-time passcode for everyone else. That friction drives workarounds, which defeat the purpose.
• Office 365 end to end encryption does not exist as a native feature for email. Microsoft's Purview encryption protects messages in transit and at rest, but Microsoft retains key management. True end-to-end encryption for email requires third-party tooling or protocol-level changes Microsoft hasn't shipped.

What Is Microsoft Purview Message Encryption?

Microsoft Purview Message Encryption is the current branding for Microsoft's server-side email encryption. It replaced the older "Office 365 Message Encryption" label, though plenty of admin interfaces and documentation still reference OME. Under the hood, it uses the Azure Rights Management service (Azure RMS) to encrypt message bodies and attachments before they leave the sender's mailbox.

The encryption applies in transit and at rest. Messages are protected by AES 256-bit encryption, and access control is enforced through rights-management policies: you can prevent forwarding, printing, or copying of message contents. When both sender and recipient are on Microsoft 365 or Outlook.com, the experience is mostly transparent. The message renders inline.

When the recipient is on Gmail, they see a preview and click through to a separate viewer. When the recipient is on Yahoo, AOL, or any ISP-grade provider, they're routed to a branded portal and prompted for a one-time passcode delivered to their inbox. This is where friction starts compounding.

Which Microsoft 365 Plans Include Email Encryption?

Only Business Premium, E3, and E5 include Purview Message Encryption natively. Business Basic and Business Standard do not. Exchange Online Plan 1 does not.

This matters more than it used to, because the cheap workaround is gone. Historically, smaller tenants on Exchange Online Plan 1 could add the Azure Information Protection Plan 1 add-on for a few dollars per user per month to enable OME. That license has been retired. It is no longer available as a standalone product.

The replacement path is either upgrading to Business Premium (roughly $16/month more per user in some configurations) or purchasing the Purview Information Protection standalone bundle, which runs around $12/month per user. For a 50-person organization on Business Standard, that's a nontrivial annual cost increase just to encrypt outbound email. Multiple admin threads from 2026 show real frustration with this licensing change, and it's the single biggest source of confusion in the Microsoft email encryption space right now.

Does TLS Count as Email Encryption?

No. This is the most common misconception, and it's worth addressing directly because it trips up compliance audits constantly.

Microsoft enables opportunistic TLS by default on all Exchange Online connections. TLS encrypts the SMTP session between mail servers. It does not encrypt the message itself. Once the email arrives at the destination server, it sits in plaintext (or whatever the receiving server's at-rest policy dictates). Attachments are not encrypted at rest. The contents aren't protected after arrival, and if the message is archived, forwarded, or exported, TLS provides zero residual protection.

Opportunistic TLS also has a degradation problem. If the receiving server doesn't support TLS, many configurations fall back to plaintext delivery silently. You, the sender, may never know. This is "encryption" in the way that locking your car counts as home security: it covers one vector and ignores everything else.

For HIPAA, CJIS, CMMC, or any regulatory framework that requires encryption of protected data in transit and at rest, TLS alone does not satisfy the requirement. Purview Message Encryption is positioned to meet the HIPAA Security Rule's technical safeguard for encryption in transit and at rest. TLS is not.

Does Office 365 Offer End to End Encryption for Email?

It does not. This is a point worth being precise about, because "office 365 end to end encryption" is something people actively search for, and the honest answer is that it doesn't exist as a native email feature in Microsoft's stack.

End-to-end encryption, in the strict sense, means only the sender and recipient can decrypt the message. The service provider cannot read it, even under compulsion. Microsoft's Purview Message Encryption does not meet this bar. Microsoft manages the encryption keys through Azure RMS. Microsoft can, in principle, decrypt messages in response to legal process or internal policy. They state this in their documentation.

Microsoft does offer end-to-end encryption for Teams calls and meetings (as of late 2023), but that capability has not been extended to email. S/MIME is supported in Exchange Online and does provide a form of end-to-end encryption via client-side certificates, but it requires PKI infrastructure, certificate distribution to every recipient, and introduces its own set of management headaches that make it impractical for most organizations outside of government or defense.

If you actually need end-to-end encrypted email (where the provider holds no keys), you're looking at third-party solutions layered on top of Exchange, or a different email platform entirely. Microsoft's native tooling gives you strong transport and at-rest encryption with centralized key management. That's a legitimate security posture for many use cases. It is not end-to-end encryption.

How Do You Set Up Email Encryption in Microsoft 365?

Assuming you're on a plan that includes Purview Message Encryption, setup happens in two layers: enabling the service, then defining mail flow rules that trigger encryption automatically.

First, verify that Azure RMS is activated for your tenant. In most newer tenants, it's on by default. You can check under the Microsoft Purview compliance portal or via PowerShell (Get-AipServiceConfiguration). If it's not active, Microsoft's setup documentation walks through activation.

Second, create mail flow rules in Exchange admin center that apply encryption based on conditions: sender, recipient domain, subject line keywords, sensitivity labels, or message headers. A common configuration encrypts all outbound messages containing specific sensitive data types (SSNs, credit card numbers) automatically. You can also let users trigger encryption manually by applying a sensitivity label or clicking "Encrypt" in the Outlook compose window.

The practical advice: don't rely on users remembering to click a button. Build mail flow rules that catch the sensitive patterns you care about and encrypt by default. Manual encryption is a training problem that never fully resolves.

What About the New Outlook Client?

The New Outlook for Windows (the one replacing the classic Win32 client) supports Purview Message Encryption through sensitivity labels. The UI has shifted: instead of the old "Permissions" button, you apply a label that carries encryption policy. If your organization has configured sensitivity labels in the Purview compliance portal, they'll appear in the New Outlook ribbon under "Sensitivity." The underlying mechanism is the same: Azure RMS policy enforcement.

One gotcha: if you haven't migrated your label taxonomy from Azure Information Protection to Purview unified labeling, labels may not appear in the New Outlook. Microsoft is retiring the legacy AIP viewer apps and RMS Sharing App as part of the push toward Purview-native experiences. If you're still on the old AIP client, plan your migration now.

Why Does the Recipient Experience Matter for Security?

Because bad UX creates workarounds, and workarounds defeat encryption.

When you send an encrypted message to another Microsoft 365 user, it renders inline. No friction. When you send to a Gmail user, they get a partial preview and a link. When you send to a Yahoo or ISP mailbox, the recipient gets a wrapper email directing them to a portal where they enter a one-time passcode. For recipients unfamiliar with this flow, it looks like phishing. Some organizations report recipients simply ignoring encrypted messages because the portal experience is confusing.

The downstream effect: senders learn that encryption causes recipient complaints. So they stop encrypting. They send PHI, financial data, and legal documents in plaintext "for convenience." The encryption tooling is technically functional but operationally bypassed. This is a systems-design failure, not a user-training failure. Encryption that creates enough friction to incentivize circumvention is encryption that degrades your security posture rather than improving it.

The better design pattern is default-on, invisible protection. If encryption is a toggle users can forget or choose not to flip, some percentage will always send sensitive content unprotected. Mail flow rules help. But the portal/passcode experience for external recipients remains a structural weakness in Microsoft's approach.

What Changed in 2026?

Three things worth tracking:

The AIP P1 add-on retirement is the most impactful change for small and mid-sized organizations. If you built your encryption posture around a $2-3/user/month add-on to Exchange Online Plan 1 or Business Standard, that path is closed. You're now choosing between a full plan upgrade and a more expensive standalone Purview bundle. Budget for it.

Legacy app retirement is happening in parallel. The Azure Information Protection mobile viewer app and the RMS Sharing App for Mac are being retired by mid-2026. If your mobile users rely on these apps to open encrypted attachments, they'll need to transition to the native Purview-integrated experience in Outlook mobile or the Microsoft 365 app.

Market context: the global email encryption market is projected to grow from $9.43 billion in 2025 to $11.75 billion in 2026, a 24.6% year-over-year increase. That growth is driven by regulatory mandates (HIPAA, GDPR, CMMC), rising email-based attacks, and increasing enterprise email volume. The demand is real and non-seasonal.

How Does Microsoft Email Encryption Compare to Third-Party Solutions?

Microsoft's native encryption is tightly integrated with the 365 ecosystem, which is its primary advantage. Policy management lives in the same admin consoles you already use. Sensitivity labels apply across email, documents, and Teams. If you're fully committed to the Microsoft stack and on the right license tier, it works with minimal additional tooling.

The gaps show up in three areas:

Key management. Microsoft holds the keys by default. You can bring your own key (BYOK) or implement Double Key Encryption (DKE) for the most sensitive content, but both add complexity. Third-party solutions like Virtru or Zix provide customer-managed keys as a default, not an add-on configuration.

Cross-platform recipient experience. As covered above, the portal/passcode flow for non-Microsoft recipients is clunky. Solutions built specifically for encrypted email delivery (like Proton Mail's web portal or Virtru's reader-free decryption) tend to handle this more gracefully.

Licensing accessibility. Putting encryption behind a $22/user/month plan when your organization only needs $6/user/month for mailboxes creates a perverse incentive to under-protect email. Third-party encryption services typically price per-feature, not per-platform-tier.

None of this means Microsoft's approach is wrong for your organization. It means the decision has more dimensions than "we use Microsoft, so we'll use Microsoft's encryption." Evaluate the recipient experience for your actual communication patterns, not just internal flows.

The Licensing Maze Is a Security Problem

This is the part most "how to encrypt email in Outlook" guides skip, because it's uncomfortable. When encryption is gated behind a specific license tier, organizations that can't justify the upgrade simply go without. The admin knows they should encrypt outbound messages containing patient data. The CFO sees a $16/user/month increase across 200 users and says no. The result: PHI travels in plaintext over opportunistic TLS, technically non-compliant, practically common.

Microsoft's licensing model treats encryption as a premium feature. That's a business decision, and they're entitled to make it. But the security consequence is that the organizations least able to afford premium licensing (small practices, startups handling sensitive data, nonprofits) are the ones most likely to be sending unencrypted sensitive email. The cheapest path to encryption was the AIP P1 add-on. That path is gone.

This is one reason we think about encryption as a default, not a feature. When you're building systems that handle sensitive information (whether that's email, file transfers, or AI-assisted workflows), protection should be in the base layer, not an upsell. At Selina, file transfers through SelinaSEND are zero-knowledge encrypted. That's the baseline, not a premium tier.

What Should You Actually Do?

If you're an IT admin or founder trying to figure out your Microsoft email encryption posture, here's a concrete sequence:

1. Audit your current licenses. Check whether your tenant actually has Purview Message Encryption enabled. Don't assume. Run Get-IRMConfiguration in Exchange Online PowerShell and verify AzureRMSLicensingEnabled is True.
2. Map your recipient patterns. What percentage of your encrypted email goes to non-Microsoft recipients? If it's high, the portal/passcode experience is going to cause friction. Plan for it or evaluate third-party overlay solutions.
3. Build mail flow rules, not training programs. Automate encryption for messages matching sensitive data patterns. Don't rely on users clicking "Encrypt." Microsoft's transport rule documentation covers the syntax.
4. Budget for the licensing change. If you were on the AIP P1 add-on, you need a new path. Business Premium or the Purview Information Protection standalone are your options. Neither is cheap, but neither is a HIPAA fine.
5. Stop calling TLS "encryption." If your security documentation says "emails are encrypted via TLS," fix that language. TLS protects the pipe. It does not protect the message. Auditors increasingly know the difference.

Email encryption in the Microsoft ecosystem is functional, well-integrated, and frustratingly gated behind licensing tiers that leave many organizations exposed. Know what you have. Know what you don't. Act on the gap.

Start a free 7-day trial, no card required, if you want to see how we handle encrypted file transfers and privacy-first AI in practice.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io