Automatically encrypting Exchange Online emails with Office 365 Message Encryption

Last year Microsoft released additional functionality to Office 365 Message Encryption (OME) including a new encryption template “Encrypt Only” which, unlike “Do Not Forward”, only encrypts the email using OME. Once decrypted by the recipient, the message can be treated like any other. Later in 2018, Microsoft announced this had been trialed and that they would also be releasing default transport rules within Office 365 to automatically encrypt emails containing sensitive information types using the “Encrypt Only” template. However, following feedback from the community between December and the end of January, Microsoft announced on January 30th this was no longer going ahead and provided guidance on how to implement the same rules yourself if this functionality is beneficial to your organization.

In October 2018, we worked with a small sample of customers to understand if we can simplify protection by automatically encrypting sensitive emails based on certain sensitive information types. Based on positive feedback from this sample, we decided to expand to a more diverse profile of tenants in December 2018. After communicating the next roll-out to select tenants, we listened to your feedback and determined that customers with more complex environments wanted to implement the rules more cautiously, and we are therefore adjusting our plans.”

Clearly, there was a feeling that the move was going to cause too much disruption. For many organisations and users, this would have been challenging to prepare for because of the potentially large impact it not only had on them, but also their recipients. Although Microsoft’s intention was unquestionably good, as most organisations are constantly seeking ways to have better processes for sensitive information, it just wasn’t feasible at this time.

The original Microsoft intention was to encrypt messages that contained the following sensitive information types:

  • ABA routing number
  • Credit card number
  • Drug Enforcement Agency (DEA) number
  • U.S./U.K. passport number
  • U.S. bank account number
  • U.S. Individual Taxpayer Identification Number (ITIN)
  • U.S. Social Security Number (SSN)

If you want to apply this transport rule you can still complete this by manually configuring the transport rule and message encryption settings in Office 365. Firstly, you should connect to Exchange Online PowerShell using instructions in this post. Then, run the following command to update the Office Message Encryption settings:

 Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $true 

This command configures OME to only encrypt the email itself, and not the attachments contained within the email. This means that once the user has decrypted the email by logging in or verifying their identity, they have full access to open, edit, print or forward the attachment as with any other email. If you don’t run this command when the user decrypts the email, the attachments will remain protected and Read-Only.

Once the attachment configuration has been updated you can then create the transport rule using the following command:

New-TransportRule -Name "Encrypt outbound sensitive emails (out of box rule)" -SentToScope  NotInOrganization  -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="Drug Enforcement Agency (DEA) Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -NotifySender "NotifyOnly"

You can then view and update the transport rule from within the Exchange Online Admin Center should you want to. You could also add any custom sensitive information types you might have configured in your tenant to this same rule should you want to.

Although there seems to be a general consensus that this rule shouldn’t be added or enabled by default, as I mentioned before, a move to encrypting more email by default should be considered, and you don’t need to limit the scope of this to only sensitive information type. You can apply the Encrypt template to any emails you can identify using an Exchange Online transport rule.

For example, you could target specific recipient domains:

Office 365 Message Encryption

Or you could encrypt messages with a specific subject string:

Office 365 Message Encryption screenshot

This is one of many ways for you to apply encryption automatically to best suit your organisation, and better yet to protect your users from data leaks and improve data security.

About the Author

Mike Parker

Mike is a Technical Architect at Content and Code, a multiple award-winning Microsoft Partner. He has spent the last five years working closely with Microsoft 365 technologies. Mike’s primary area of focus is in the delivery of the Microsoft 365 suite, including the Office 365 suite and Enterprise Mobility + Security, for a range of global enterprise clients. Mike blogs at, speaks at internal and public events when time allows!


  1. Muk

    I am trying for a while to setup a rule in Exchange Online to encrypt messages with a RMS template, but for some reason i cant choose for an encryption with code, so that if you receive the message, you ask for a code to get the original message.

    Does anyone know how to fix this?

    1. Avatar photo
      Tony Redmond

      It depends on the client being used by the recipient and their account. Accounts in M365 tenants using clients that know how to interact with MIP will fetch the necessary use licenses etc. and display the decrypted content inline. Others will prompt for a code to allow them to read the message via the MIP portal. AFAIK, you can’t force an “enlightened” client to use a code because this would be too disruptive to the flow of receiving and reading messages.

  2. Greg C

    Please tell me this encrypt policy doesn’t send a separate email through the same potentially compromised mail channel with the password? LOL? Maybe they should come up with an “auto stickie note” that pops up in the receiver’s screen with the password? How dumb is that.

  3. Ryan Jones

    I had tested a year or so back with the ome version and had a rule with keyword and an auto encrypt that would look for sensitive info like socials etc. Completely working. Fast forward, none of that works so I switched to the new 365 encryption. The keyword rule works fine but the auto encrypt for sensitive info does not. Microsoft claims i need an e5 license despite having the Azure information protection. I’m completely lost on this. They are all the time changing things and it’s almost a full time job just to read updates. Anyone know if this is true or do you have an auto rule setup to encrypt with the new encryption that is working? I have business premium and azure information protection.

    1. Luis M

      I am having similar situation. My rule stopped working and now I can not make it work nor with the old OME encryption neither with the new 365. I have an on premises exchange routed thru online exchange. A guy in support told me that I have to migrate to online for it to work. I don’t believe what he said I will have to get someone else from support

  4. Dustin

    Thanks for the tips here. I’m using Tor private browser and Surfshark VPN, but I guess it’s time to upgrade my security level and learn how to send encrypted emails. I was thinking about getting something like Protonmail, would you say it’s safe to use?

  5. Frank

    In your fist example when sending an email to and cc’ing a friend on gmail the email to *both* will be encrypted which is a pain.

    Is there a way to avoid this scenario so the gmail side never sees the encryption?

  6. sankar

    we have enabled this AIP flag but the end user not able to open the email in the outlook client. any thoughts

  7. Rachel

    This is really useful, thanks

  8. Oleg K

    Microsoft also warned that OME won’t coexist normally with old on-premise RMS services, so RMS has to be deprovisioned first or OME should be disabled (at least partly, updates to OME functionality should be disabled with a command).

Leave a Reply