Office 365 Message Encryption (Part 3)

If you would like to read the other parts in this article series please go to:


This is the third and final part of an article series looking at the Office 365 Message Encryption service. In parts one and two, I’ve configured my Office 365 lab tenant with the Azure Rights Management service to facilitate message encryption, then went on to setup the necessary transport rules in Exchange Online. I then saw how messages could be sent and received when they were encrypted, and how users can use the one-time password feature of the service to easily view encrypted messages.

Here in part three, I am going to finish this article series by looking firstly at mobile devices and how users on devices such as Windows Phone can view encrypted messages. I will then move on to looking at decrypting replies to encrypted messages and the overall branding options I have in the message encryption service, before finishing with a very brief look at troubleshooting.

Mobile Devices

In part two of this article series, I showed what my experience of the Office 365 Message Encryption user experience looked like when using Outlook Web App. What if I was to send an encrypted message to my external mail contact, who is outside of the organization, and that contact happens to be using a mobile device? What sort of experience do they have?

Figure 3-1 shows an encrypted message I received on a Windows Phone device. As you can see, it appears largely the same as I saw previously in OWA, in that the encrypted message contained an HTML attachment that the user had to save and open to view the contents. By downloading and opening the HTML attachment, the user was presented with the same screen that was shown earlier in part two, namely the screen where the user has to either sign in using their Microsoft account or choose to receive a one-time password.

One thing to note here regarding mobile devices is the use of the HTML attachment. To open this HTML attachment on a mobile device, Microsoft states that the mobile device browser must support Form Post. This is already the case when using Windows Phone, but this should be taken into consideration when attempting to open the attachment on other types of mobile devices.

Figure 3-1:
Encrypted Message on Windows Phone

Replying to Encrypted Messages

There are two main things I noticed when testing replies to messages that were sent using Office 365 Message Encryption. First, when the recipient of the encrypted message replied to the sender, they were automatically included into the CC line of the message. Second, and perhaps more importantly, the replies to previously encrypted messages were also encrypted. Figure 3-2 shows both of these features as experienced; notice how the sender’s email address has been automatically included in the CC line of this encrypted message that was sent.

Figure 3-2:
Encrypted Message Reply

With the reply encrypted, this meant that to view these replies, the recipients must also either sign in using their Microsoft accounts or choose the one-time password option. Should it be desired, there is a way to remove the encryption from the incoming replies; this can be achieved by another transport rule. For example, I decided to automatically decrypt replies received from the external account and to do this my required transport rule looked like the one shown in 3-3. Notice how the Do the following… action is set to Remove Office 365 Message Encryption from the message and how the sender is configured to only apply to the external account.

Figure 3-3:
Decryption Transport Rule

Message Encryption Branding

As a final area of configuration that I looked at, Microsoft provides a way to brand the encrypted messages. Specifically, there are four configuration areas that can be configured within the message encryption service. Earlier in this article series, I saw the default screen that is displayed when opening the message.html attachment that comes with the encrypted message. This screen, known as the encryption portal, is shown again below in Figure 3-4. Two of the branding options are included in this portal, represented by the red boxes. The bottom red box is where any logo will be shown.

Figure 3-4:
Encryption Portal Branding

The two areas on this portal screen that can be configured with message encryption branding are:

  • The text right at the top of the portal, which by default simply stated “Encrypted Message”
  • The area at the bottom of the portal, which can contain a company logo. As you can see from Figure 3-4, by default no logo was included as might be expected

To configure these two branding areas, I used PowerShell when connected to my Office 365 lab tenant. The PowerShell command I used is the Set-OMEConfiguration cmdlet. To see what parameters I could use, I first ran the Get-OMEConfiguration cmdlet as shown in Figure 3-5.

Figure 3-5:
Default OME Configuration Settings

It should become apparent from Figure 3-5 that the two parameters I was interested in for the branding associated with the screen shown in Figure 3-4 were PortalText and Image. However, before I set these, I made a note of the value of the Identity parameter in Figure 3-5, as this is required in order to run the Set-OMEConfiguration cmdlet. By default, the Identity parameter was set to “OME Configuration” as you can see.

To set the portal text, my example command is shown below. Note how “OME Configuration” was passed as the identity as just explained.

