• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Online / Automatically encrypting Exchange Online emails with Office 365 Message Encryption

Automatically encrypting Exchange Online emails with Office 365 Message Encryption

March 20, 2019 by Mike Parker 6 Comments

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:

1
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:

1
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.

Exchange Online Office 365 Message Encryption

Comments

  1. Phillip Kenyon says

    January 29, 2020 at 4:08 am

    Mike, Really appreciate the guide. I wrote a script to semi-automate adding domains to such a rule set, in a case where your org wants to sort of ‘OME if TLS fails’ type of situation. Theres a write up over on Tech Community : https://techcommunity.microsoft.com/t5/exchange/forcing-message-encryption-on-certain-domains/td-p/1133382#.XjB3O6gUt4Y.link Let me know your thoughts.

    Reply
  2. Dustin says

    December 6, 2019 at 11:52 pm

    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?

    Reply
  3. Frank says

    October 2, 2019 at 8:13 am

    In your fist example when sending an email to practical365.com 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?

    Reply
  4. sankar says

    April 26, 2019 at 4:49 am

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

    Reply
  5. Rachel says

    March 26, 2019 at 1:14 am

    This is really useful, thanks

    Reply
  6. Oleg K says

    February 20, 2019 at 5:23 pm

    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).

    Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Hands-on SharePoint Syntex Blog Series – Part I
  • The Practical 365 Weekly Update: S2, Ep 8 – What to expect in 2021, Solarigate, TLS in Exchange and new Teams updates
  • Security updates released for Exchange and SharePoint Servers 2010 to 2019
  • The Practical 365 Weekly Update: S2, Ep 7 – Urgent Exchange security updates, new Teams features launch
  • How to train your users against threats with Attack Simulation Training
Practical 365

Related Posts

Related Posts

Training Courses

  • Configuring and Managing Office 365 Security
  • Office 365 Admin Playbook
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • More Training Courses...

Recommended Resources

  • Office 365 Security Resources
  • Office 365 Books
  • Exchange Server Books
  • Exchange Server Migrations
  • Exchange Analyzer
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials. Read more...

Find out more about advertising with us.

Contact us


Subscribe to our newsletter
  • Facebook
  • Twitter
  • RSS
  • YouTube

Copyright © 2021 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland