🔑 Key Takeaways
- Outlook offers three encryption paths: Purview, native S/MIME, and third-party add-ins like Virtru.
- Purview encryption is four clicks: Options, Encrypt, pick policy, Send. External users get a portal.
- No Encrypt button usually means the wrong Microsoft 365 plan, not an Outlook bug.
- S/MIME needs an X.509 cert on both sides, which clusters use in orgs with central PKI.
- HIPAA practices need a Microsoft BAA plus Purview or S/MIME before routing any PHI through Outlook.
Sending encrypted emails in Outlook is straightforward once the correct license and configuration are in place. The confusion for most users starts with which encryption method their license supports and whether the Encrypt button in the ribbon is available at all.
This guide covers the three practical routes for encrypted email in Outlook: Microsoft Purview Message Encryption, S/MIME through certificates, and third-party add-ins. Each section includes step-by-step instructions and the license or setup requirement.
A dedicated troubleshooting section addresses the “cant send encrypted emails Outlook” errors that generate the most support tickets. Every fix is based on Microsoft’s current documentation and typical production configurations.
Three Encryption Routes in Outlook
Outlook supports encrypted email through three separate mechanisms. The right choice depends on the Microsoft 365 license, the recipient population, and whether the organization needs certificate-based zero-knowledge encryption.
Microsoft Purview Message Encryption is the most common route. It ships with Microsoft 365 Business Premium and Enterprise E3, E5, A3, and A5 licenses. Users encrypt messages with a single click in the Options ribbon.
S/MIME is the second route. It requires an X.509 certificate installed on the sender’s device and prior key exchange with the recipient. S/MIME is standards-based and interoperable across mail clients that support it, but the setup burden limits adoption.
Third-party add-ins are the third route. Virtru, Mailhippo, and Barracuda all publish Outlook add-ins that add encryption capability to Outlook regardless of the underlying Microsoft license. These add-ins fit tenants on lower license tiers or workflows that need features Microsoft native encryption does not cover.
Sending an Encrypted Email with Purview Message Encryption
Purview Message Encryption is the fastest route to encrypted email in Outlook for tenants with an eligible license. The sending workflow takes four steps.
Compose a new message in Outlook Desktop or Outlook on the web. Click the Options tab in the ribbon at the top of the compose window. Click the Encrypt button in the Options ribbon. Choose the encryption policy from the dropdown: Encrypt-Only for content encryption or Do Not Forward for encryption plus forwarding restrictions.
- Compose the message as normal (recipient, subject, body, attachments)
- Click Options in the ribbon
- Click Encrypt, then select the policy
- Click Send
Recipients on Microsoft 365 read the message inline in their inbox with no additional steps. External recipients receive a notification email with a link to Microsoft’s Message Encryption portal. They sign in with a Microsoft account, Google account, or a one-time passcode to read the message.
Sending an Encrypted Email with S/MIME in Outlook Desktop
S/MIME encryption in Outlook Desktop requires an X.509 certificate installed in the Windows certificate store on the sender’s machine. The certificate can be issued by an internal certificate authority or a commercial CA.
Once the certificate is installed, configure Outlook to trust it. Open Outlook, click File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings. In the Security Settings Name dropdown, name the profile. Under Signing Certificate and Encryption Certificate, click Choose and select the S/MIME certificate. Click OK.
To send an encrypted message, compose the message as normal. Click the Options tab and select Encrypt (or Sign, if digital signing only). Send. For encryption to work, Outlook needs the recipient’s public certificate. If the recipient has sent a previously signed message, Outlook captures the certificate automatically.
Our companion piece on how to send encrypted emails covers the S/MIME setup in more depth including certificate procurement from commercial CAs.
Understanding Encrypt-Only Versus Do Not Forward
The Encrypt button dropdown in Outlook offers two Purview policies: Encrypt-Only and Do Not Forward. The difference matters because it affects what recipients can do with the message after they read it.
Encrypt-Only applies message-level encryption to the content in transit and at rest. Recipients can read, reply, forward, print, and copy the content freely once decrypted. The encryption protects against server-side exposure and network interception.
Do Not Forward adds rights management restrictions on top of encryption. Recipients using compliant clients cannot forward, print, or copy the content. The restrictions are enforced by the recipient’s mail client, so they may not hold in all environments (particularly on mobile clients or non-Microsoft mail apps).
Choose Encrypt-Only when the concern is transport and mailbox exposure and the recipient needs full flexibility to work with the content. Choose Do Not Forward for messages containing internal deliberations, confidential negotiations, or sensitive personnel information where distribution controls matter.
A 12-clinician orthopedic practice on Microsoft 365 Business Standard tried to send an MRI report to a referring surgeon and found no Encrypt button in the Outlook ribbon. IT verified the plan in the admin center, upgraded three clinical mailboxes to Business Premium at $22 per seat per month, and confirmed Azure Rights Management showed Activated. The Encrypt button appeared within 45 minutes of license assignment. A test send to a Gmail address delivered a portal link that opened after a one-time passcode.
Fixing “Cannot Send Encrypted Emails” Errors in Outlook
The most common cause of the “cant send encrypted emails Outlook” error is a license mismatch. Purview Message Encryption is not included in Microsoft 365 Business Basic or Business Standard. The Encrypt button in the ribbon does not appear when the license is not eligible.
Verify the license in the Microsoft 365 admin center at admin.microsoft.com. Navigate to Billing, Licenses, and confirm the assigned license is Business Premium, E3, E5, A3, or A5. If the license is Business Basic or Business Standard, upgrade to enable Purview Message Encryption.
The second common cause is Azure Rights Management being disabled at the tenant level. In the admin center, navigate to Settings, Org settings, Services, and confirm Rights Management is set to Activated. Microsoft’s documentation at learn.microsoft.com purview ome covers the tenant-level activation steps.
The third common cause is Outlook not being fully signed in to the Microsoft 365 mailbox. Check the account status in File, Account Settings and confirm the account shows as connected. Sign out and sign back in if the account shows as offline or unauthenticated.
Encrypted Emails in Outlook on the Web
Outlook on the web (outlook.office.com) supports Purview Message Encryption with the same license eligibility as Outlook Desktop. The compose window includes an Encrypt option in the toolbar.
Click New message. Compose the message. Click the ellipsis (three dots) in the message toolbar. Select Encrypt, then choose the policy. The recipient experience matches the Desktop workflow.
Outlook on the web does not support S/MIME as fully as Outlook Desktop. Some S/MIME features require the S/MIME extension for Edge or Chrome. Organizations relying on S/MIME should standardize on Outlook Desktop or accept the reduced feature set in the web client.
For workflows where users move between Desktop and web frequently, Purview Message Encryption provides a consistent experience. S/MIME works best when the user consistently uses Outlook Desktop.
Encrypted Emails in Outlook Mobile
The Outlook mobile app for iOS and Android supports Purview Message Encryption for both sending and reading. The interface mirrors the desktop workflow with an Encrypt option in the compose menu.
To send an encrypted message on mobile, tap New Message. Compose the message. Tap the three-dot menu. Tap Encrypt and select the policy. Tap Send.
S/MIME on mobile is more limited. iOS Mail supports S/MIME natively when a certificate is provisioned through a configuration profile. Outlook mobile has limited S/MIME support and generally requires organization-specific configuration through Intune or a similar mobile device management platform.
For practices where mobile use is heavy, Purview Message Encryption provides a smoother path than S/MIME. Users who need S/MIME on mobile should plan on iOS with MDM-managed certificates rather than trying to make it work on Android or Outlook mobile.
License upgrades alone do not always surface the Encrypt button. Azure Rights Management must be Activated at the tenant level under Settings, Org settings, Services. Roughly one in five license-upgrade tickets stall here because the tenant was provisioned before automatic activation became default. Activating takes two clicks in the admin center, and the button appears in Outlook after the client resyncs licenses (usually within an hour).
Encrypted Emails in Outlook for HIPAA Compliance
Healthcare practices sending PHI through Outlook need a Business Associate Agreement (BAA) covering the Microsoft 365 tenant. Microsoft signs a BAA for Business and Enterprise plans but not for free Outlook.com accounts.
The BAA plus TLS in transit plus encryption at rest satisfies the HIPAA Security Rule’s transmission and storage safeguards. Adding Purview Message Encryption or S/MIME provides additional message-level protection. HHS publishes BAA guidance at the HHS BAA reference page.
Practices should confirm the BAA is signed before sending PHI. The Microsoft 365 admin center under Compliance shows the BAA status for enterprise agreements. For Business tier agreements, the BAA is typically part of the Microsoft Products and Services Data Protection Addendum available from the Microsoft Trust Center.
Our team at Redefine Web has published guidance on healthcare website security features for practices building broader HIPAA programs beyond email.
Third-Party Encryption Add-Ins for Outlook
Tenants on Microsoft 365 Business Basic or Business Standard cannot access Purview Message Encryption. Rather than upgrading the whole tenant license, some practices add a third-party encryption product that includes an Outlook add-in.
Common options include Virtru (browser and Outlook add-in), Barracuda Email Gateway Defense (Outlook add-in through the gateway), and inbox-native services such as Mailhippo (Outlook add-in with recipient inbox delivery).
These add-ins install through Microsoft AppSource and integrate into the Outlook compose window. Users click an encryption button in the ribbon or toolbar to route the outbound message through the service.
The trade-off is that the sender manages two encryption tools if the tenant also uses Purview. For small practices, standardizing on a single add-in and skipping Purview keeps the workflow simpler. Larger organizations that already own Business Premium or higher typically standardize on Purview and use add-ins only for niche workflows.
Opening and Forwarding Encrypted Emails in Outlook
Recipients on Microsoft 365 read Purview-encrypted messages inline in Outlook Desktop, Outlook on the web, or Outlook mobile. No additional steps are required.
External recipients receive a notification email with a Read the message button. Clicking opens Microsoft’s Message Encryption portal in a browser. The recipient signs in with a Microsoft, Google, Yahoo, or one-time passcode option. The decrypted message displays. Our companion piece on how to open encrypted emails in Outlook covers this flow.
Forwarding an encrypted email depends on the policy. Encrypt-Only messages can be forwarded and remain encrypted in transit. Do Not Forward messages are blocked from forwarding in compliant clients. S/MIME messages can be forwarded, but the forwarding recipient must have the original recipient’s public certificate for the encryption to reach them successfully.
For practices where forwarding is common (referrals, care coordination), Encrypt-Only is usually the correct default policy. Do Not Forward suits legal, personnel, and executive communications where distribution controls matter more than workflow flexibility.
Frequently Asked Questions
Open a new message in Outlook Desktop or Outlook on the web. Click the Options tab in the ribbon. Select Encrypt and choose either Encrypt-Only or Do Not Forward from the dropdown. Compose the message and click Send. Recipients on Microsoft 365 read the message inline. External recipients receive a portal link to read through Microsoft’s Message Encryption portal. This method requires the tenant to have Microsoft 365 Business Premium or higher, or an Enterprise E3, E5, A3, or A5 license.
The most common cause is a license issue. Microsoft Purview Message Encryption is not included in Microsoft 365 Business Basic or Business Standard. Upgrading to Business Premium or higher enables the Encrypt button in the ribbon. Other causes include Azure Rights Management being disabled at the tenant level, Outlook not being connected to the Microsoft 365 mailbox, or corporate policies blocking the encryption option. Verify the plan in the Microsoft 365 admin center and confirm the correct account is signed in to Outlook.
Encrypt-Only encrypts the message content in transit and at rest. Recipients can read, reply, forward, print, and copy the content. Do Not Forward encrypts the message and applies rights management restrictions that prevent forwarding, printing, and copying (for recipients using clients that honor those restrictions). Do Not Forward is enforced by the recipient’s mail client, so restrictions may not hold on all clients. Choose Encrypt-Only when the concern is transport and mailbox exposure. Choose Do Not Forward for additional distribution controls.
Obtain an S/MIME certificate from an internal certificate authority or a commercial certificate authority such as Sectigo or DigiCert. Install the certificate in the Windows certificate store on the machine running Outlook. Open Outlook, go to File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings and select the certificate. Save. To send encrypted, compose a message, go to Options in the ribbon, and select Encrypt (S/MIME option) if the recipient’s certificate is already known to Outlook.
Yes. External recipients read Purview-encrypted messages by clicking a link in the notification email that opens Microsoft’s Message Encryption portal. They sign in with a Microsoft account, Google account, or a one-time passcode. The portal displays the decrypted message. For S/MIME encrypted messages, the external recipient must have their own S/MIME certificate and a mail client that supports S/MIME. Not all external recipients meet those requirements, so Purview is more practical for mixed audiences.
Encrypted email in Outlook satisfies HIPAA when three conditions are met. The Microsoft 365 tenant must be on a plan for which Microsoft signs a BAA (Business or Enterprise, not free Outlook.com). Encryption must be applied to PHI-containing messages using Purview Message Encryption or S/MIME. The organization must have documented policies and access controls consistent with the HIPAA Security Rule. Meeting all three keeps Outlook-based email HIPAA-compliant for most healthcare workflows. Practices should verify the BAA is signed before sending PHI.
Forwarding behavior depends on the encryption method and policy. An Encrypt-Only message can be forwarded by the recipient and remains encrypted at the transport level. A Do Not Forward message is blocked from forwarding in clients that honor the restriction. An S/MIME encrypted message can be forwarded, but the forwarding recipient must have the original recipient’s certificate or the sender re-encrypts to the new recipient. Forwarding across encryption boundaries (Purview to S/MIME or vice versa) often falls back to unencrypted or requires re-encryption at the forwarding client.
