Unable to Open Encrypted Email in Outlook and Microsoft 365

8.7K

In this tutorial we will show how to open and troubleshoot Microsoft 365 encrypted emails using Outlook, OWA, and mobile apps.

What Is Microsoft Purview Message Encryption?

The Microsoft 365 subscription allows users to use a native email encryption solution called Microsoft Purview Message Encryption (formerly Office 365 Message Encryption, OME). Microsoft Purview Message Encryption can be used to send encrypted emails to internal and external recipients, and it doesn’t require any special client-side software.

There are several reasons why a user might not be able to open an encrypted Microsoft 365 email.

How Microsoft 365 Email Encryption Works

When a recipient opens a Microsoft Purview Message Encryption message, the decryption flow depends on the recipient and client. For an internal recipient using a supported Outlook client, the client authenticates the user, obtains the required usage rights from Azure Rights Management, and decrypts the protected message locally before displaying it.

The process can be summarized as follows:

1. The recipient authenticates with Microsoft Entra ID or, for supported external-recipient scenarios, completes the required authentication or one-time passcode flow.
2. The Outlook client or Microsoft 365 service requests the information required to access the protected content.
3. Azure Rights Management evaluates the protection policy and the recipient’s usage rights.
4. For supported internal Outlook cases, the client obtains the required use license and performs the decryption locally.
5. Outlook displays the protected message according to the usage rights granted by the protection policy.

For external recipients who use the Microsoft-hosted encrypted message portal, Microsoft 365 can perform the necessary processing on the service side and present the decrypted message through the secure web experience. This is different from the client-side decryption performed by supported Outlook clients.

Reading Encrypted Email in Outlook and Outlook on the web

Recipient doesn’t need Outlook or a Microsoft 365 account to open the encrypted email. External recipients then receive a secure email, seeing only the email subject and a button to read the message. When the user clicks the Read the Message link, they are redirected to Outlook on the web to verify their account using a trusted OAuth provider or a one-time passcode.

In case the recipient is already authenticated in Microsoft Entra ID, Outlook/OWA retrieves a decryption key from the MS Rights Management Service (RMS). This allows the message to be displayed flawlessly.

If you receive an encrypted message and open it in Outlook on the web, it will be decrypted automatically. In this case, under the subject and recipient in the header of the letter, the following information will appear:

Encrypt: This message is encrypted. Recipient can’t remove encryptions.
Permission granted by: username

Review Microsoft Purview Message Encryption Labels

Emails sent from a Microsoft 365 tenant can be automatically encrypted using sensitivity labels and mail flow (transport) rules. Sensitivity encryption label settings can restrict the list of users who are allowed to decrypt messages.

Keep in mind that sensitivity labels can also affect the message based on labeled attachments. In supported Outlook and Microsoft Purview configs, a sensitivity label applied to an attachment can be inherited by the email or trigger a label recommendation for the message. When troubleshooting encrypted email, you need to check both the label applied directly to the message and any labels applied to its attachments.

1. Go to the Microsoft Purview portal > Solutions > Information Protection > Sensitivity labels, and find the label used for message encryption;
   

   

2. Check which users or groups are allowed to access content protected by the label. Also verify whether the label is being inherited or recommended from a labeled attachment;
3. Verify that the user who cannot decrypt the email has permissions to view the content. In case the message inherited its label from an attachment, you should verify the protection settings of the attachment’s label as well;
   

   

4. This is where you can grant permissions to decrypt messages to specific e-mail addresses or domains, or to any authenticated user (which is less secure).

Check Message Delivery Status

Before troubleshooting Outlook, Microsoft Purview Message Encryption, or Azure Rights Management issues, you should check if the encrypted message was successfully delivered to the recipient mailbox.

First, connect to Exchange Online PowerShell:

Connect-ExchangeOnline

Now search for the message delivery status:

