[mh_key_takeaways]
O365 email encryption is a bundle of features under Microsoft Purview Message Encryption, formerly known as Office 365 Message Encryption. It covers transport encryption, at-rest encryption on Exchange Online, and message-level encryption through a portal delivery model.
This guide walks through the licensing, setup, and known limits. If your tenant needs a supplementary encrypted email path for specific recipient groups or vertical compliance requirements, the vendor-neutral overview is a useful reference.
The audience assumed here is an IT admin or Microsoft 365 tenant owner setting up encryption for the first time or reviewing an existing configuration.
What O365 email encryption covers by default
Every Microsoft 365 tenant gets some encryption automatically. Exchange Online encrypts mail in transit using TLS 1.2 or higher between mail servers when both sides support it. This is the baseline any modern mail provider offers.
Exchange Online also encrypts mail at rest using BitLocker on the underlying storage and per-message encryption keys. This protects mail on disk against a physical theft or storage-layer attack.
The piece that is not on by default is the end-user Encrypt button. On-demand message-level protection requires a licensed feature, either Purview Message Encryption or S/MIME. Both are available on qualifying subscription tiers.
Compliance-covered communication requires the message-level layer in addition to the automatic transport and at-rest layers. Practices sending patient email cannot rely on the default alone. The Encrypt button is what makes the outbound message protected from server to recipient.
Licensing tiers and encryption features
Licensing determines which encryption features are available. The mapping is not obvious from the marketing pages, and admins routinely encounter tenants where the Encrypt button is missing because the license is wrong.
- Business Basic and Business Standard: TLS and at-rest encryption only, no Encrypt button
- Business Premium: full Purview Message Encryption including the Encrypt button
- Enterprise E3: full Purview Message Encryption including the Encrypt button
- Enterprise E5: Purview plus Advanced Message Encryption for branding, expiration, and revocation
- Standalone add-on: Azure Information Protection Plan 1 or 2 adds Purview to lower tiers
- Government: GCC and GCC High tenants have equivalent tiers with same feature mapping
Adding Purview to a Business Basic tenant through Azure Information Protection is technically possible but administratively awkward. Most tenants upgrade to Business Premium instead.
Confirm current licensing through the Microsoft 365 admin center before enabling encryption rules. Microsoft publishes the current feature mapping in the Microsoft Purview Message Encryption documentation.
Enabling Purview Message Encryption on the tenant
Enabling Purview requires a few specific steps. On new tenants provisioned after February 2019, Azure Rights Management is enabled by default. On older tenants, an admin needs to enable it through Exchange Online PowerShell.
Connect to Exchange Online PowerShell as a global admin. Run Enable-AadrmService to activate Rights Management on the tenant. Verify the state with Get-AadrmConfiguration. Once active, Purview Message Encryption is available to eligible users.
Assign Azure Information Protection or Message Encryption licenses to users through the admin center. Users see the Encrypt button in the Options ribbon in Outlook the next time they compose a message. Outlook on the web shows the same button in the compose interface.
Test with a compose to an external Gmail or Yahoo address before rolling out to end users. The test verifies the notification email arrives, the portal login works, and the message body renders correctly on the recipient side.
Automating encryption with mail flow rules
Mail flow rules in the Exchange admin center apply encryption automatically based on conditions. This removes the per-message decision from the sender and prevents the plaintext accident.
Common conditions include keyword lists in the subject or body, sender group membership, recipient domain matching, and attachment content patterns. A healthcare practice might trigger encryption on any outbound message to a patient domain list or containing terms like DOB, MRN, or diagnosis.
Configure the rule under Mail flow in the Exchange admin center. Add a new rule. Select Apply Office 365 Message Encryption and rights protection to the message. Choose the encryption template such as Encrypt or Do Not Forward. Save.
Test the rule with a message that matches the condition. Confirm the message is delivered encrypted. Then move on to the next rule. Complex mail flow with many rules can produce order-of-evaluation issues, so keep the rule set small and documented.
[mh_example]
Comparing Purview Message Encryption to S/MIME in O365
Both Purview and S/MIME are supported in O365. They solve different problems and are often deployed together in the same tenant for different use cases.
| Attribute | Purview Message Encryption | S/MIME |
|---|---|---|
| Recipient prerequisites | None, portal-based | Public certificate installed |
| Setup complexity | Tenant-side only | Sender and recipient certificate exchange |
| Recipient experience | Portal login | Inline in mail client |
| Reach to any address | Yes | Only PKI-equipped recipients |
| Typical fit | Business to consumer | Government, defense, enterprise PKI |
| Branding | Portal branded on Enterprise E5 | No portal to brand |
Purview is the modern default for reaching external recipients on any platform. S/MIME is the preferred path when both sides already run PKI and inline decryption is required by policy.
Practices comparing broader alternatives can review the email encryption category overview alongside the Purview and S/MIME options.
Signing and encrypting in the same message
Signing and encryption are separate operations. Some organizations require both on the same message. O365 supports this through S/MIME with certificates installed in Outlook Trust Center.
Signing uses the sender’s signing certificate to hash the message and encrypt the hash with the sender’s private key. The recipient uses the sender’s public certificate to verify the signature. This proves sender identity and message integrity.
Encryption uses the recipient’s public certificate to encrypt the message content. Only the recipient’s private key can decrypt. Applying both operations on the same message provides authenticity and confidentiality together.
Sign-only, encrypt-only, and sign-and-encrypt are all valid options. Government and financial services organizations often mandate sign-and-encrypt as the default. Healthcare practices sending patient email usually apply encryption without signing because recipients are not verifying certificate chains.
Branding the recipient portal experience
Advanced Message Encryption on Enterprise E5 supports portal branding. This changes what an external recipient sees when they open the portal to read the encrypted message.
Configure branding through Exchange Online PowerShell using Set-OMEConfiguration. Parameters include OMEConfiguration for logo URL, background color hex, disclaimer text, portal text, and email text. Multiple configurations can be created and mapped to different mail flow rules.
Branding appears when external recipients open the portal. It does not appear on messages viewed inline in Outlook by internal recipients on the same tenant. Branding does not change the encryption itself. It changes the recipient trust signal.
Practices with a website and consistent visual identity often extend the same branding to the encrypted portal. Redefine Web covers the underlying identity work in the overview of healthcare web design.
Encryption at rest and mailbox-level protection
At-rest encryption in Exchange Online uses BitLocker on the underlying storage. This is transparent to admins and users. Every stored mail item is encrypted at the storage layer.
Customer Key is an option on Enterprise E5 and Advanced Compliance add-ons. It allows the customer to provide their own encryption keys used alongside Microsoft-managed keys. Losing the customer key results in permanent data loss, so key management overhead is significant.
Customer Key is a control for regulated industries that require key custody separate from the platform provider. For most healthcare and business use cases, Microsoft-managed keys are sufficient and much easier to operate.
Microsoft publishes the at-rest encryption architecture in the Microsoft Purview encryption reference. The design is aligned with NIST cryptographic guidance in NIST SP 800-52 Rev. 2.
[mh_protip]
Known limitations and workarounds
Every encryption system has limits. Documenting them in advance saves helpdesk hours later.
- Branding does not appear on messages viewed inline in Outlook, only in the portal view
- External recipients occasionally lose the portal notification to spam filtering
- Outlook 2013 requires patching and the Message Encryption add-in for the Protect button
- S/MIME needs certificate pre-exchange, which is not practical for ad hoc external sends
- Some compliance frameworks require signing in addition to encryption, doubling the setup work
Workarounds include publishing a short recipient guide, allowlisting the Microsoft notification domain on partner mail servers, and upgrading beyond Outlook 2013. Each mitigation is small individually and adds up to a smoother user experience.
Some organizations supplement O365 encryption with a dedicated email encryption service for specific use cases where the portal experience is not suitable. The two can coexist through mail flow rules that route matching messages through the vertical vendor.
Operational monitoring and audit trails
Encryption is only useful if it stays on. Operational monitoring catches drift, misconfiguration, and user error before they turn into compliance events.
Enable audit log retention for at least six years in the Microsoft Purview compliance portal. HIPAA record-keeping applies to policies and procedures, and the audit log is the evidence trail during any Office for Civil Rights inquiry.
Monitor the Encrypt button usage through Message Trace and Advanced Message Encryption reports. Users who never use the button after a rollout are either not sending sensitive mail or are bypassing the encryption workflow. Both cases warrant follow-up.
Review mail flow rule hits monthly. A rule that produced regular hits then stopped may indicate an upstream change that broke the trigger. Diagnosing early prevents a silent gap in encryption coverage.
Practical rollout plan for a new O365 encryption deployment
A first-time O365 encryption deployment can run in one afternoon for a small tenant or across two weeks for a larger organization. The key stages are the same.
Confirm licenses cover the target user population. Enable Azure Rights Management if not already active. Configure mail flow rules for the initial triggers, such as external mail with specific keywords. Assign encryption-eligible licenses to pilot users.
Pilot with five to ten users for two to three weeks. Collect feedback on the sender workflow and the recipient portal experience. Adjust mail flow rules and branding based on the pilot findings. Roll out to remaining users in staggered groups.
Publish a one-page recipient guide for external partners describing the portal login process. Practices with a broader compliance program should coordinate the rollout with related work such as healthcare website maintenance to keep the whole patient communication stack aligned.
[mh_faqs]
