Outlook offers two genuinely different ways to encrypt email, and they are not interchangeable alternatives that happen to have different setup steps. They provide different security guarantees, and choosing the wrong one for your actual need is the most common mistake people make with Outlook email encryption.
- S/MIME: true end-to-end encryption. Once configured correctly between two parties, not even Microsoft can read the message content. Requires both sender and recipient to have a digital certificate and a qualifying Microsoft 365 subscription, and does not work with consumer Outlook.com, Hotmail.com, or Live.com accounts.
- Microsoft Purview Message Encryption (formerly called Microsoft 365 Message Encryption, also referred to as OME): much easier to set up and use, requires nothing special from the recipient, but is not end-to-end encryption. Microsoft’s own infrastructure retains the ability to access message content for legal compliance and policy enforcement purposes.
Which one you actually need depends on what you are protecting against. The rest of this article explains both clearly, with current setup steps for the modern Outlook interface.
What Email Encryption Actually Does
Encrypting an email converts its readable content into ciphertext, unreadable scrambled data, using a cryptographic key, before the message leaves the sender’s device. Only someone holding the correct corresponding key can convert it back into readable text. If the message is intercepted anywhere along its path, an attacker without the right key sees only the scrambled version.
Two different categories of cryptographic keys are involved, and getting their relative scale right matters for understanding how this actually works:
- Symmetric keys: a single shared key is used for both encrypting and decrypting. This is fast and efficient, and modern symmetric encryption (such as AES) typically uses key lengths of 128 or 256 bits. Symmetric encryption is what actually does the heavy lifting of scrambling the bulk message content in most real-world systems, including S/MIME, once a secure channel is established.
- Asymmetric keys: a mathematically related pair, a public key and a private key, where data encrypted with one can only be decrypted with the other. This is the basis of certificate-based systems like S/MIME: your public key can be shared freely and is what others use to encrypt messages to you, while your private key stays secret and is what you use to decrypt them. Asymmetric keys are intentionally longer than symmetric keys to provide equivalent security, with RSA keys commonly using 2048 bits or larger, or shorter modern elliptic-curve (ECC) keys offering comparable strength.
In practice, S/MIME uses asymmetric encryption (via your certificate) to securely exchange a symmetric key for that specific message, then uses the fast symmetric encryption to actually scramble the message content. This hybrid approach is standard practice across most modern encryption systems, not just email.
S/MIME vs Microsoft Purview Message Encryption: The Real Differences
| S/MIME | Microsoft Purview Message Encryption | |
| True end-to-end encryption? | Yes: Microsoft cannot read the message content | No: Microsoft’s infrastructure can access content for compliance and legal purposes |
| What the recipient needs | A digital certificate already installed, and a compatible email client | Nothing special: verifies identity via Microsoft account, Google or Yahoo login, or a one-time passcode |
| Works with Outlook.com / Hotmail / Live consumer accounts? | No | Recipients on any email service can typically still open the message via a web portal |
| Setup complexity | Higher: requires obtaining and installing a certificate for every user who wants to send or receive encrypted mail | Lower: enabled by the sender’s organization at the licensing and admin level; no certificate needed |
| License requirement | Qualifying Microsoft 365 subscription for S/MIME use | Office 365 Enterprise E3 or equivalent for the sending organization |
| Best suited for | Genuine end-to-end confidentiality requirements, regulated communications where even the platform provider should not have access | Restricting forwarding or printing of sensitive but not maximally confidential messages, sending to external recipients without certificates |
If your actual requirement is that absolutely no third party, including Microsoft, should be able to read the message, S/MIME is the only one of these two options that satisfies that. If your requirement is closer to restricting what a legitimate recipient can do with the message (preventing forwarding, for example) and you need to reach external recipients who do not have a certificate, Microsoft Purview Message Encryption is the more practical and far easier to deploy option, with the tradeoff being that it is not end-to-end encryption in the strict cryptographic sense.
Setting Up and Using S/MIME in Outlook
Before S/MIME works for sending encrypted mail to someone, both you and that recipient need a valid S/MIME certificate installed, and the recipient’s public certificate needs to be available to your Outlook client, typically obtained automatically the first time they send you a digitally signed message.
One-time setup
- Obtain an S/MIME certificate from a Certificate Authority for your email address, and install it according to your CA’s instructions.
- In Outlook, go to Settings, then Mail, then S/MIME.
- To sign all outgoing messages automatically, select Add a digital signature to all messages I send.
- To encrypt all outgoing messages automatically (only works for recipients whose public certificate you already have), select Encrypt contents and attachments for all messages I send.
- Optionally select Automatically choose the best certificate to let Outlook select the appropriate certificate per message rather than prompting you each time.
Per-message encryption without changing the default
If you have not enabled encryption for all outgoing mail, you can still encrypt a specific message individually: compose the message, select Options, select Encrypt, then select Encrypt with S/MIME.
S/MIME does not work with Outlook.com, Hotmail.com, or Live.com consumer accounts. It is intended for Microsoft 365 business or school accounts, and can also be used with Gmail accounts added to Outlook. If you are using a personal consumer Microsoft email account, S/MIME is not available to you regardless of certificate setup, and Microsoft Purview Message Encryption or a separate end-to-end encrypted email service is the relevant alternative.
Setting Up and Using Microsoft Purview Message Encryption
This option requires your organization’s Microsoft 365 subscription to include the relevant licensing (Office 365 Enterprise E3 or equivalent), configured by an administrator. Once enabled at the organization level, individual users can apply it directly from Outlook with no certificate setup of their own.
- Compose your message as usual.
- Select Options.
- Select Encrypt.
- Choose Encrypt-Only to apply encryption without additional restrictions, or Do Not Forward to additionally prevent the recipient from forwarding, printing, or copying the message content.
- Send the message normally.
Recipients, regardless of which email service they use, can open the message by verifying their identity, typically through an existing Microsoft account, a Google or Yahoo account, or a one-time passcode sent to their email address. No certificate installation or special software is required on their end, which is the primary practical advantage of this option over S/MIME when emailing people outside your own organization.
Microsoft Purview Message Encryption and S/MIME should not be combined on the same message. A message already encrypted or signed with S/MIME should not also have Purview’s IRM protection applied, and vice versa; apply one or the other, not both, to a given message.
Why Email Encryption Matters in the First Place
Email frequently carries genuinely sensitive content: financial details, health information, legal documents, and confidential business communications. Regulatory frameworks including HIPAA (healthcare data in the United States), FERPA (educational records), and GDPR (personal data in the EU and for organizations handling EU residents’ data) all establish data protection expectations that are relevant context for why organizations handling this kind of information often need encrypted email as part of their broader compliance posture. This article explains how Outlook’s encryption tools work technically; it is not a substitute for actual legal or compliance guidance specific to your organization’s regulatory obligations, which is worth obtaining from a qualified compliance professional if you are making decisions based on a specific regulatory requirement.
Frequently Asked Questions
I don’t see an Encrypt option in Outlook at all. Why?
The most common cause is licensing: Microsoft Purview Message Encryption requires your organization’s Microsoft 365 subscription to include the relevant license tier (commonly Office 365 Enterprise E3 or higher), configured by an administrator. If your organization’s subscription does not include this, or if Microsoft has changed licensing requirements since your plan was set up, the Encrypt option may not appear at all. Check with your IT administrator about your organization’s current licensing, or consider S/MIME as an alternative if you have a qualifying subscription and can install a certificate.
Can I send an encrypted email to someone using Gmail or another non-Microsoft email service?
With Microsoft Purview Message Encryption, yes: recipients on any email service can open the encrypted message, typically through a secure web portal where they verify their identity. With S/MIME, the recipient needs a compatible email client and a valid certificate of their own; Gmail accounts can be added to and used with Outlook for S/MIME, but a recipient using Gmail’s own native web interface without a certificate set up would not be able to participate in S/MIME encrypted exchange the same way.
Is S/MIME actually worth the setup complexity compared to Purview?
It depends entirely on whether end-to-end encryption is a genuine requirement for your specific use case. If you need assurance that not even Microsoft’s own infrastructure can access the message content, for legal, competitive, or particularly sensitive personal reasons, S/MIME is the only one of Outlook’s two built-in options that provides that. If your concern is more about controlling what a legitimate recipient can do with a message, or you need to reach external recipients without certificates easily, the lower setup overhead of Purview Message Encryption is likely the more practical choice despite not being end-to-end encrypted in the strict sense.