Get-MessageTraceV2 `
-RecipientAddress user@contoso.com `
-StartDate (Get-Date).AddDays(-7) `
-EndDate (Get-Date)

Review the trace results and identify the message. Then retrieve detailed transport info:

Get-MessageTraceDetailV2 `
-MessageTraceId <MessageTraceId> `
-RecipientAddress user@contoso.com

The V2 cmdlets support a larger historical search window (up to 90 days, queried in smaller time ranges), making them better suited for investigating older mail delivery issues than the legacy cmdlets.

Note. This article uses the modern Get-MessageTraceV2 and Get-MessageTraceDetailV2 cmdlets. The legacy Get-MessageTrace and Get-MessageTraceDetail cmdlets have been deprecated by Microsoft and you should not use them longer in new scripts.

At this step you should check whether:

• The message was successfully delivered;
• An Exchange Online transport rule applied encryption;
• The message was redirected, quarantined, or rejected;
• Delivery failures occurred before the recipient attempted to open the encrypted email.

In case the message was never delivered successfully, troubleshooting Outlook, OWA, authentication, or Microsoft Purview encryption settings will not resolve the problem. You should always verify successful message delivery first.

We Can’t Display Your Encrypted Message Right Now in Outlook

In some cases, when authenticating with a Microsoft account or one-time passcode, you may receive errors:

An error has occurred.  We’re sorry. An unknown error has occurred. Please try again later.

Or:

Sorry, we can’t display your message right now. Something went wrong and your encrypted message couldn’t be opened. Please try again by following the instructions in the original email message in 5 minutes.

In some cases, encrypted emails cannot be opened due to multiple possible causes beyond Outlook add-ins/OWA MIME config. These common root causes include authentication token issues, Microsoft Entra ID sign-in failures, Conditional Access restrictions, expired/invalid Rights Management (IRM) licenses, or misconfigured Microsoft Purview Information Protection policies.

In case the problem persists, you need to try the following additional checks:

• Microsoft Entra ID authentication issues related to expired tokens, broken sign-in session
• Conditional Access policies may be blocking external/unmanaged devices
• Azure Rights Management (RMS) service is unavailable/misconfigured
• Required Microsoft Purview/Information Protection licenses are missing
• User is not in allowed group due to Microsoft Purview sensitivity label restrictions
• Corrupted Outlook profile/Exchange Online mailbox sync issues
• The user opened message under different account than intended
• External recipient not completing OTP/Microsoft account verification flow

Verifying Azure Rights Management Config

Microsoft Purview Message Encryption relies on Azure Rights Management Services (RMS) to issue decryption licenses and enforce message protection policies. In case RMS is misconfigured/unavailable, you may be unable to open encrypted messages even when Outlook and authentication are functioning correctly.

To connect to the Microsoft Purview Information Protection service, run the command:

Important. Note that the AIPService PowerShell module requires a compatible PowerShell version. If you are using an older AIPService module, run these commands in Windows PowerShell 5.1. PowerShell 7 support was added in AIPService module 3.1.0.0.

Connect-AipService

Review the current Azure Rights Management config with the command:

Get-AipServiceConfiguration

In case Connect-AipService fails with Object reference not set to an instance of an object, you need to check the installed AIPService module version and PowerShell version before troubleshooting authentication/licensing. Older versions of the module do not support PowerShell 7. Update the module to version 3.1.0.0 or later, or run the commands in Windows PowerShell 5.1.

Get-Module AIPService -ListAvailable
$PSVersionTable.PSVersion

Review the following values in the output:

• FunctionalState should be Enabled.
• Templates should contain the expected Rights Management templates.
• LicensingIntranetDistributionPointUrl and LicensingExtranetDistributionPointUrl should contain valid Azure Rights Management licensing endpoints.
• CertificationIntranetDistributionPointUrl and CertificationExtranetDistributionPointUrl should contain valid Azure Rights Management certification endpoints.
• AzureInformationProtectionServiceId should be populated.

In Exchange Online, you should check if Azure RMS licensing is enabled:

Get-IRMConfiguration

You need to review the output for the following properties:

• AzureRMSLicensingEnabled — should be True when Azure Rights Management licensing is enabled for Exchange Online.
• RMSOnlineKeySharingLocation — check if the expected Azure Rights Management endpoint is configured.
• ServiceLocation, PublishingLocation, and LicensingLocation — check if the RMS endpoints are populated and valid.

Keep in mind that you should perform Azure Rights Management activation and deactivation through PowerShell. These operations are no longer available in the Microsoft Purview /other Microsoft 365 admin portals.

In case Azure Rights Management is unavailable/incorrectly configured, Outlook and Outlook on the web may fail to acquire a decryption license and encrypted messages cannot be opened.

Checking Microsoft Entra Conditional Access Policies

Keep in mind that Microsoft Purview Message Encryption requires successful authentication to Microsoft Entra ID before a decryption license can be issued. In many environments, Conditional Access policies may prevent users from accessing encrypted messages even when the message was delivered successfully.

Common Conditional Access cases that may block encrypted email access include:

• Unmanaged/non-compliant devices;
• Geographic location restrictions;
• Multi-Factor Authentication (MFA) requirements;
• Sign-in risk policies;
• Conditional Access policies targeting internal users/Microsoft Entra B2B guest users;
• Session controls that block browser-based access.

In case you receive errors such as Sorry, we can’t display your message right now or Something went wrong and your encrypted message couldn’t be opened, you need to review the user’s Microsoft Entra sign-in logs.

First, connect to Microsoft Graph PowerShell with the command:

Prerequisites. Keep in mind that viewing Microsoft Entra sign-in logs requires the appropriate Microsoft Entra permissions and licensing. The admin running this command must have a role that can read sign-in logs (such as Reports Reader or Security Reader), and the tenant must have the appropriate Microsoft Entra ID licensing for the sign-in logs being accessed.

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Now review recent sign-in events using the following command (ensure you are connected to the correct tenant):

Get-MgAuditLogSignIn `
    -Filter "userPrincipalName eq 'user@contoso.com'" `
    -Top 50 |
    Select-Object ConditionalAccessStatus,
        @{Name='ErrorCode'; Expression={$_.Status.ErrorCode}},
        AppDisplayName,
        ResourceDisplayName

Here you need to check for:

• Conditional Access failures;
• MFA challenges that were not completed;
• Blocked sign-in attempts;
• Device compliance failures;
• Guest access restrictions.

You can also review sign-in activity in the Microsoft Entra admin center:

1. Open Microsoft Entra admin center;
2. Go to Identity > Monitoring & Health > Sign-in logs;
3. Here locate the affected user;
4. Review Conditional Access and authentication details for failed sign-ins.

Note that Conditional Access policies are one of the most common causes of Microsoft Purview Message Encryption access failures (particularly for external recipients and users accessing email from unmanaged devices).

Note that in case Conditional Access blocks token issuance, Microsoft Purview Message Encryption will fail even if the message is successfully delivered and RMS is healthy.

Troubleshoot Outlook Client-Specific Issues

In case encrypted emails open successfully in Outlook on the web but fail in the Outlook desktop client, you need to find out which Outlook client the user is using before troubleshooting add-ins.

Classic Outlook for Windows

In Classic Outlook, third-party COM add-ins can interfere with Outlook functionality. In order to test if a COM add-in is causing the problem, follow the steps below:

1. Select File > Options > Add-ins.
2. At the bottom of the window, select COM Add-ins next to Manage, and then select Go.
3. Temporarily disable non-Microsoft COM add-ins.
   

   

4. Restart Outlook and try to open the encrypted message again.

New Outlook for Windows

New Outlook for Windows uses a different architecture and does not support COM or VSTO add-ins. It uses Outlook web add-ins instead. To troubleshoot add-ins in new Outlook, follow the steps below:

• Select More apps > Add apps from the Outlook navigation bar/ribbon.
• Open Manage your apps and review the installed Outlook add-ins.
• Temporarily remove/disable a suspected third-party web add-in, if permitted by your organization’s policies.
• Restart new Outlook and test the encrypted message again.

If the message opens in Outlook on the web but not in new Outlook, compare the behavior after removing the suspected web add-in. Also don’t forget to check if the issue is not related to authentication, Conditional Access, or the protected-message policy itself.

Because new Outlook and Outlook on the web use a closely related web-based architecture, reproducing the problem in Outlook on the web is an important diagnostic step.

View Encrypted Microsoft 365 Email on iOS and Android

If you want to use an iOS/Android mobile device to read secure emails, be sure to install and use Outlook for Mobile. The native iOS email app doesn’t support encrypted emails from Microsoft 365.

Note that iOS native Mail does not natively support OME encrypted message rendering. But external recipients can still open encrypted emails: they can do that via a secure web browser session triggered from the message link.

When you receive an encrypted message in alternative application, you will see the following text (and the encrypted message file with the *.rpmsg extension — Rights-Managed Email Message will be attached to the email):

This message is protected with Microsoft Information Protection. You can open it using Microsoft Outlook, which is available for iOS, Android, Windows, and Mac OS. Get Outlook for your device.

Microsoft Information Protection allows you to ensure your emails can’t be copied or forwarded without your permissions.