You’re drafting a contract amendment for a client. You hit Alt+H, then S, then E — the Encrypt button lights up. You click Send. Five minutes later, the client replies: “I got it, but it wasn’t encrypted.” You check your Sent Items. The message shows the lock icon. So what happened?
The Problem
Outlook encryption fails silently — no warning, no error dialog, no red banner. It looks like it worked. But the recipient sees plain text. Or worse: they can’t open it at all.
This happens because Outlook doesn’t encrypt messages on its own. It relies on two external systems working in sync: your digital certificate (and whether it’s trusted by the recipient) and Microsoft 365’s transport encryption infrastructure. If either piece is missing or misconfigured, the lock icon lies to you.
It affects finance teams sending sensitive payroll data. Legal departments sharing NDAs. HR managers distributing offer letters. Anyone who assumes clicking Encrypt guarantees end-to-end confidentiality — and discovers too late that it doesn’t.
The root cause isn’t user error. It’s architectural: Outlook uses S/MIME for message-level encryption (where content is encrypted before leaving your device), but only if both sender and recipient have valid, mutually trusted certificates. Meanwhile, Microsoft 365 also applies TLS-based transport encryption automatically — but that only protects the message while it’s moving between servers, not when it’s stored or opened.
The Fix
First, verify which type of encryption you’re using. Outlook offers two distinct paths — and they behave very differently.
How does Outlook encryption work? (S/MIME)
This is true message-level encryption. Your message body, attachments, and headers are encrypted with the recipient’s public key — so only their private key can decrypt it. It requires:
- A valid S/MIME certificate installed in your Windows certificate store (not just Outlook)
- The recipient’s public certificate in your Contacts or Global Address List
- Both certificates issued by a trusted Certificate Authority (CA) — self-signed certs won’t work across organizations
To set it up in Outlook 365 or Outlook 2019/2016:
File > Options > Trust Center > Trust Center Settings > Email Security
Under Encrypted email, click Settings…. Select your signing and encryption certificates. Check Encrypt contents and attachments for outgoing messages only if you want this applied globally — but don’t. That causes more failures than it prevents.
Instead, manually encrypt per message: Compose email → Alt+H → S → E. Look for the lock icon in the ribbon. Hover over it — tooltip should say “Encrypt this message with S/MIME.” If it says “Encrypt for recipients using Office 365 Message Encryption,” that’s a different system entirely.
How does email encryption work in Outlook? (OME)
Office 365 Message Encryption (OME) is Microsoft’s cloud-based alternative. It doesn’t require certificates. Instead, Outlook sends a protected link. Recipients open it in a browser, authenticate (with Microsoft account, Google, or sometimes just a one-time passcode), and view the message in a secure portal.
OME works even if the recipient uses Gmail or Yahoo. But it changes the experience: no native email client support, no offline access, no forwarding unless explicitly allowed.
Enable OME via Microsoft 365 admin center (Exchange Admin Center > Mail flow > Rules), then apply labels or use the Permissions button in compose window (requires sensitivity labeling enabled). In Outlook 365, look for Protect on the Message tab — not the Encrypt button under Options.
If That Doesn't Work
Try these in order — ranked by real-world success rate:
- Check certificate trust chain: Open certmgr.msc → expand Personal > Certificates. Right-click your S/MIME cert → Properties → Details tab → scroll to Enhanced Key Usage. It must list both “Client Authentication” and “Secure Email.” If not, re-import from your CA.
- Test with a colleague inside your org: S/MIME often fails cross-domain due to certificate policy mismatches. Try encrypting to someone in your own domain first — same CA, same PKI setup.
- Disable auto-encryption in Trust Center: If you previously checked “Encrypt contents and attachments for outgoing messages,” uncheck it. Auto-encrypt breaks replies and forwards — Outlook tries to encrypt every reply, even if the original wasn’t S/MIME-enabled.
- Use Outlook on the web (OWA) instead of desktop: OWA handles OME more reliably — especially for shared mailboxes. Desktop Outlook sometimes caches outdated permissions or fails to load Azure Rights Management templates.
Preventing It Next Time
Here’s the counterintuitive tip most admins miss: Don’t rely on the lock icon alone. In Outlook 365, that icon reflects *intent*, not outcome. It only confirms you clicked Encrypt — not that encryption succeeded or was received.
Set up automatic notifications: In File > Options > Mail > Tracking, check Send me a notification when a message I’ve sent is read — but only for messages with sensitivity labels or OME protection. Then build a simple Power Automate flow that triggers on “OME delivery report” and emails you “✅ Encrypted via portal” or “⚠️ Delivered unencrypted.”
For shared mailboxes: S/MIME doesn’t work unless each delegate has their own certificate AND the shared mailbox’s default send-as identity is mapped to that cert. There’s no group certificate. Each person must install and select their own in Trust Center > Email Security > Settings.
Delegate access adds another layer: If you grant “Send As” rights to a delegate, their S/MIME cert controls encryption — not yours. That’s why legal assistants sometimes send unencrypted NDAs even when the partner’s cert is perfect.
Related Settings
These settings interact directly with encryption behavior — and often override it:
| Setting | Location | Effect on Encryption |
|---|---|---|
| Automatic Replies (OOF) | File > Automatic Replies | OOF messages ignore S/MIME and OME settings. They always send in plain text — even if triggered by an encrypted inbound message. |
| Cached Exchange Mode | File > Account Settings > Account Settings… > double-click account > Change > More Settings > Advanced | If disabled, S/MIME encryption may fail silently during send — especially on slow connections — because Outlook can’t validate certificate revocation lists (CRLs) in real time. |
| Junk Email Handling | Home tab > Junk > Junk E-mail Options | OME-protected messages sometimes land in Junk if the recipient’s tenant blocks external OME portals. Whitelisting emea.protection.outlook.com fixes this. |
| Sensitivity Labels | Home tab > Sensitivity > Manage Sensitivity Labels | Labels with “Encrypt email” applied *before* sending enforce OME — even if the user never clicks Encrypt. Overrides manual S/MIME selection. |
| Mailbox Encryption (M365) | Microsoft 365 admin center → Exchange > Mailboxes > [user] > Mailbox features | This encrypts mailbox data at rest — unrelated to message-level encryption. Confusingly named, but completely separate. |
| Default Reply Format | File > Options > Mail > Compose messages > Reply to messages using | If set to Rich Text (.rtf), S/MIME encryption fails on replies. Must be HTML or Plain Text. |
