Back
Office 365

Introducing Office 365 Message Encryption: Send encrypted emails to anyone!

Shobhit Sahay is product marketing manager on the Microsoft Exchange team.

We’re pleased to announce the upcoming release of Office 365 Message Encryption, a new service that lets you send encrypted emails to people outside your company. No matter what the destination-Outlook.com, Yahoo, Gmail, Exchange Server, Lotus Notes, GroupWise, Squirrel Mail, you name it-you can send sensitive business communications with an additional level of protection against unauthorized access. There are many business situations where this type of encryption is essential. We’ve listed just a few.

    • A bank sending credit card statements to customers over email.
    • An insurance company providing details about the policy to clients.
    • A mortgage broker requesting financial information from a customer for a loan application.
    • A healthcare provider using encrypted messages to send healthcare information to patients.
    • An attorney sending confidential information to a client or another attorney.
    • A consultant sending a contract to a client.
    • A therapist providing a patient diagnosis to an insurance company.

      Office 365 Message Encryption is the new version of Exchange Hosted Encryption (EHE). This version includes all of the capabilities of EHE plus new features, such as the ability to apply your company’s branding to encrypted messages. Like EHE, Office 365 Message Encryption works with Office 365 mailboxes as well as with on-premises mailboxes that use Exchange Online Protection.

      Here’s the added good news: Office 365 E3 and E4 users will get Office 365 Message Encryption at no extra cost. We’re including it in Windows Azure Rights Management, which is already part of E3 and E4 plans.  We’re also including it in the standalone version of Windows Azure Rights Management, without raising the price of that service. For $2 per user per month you can get a complete solution for internal and external information protection: traditional Rights Management capabilities like Do Not Forward for internal users, plus the new ability to encrypt outbound messages to any recipient.

      Let’s take a closer look at how Office 365 Message Encryption works.

      Setting up encryption

      Administrators set up transport rules to apply Office 365 Message Encryption when emails match specified criteria. Transport rules provide great flexibility and control, and can be managed via a web-based interface or PowerShell.

      Setting up the transport rules is simple. Administrators simply select the action to apply encryption or remove encryption in the Exchange admin center. This is an improvement over EHE, which required complex headers and multiple setup steps.

      You set up Office 365 Message Encryption rules in the Exchange admin center.

       

      Once the admin sets up the rules, whenever anyone in the company sends a message that matches the conditions, the message is encrypted using Office 365 Message Encryption. The outgoing message is encrypted before it is delivered to the outside mail server to prevent any spoofing or misdirection.

      Receiving and responding to encrypted messages

      When an external recipient receives an encrypted message from your company, they see an encrypted attachment and an instruction to view the encrypted message.

      The encrypted message appears as an attachment in a message in the recipient’s inbox, with instructions for how to view it. 

      You can open the attachment right from your inbox, and the attachment opens in a new browser window. To view the message, you just follow the simple instructions for authenticating via your Office 365 ID or Microsoft Account.

      Once you are authenticated, the content of an encrypted message appears.

      The Message Encryption interface, based on Outlook Web App, is modern and easy to navigate. You can easily find information and perform quick tasks such as reply, forward, insert, attach, and so on. As an added measure of protection, when the receiver replies to the sender of the encrypted message or forwards the message, those emails are also encrypted.

      When you reply to an encrypted message you’ve received, your reply is also encrypted.

       

      Applying custom branding

      Office 365 Message Encryption allows you to customize the branding on your company’s encrypted messages and portal where the message is viewed. The customization is not limited just to your company logo, but can also extend to the text in the header, disclaimer, and the portal text in the sent email.

      Screenshot of custom branding with Message Encryption

      With Message Encryption, you can customize the disclaimer text and header text in your company’s encrypted emails.

      You can also customize your company Logo and portal text that appear in your encrypted emails.

      Administrators can use PowerShell cmdlets to set up the branding for these texts and images.


      PowerShell can be used to set up different branding texts and logo emails encrypted in Message Encryption.

       

      With Office 365 Message Encryption you can send sensitive information to people outside your organization with the confidence that that information is protected. We’re excited to bring its new capabilities to you, and we look forward to hearing your feedback.

       – Shobhit Sahay

      FAQ:

      Q. When will Office 365 Message Encryption be available?

      A. Office 365 Message Encryption will be available for purchase during the first quarter of 2014, and customers who are currently using Exchange Hosted Encryption (EHE) will be upgraded to Office 365 Message Encryption beginning in the same timeframe. EHE customers can learn more about the upgrade by visiting the EHE Upgrade Center

      Q: How do I get Office 365 Message Encryption?

      A: Office 365 Message Encryption will be available as part of Windows Azure Rights Management. Office 365 Enterprise E3 and E4 users will get Office 365 Message Encryption at no extra cost. We’re including it in Windows Azure Rights Management, which is already part of the E3 and E4 plans. We’re also including it in the standalone version of Windows Azure Rights Management, without raising the price of that service. Office 365 Message Encryption is available as an add-on for other Office 365 plans and for standalone plans. For example, Exchange Online Kiosk Plan 1 and Plan 2 customers will be able to add the service to their subscriptions at a cost of $2 per user per month.

      Office 365 Message Encryption is also available to Exchange on-premises customers who purchase Windows Azure Rights Management service. Office 365 Message Encryption requires on-premises customers to route email through Exchange Online, either by using Exchange Online Protection for email filtering or by establishing hybrid mail-flow.

      Q. I am currently an Exchange Hosted Encryption (EHE) Subscriber. What happens to my subscription?

      Customers who are currently using Exchange Hosted Encryption (EHE) will be upgraded to Office 365 Message Encryption beginning in the first quarter of 2014. EHE customers can learn more information about the upgrade by visiting the EHE Upgrade Center.

      Q. How does Office 365 Message Encryption relate to other encryption technologies?

      A. A variety of encryption technologies work together in Office 365 to provide protection for emails at rest and in transit:

      • TLS encrypts the tunnel between mail server to help prevent snooping/eavesdropping.
      • SSL encrypts the connection between mail clients and Office 365 servers.
      • BitLocker encrypts the data on the hard drives in the datacenter so that if someone gets unauthorized access to the machine they can’t read it.
      • Information Rights Management. Windows Azure Rights Management in Office 365 prevents sensitive information from being printed, forwarded, or copiedby unauthorized people inside the organization.
      • S/MIME is an encryption scheme that uses client-side encryption keys, popular for some government B2B scenarios. Read more about the upcoming S/MIME enhancements in Office 365 here.

      Office 365 Message Encryption is designed to help you send confidential messages to people outside your company simply and securely, without the administrative overhead required to use S/MIME or similar technologies. It’s an outside-the-company companion to Information Rights Management, which is why it’s included as part of the Windows Azure Rights Management offering.

       

       

      Join the conversation

      25 comments
      1. This is great! Very excited to see this feature next year! I think it’ll add even more value to Office 365!

        • Thank you Dave. We are extremely happy to bring this new service to our customers

          • This is very good news as I have many client that have HIPPA privacy requirements. Just a couple of questions:
            1. If you are currently using Exchange Hosted Encryption (EHE), will all of the encryption rules migrate and work as they had previously or will they have to be tweaked?

            2. Is the regex syntax still used?

            3. Does Microsoft have a guideline for rule creation that would explain all of the rule syntax? I have never been able to find on and have had to use some trial and error?

            4 . Does this totally eliminate Voltage?

            Thanks – Frank Zurek

            • Hi Ipartners.

              1. Yes, as part of upgrade from EHE to Office 365 Message Encryption , we will migrate over the new rules. Please refer to http://www.getencryption.com which is the EHE upgrade center.

              2, 3. We have siplified the process of rule creation. You can take single action for encryption or decryption.

              4. We are only upgrading those customers who are currently subscribed to Exchange Hosted Encryption. If you are using any other native Voltage product, you can continue using them. With the new Office 365 Message Encryption, we are using existing Microsoft’s RMS keys infrastructure, and it does eliminate dependency with voltage, since EHE used voltage.

      2. If I want to protect a message addressed to both inernal and external recipients, is there a way I can used RMS and Office 365 Message Encryption respectively in the same email message?

        • Yes, You can use both RMS and Office 365 Message Encryption in the same message. For example, if you have 2 recipients, 1 internal and 1 external, you can set up an exchange transport rule to apply Office 365 Message Encryption if the message is sent outside the organization, and apply RMS if the message is sent inside the organization. It is extremely flexible to tweak these rules based on your business scenario.

      3. Sounds interesting, but: if the recipient of such an encrypted mail has no Office 365-ID/Account or Microsoft-ID/Account, let’s say it is a Lotus-Notes User from a "foreign" Organization – how such a recipient would be able to open the encrypted e-mail? For the certificate-exchange there should be any kind of authentication? Or do I miss here something? Please enlighten me…

        • Such an obvious question, right? Unfortunately, there’s no immediately obvious answer. But we can suss some clues. In the section "Receiving and responding to encrypted messages," we read:

          "When an external recipient receives an encrypted message from your company, they see an encrypted attachment and an instruction to view the encrypted message…. You can open the attachment right from your inbox, and the attachment opens in a new browser window. To view the message, you just follow the simple instructions for authenticating via your Office 365 ID or Microsoft Account."

          Switching the writing from third person to second person certainly doesn’t make comprehension easier, for one thing. The important bit is the last sentence. This implies that the _recipient_ must have, at minimum, a Microsoft account, tied to the recipient’s email address.

          This makes sense: the only way Microsoft can authenticate the recipient (and therefore decrypt the message) is if Microsoft knows something about that recipient. Without authenticating the recipient, there is no way to ensure that only the recipient can read the message.

          I sure wish this article included some mention of such a requirement. But, alas, the article appears to omit this minor but necessary detail. Probably because it’s not "seamless."

      4. For E1 plan subscribers, can we add message encryption on a per-user basis or do we have to add it for all licenses in the subscription?

        • Hi Joe, As E1 Plan subscriber , you can add Office 365 Message Encryption per user.

      5. FOPE currently offers a Decrypt option on reply messages, does the Remove option apply to the new tool so that emails are decrypted and reside in Exchange in clear text so O365 users do not have to authenticate to read the message.

        • Hi Colin, that is correct! The Remove Office 365 Message Encryption options works in the same way as does the Decrypt function of EHE. Once encryption is removed, O365 Users should be able to read the message in plaintext without authenticating again.

      6. Great service, thanks you can Galaxkey for this also if you like as its completely independent.

        You can also be assured that all the keys are kept safely away from big vendors and prying eyes.

      7. Can I use smart cards for certificate based authentication with the new service?

        • Hi Gil, Currently we do not support the smart cards for certificate based authentication.

      8. Shobhit: This is great news! Will MS Partners be able to gain access to this feature before it becomes generally available?

        • Hi PFM, Currently we will not be able to provide any trials to partners as that would mean a code change. They will have to wait till early Q1 CY 2014 to get a trial version.

      9. The idea is good .
        I ‘m all for encrypting email.

        Only i don’ t like this version.
        The keys for the certificates sould be with the receiving party and not by one party where it is not clear whether secret services are involved or not. Whether it is Microsoft’s Office 365 or another party does not matter, I want to be able to maintain in control for myself. ( though I do not know if the secret services are happy about that )

        As receiving party I want to controll the public certificate used for e-mail encryption and hold my private key private.

        The solution is simple :
        Use a mechanism that meets DKIM. (RFC5322)
        DKIM already gives the possibility to check the origin of an e-mail.
        This is done with certificates published in DNS .

        The same certificates can also be used to encrypt the email.
        The receiving party of the email owns the private key to decrypt the email.

        Some minor adjustments that may be implemented independed.
        (capture that in a RFC )

        1 )
        The receiving e – mail client should get a minor adjustment so it kan use the private key to read the encrypted e-mail.

        2 )
        Announce in DNS that with the DKIM certificate encrypted e-mail can be received.
        ( from security considerations , this must be a separate procedure that only run’s once )

        3 )
        The sending e-mail client gets the mail recipient’s Public certificate and use it.
        (after check on DNS if the recipient encrypted e-mail can handle)

        Actually it is so simple to realize and Microsoft, Google and other major parties can make use of it for their own e-mail services without having to force others.

        By this open method of secure e-mail offering you don’t need to use a fixed service provided, but you can use an alternative.(if you please)

        Thanks for implementing my solution for secure e – mail .

        Johan Wijnker

      10. hello, could you tell me if the new versión come in spanish? Can I have a demo with my company to view the new caracteristics applied?

        • Hi Jorge,

          Incoming email and html is localized based on the sender setting. The viewing portal is localized based on recipient’s browser settings. The actual body(content) of encrypted message isn’t localized. Demo will be made available in early Q1 CY2014

      11. Does this totally eliminate Voltage? We are goint to have access to the admin console or you are going to recibe the customization from our compay? How is the process?

        • Hi Jorge, we are only upgrading those customers who are currently subscribed to Exchange Hosted Encryption. If you are using any other native Voltage product, you can continue using them. With the new Office 365 Message Encryption, we are using existing Microsoft’s RMS keys infrastructure, and it does eliminate dependency with voltage.

      12. While the inclusion of encryption for non-enterprise level BPOS/Office 365 customers is a welcome feature (esp. the option to brand email templates, which was not available to Enterprise customers a few years back) there is still CRITICAL feature specification documentation missing here in the FAQ. Namely: HOW LARGE of an encrypted email can you send? And what happens if you send an email that EXCEEDS that size? This is NOT a trivial concern. I am someone who worked for a large enterprise with a BPOS EHS implementation a few years back where we ran into this GOTCHA. Mainly, the fact that the message size is CAPPED at 10 MB and the error message tied to it WAS VERY UNHELPFUL (that is, meaningless). The email would be sent, but the recipient could not receive it when they were directed to the EHS portal and had no idea why. In addition, with MIME overhead, the practical limit wasn’t even 10 MB. Given that most email you want encrypted these days will contain attachments of some size, this should be front and center in the documentation, yet it is NOT here on this blog. Especially since MS licensed the Voltage solution for encryption. Voltage, to its credit has a very high limit for its own stand alone product (last I checked it was capped its cloud offerings at 50 MB per email max size). It would be nice if MS documented this better and would not cripple functionality it licenses from third parties. Nothing like pissing off end users with these sorts of roadblocks, and giving security another black eye.

      13. Can you discuss how this encrypted email server might work with HealthVault — can this be used to bypass say having to locally host a gateway provider for sending HealthVault direct messages?

      Comments are closed.