Set-OMEConfiguration “OME Configuration” –PortalText “Office 365 Message Encryption Demo”

To set a logo, an example command is shown below. One important thing to note regarding the logo is that it also appeared on the encrypted message as well as the portal so I considered the effect of that before setting the logo. In the end, I decided not to configure branding with any logo.

Set-OMEConfiguration “OME Configuration” –Image (Get-Content {path to your image file} –Encoding byte)

The result is shown below in Figure 3-6 where you can see that the branding portal text change was successfully made.

Figure 3-6:
Branded Encryption Portal

The other two branding changes were made on the encrypted messages themselves. Each encrypted message had a disclaimer contained within it that can be customized. Furthermore, the configuration elements of the branding process permitted me to add additional text within the message. This additional text appeared just above the instructions that inform the users how to view their encrypted messages. This branding element gives me an ideal opportunity to give users additional information on encrypted messages, such as a link to any company policies or procedures regarding encrypted messages for example. Looking back at Figure 3-5, you can see that these particular branding options were configured via the EmailText and DisclaimerText parameters of the Set-OMEConfiguration cmdlet.

A default, non-branded encrypted message in my Office 365 lab tenant is shown in Figure 3-2 earlier in this article. I was able to make the additional branding changes using the Set-OMEConfiguration cmdlet. First, to change the disclaimer text, my example command is next. In Figure 3-7, you can see the custom disclaimer within the red box.

Set-OMEConfiguration “OME Configuration” –DisclaimerText “Office 365 Message Encryption Demo Custom Disclaimer”

To change the email text, my example command is next.

Set-OMEConfiguration “OME Configuration” –EmailText “Office 365 Message Encryption Demo – for further information on email encryption, please contact the Service Desk”

In Figure 3-7, you can see the email text within the green box.

Figure 3-7:
Branded Encrypted Message

Troubleshooting Message Encryption

As I mentioned in part two of this article series, there could be a time when I need to investigate why a message is not being encrypted as I might expect. It’s most probably because the transport rule is not firing against that message. To confirm that the transport rule is being applied, I can use the message tracing feature. For example, I can use the Get-MessageTrace cmdlet with the –StartDate, -EndDate and –RecipientAddress parameters to narrow down my message selection as you can see from the example in Figure 3-8. I’ve used this command to narrow down my message list to a couple of messages that I know were sent with the requirement to have it encrypted via Office 365 Message Encryption.

Figure 3-8:
Searching for Messages With Get-MessageTrace

Once I know which message I am specifically looking for, I can then use the Get-MessageTraceDetail cmdlet to provide more details on the events that happened to this message. This is just a case of piping the results of the previous command into the Get-MessageTraceDetail | fl command to provide the full output. As I reviewed the output, I looked for the Transport rule event that indicated that the Office 365 Message Encryption transport rule I created was successfully applied to the message. An example of what this might look like is shown below in Figure 3-9. Here you can see that the Encrypt to Neil transport rule had been applied to this message, so I was pretty sure that the encryption transport rule had fired successfully.

Figure 3-9:
Get-MessageTraceDetail Extract

I could also examine the message headers to reveal whether encryption had been applied. Specifically, I looked for the X-MS-Exchange-OMEMessageEncrypted header and ensured that it had a value of true.


That completes this look at the Office 365 Message Encryption service where setting up and using the service was covered. If you’ve not used this service before and have just completed reading this article series, I’m sure you’ll agree that this is an excellent service that is very easy to use both from the administrator and end-user perspectives. Hopefully you’ll now test it for yourself.

If you would like to read the other parts in this article series please go to:

About The Author

2 thoughts on “Office 365 Message Encryption (Part 3)”

  1. very useful !!!!
    especially he troubleshooting! thanks
    so the
    Get-MessageTrace cmdlet –StartDate, -EndDate –RecipientAddress should be piped to
    “Get-Messagetracedetail | fl”
    or does the get-messagetracedetail have to be ran against another value?

  2. Thanks, everything is working fine except the OTP, when an external user (gmail, yahoo, etc..) tries to use the OTP option the email with the passcode never arrives (it’s not in junk, received or any other folder). Any suggestion?

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top