You’re drafting a message to Legal about the M&A due diligence findings. You click Encrypt in the ribbon, hit Send — and breathe easy. Five minutes later, you realize the recipient uses Gmail on mobile. Did that email ever get encrypted? Or did Outlook just slap a label on it while sending plain text?
The Short Version
Outlook offers four distinct encryption behaviors — not one. They behave differently depending on who you're emailing, what client they use, and whether you're on Windows, Mac, or web. Below is what actually happens when you click "Encrypt" — not what Outlook claims.
| Method | Pros | Cons | Works With Gmail? |
|---|---|---|---|
| "Encrypt" button (S/MIME) | End-to-end, signed & verified if both sides have certs | Fails silently with non-Outlook clients; no warning | ❌ No — breaks in Gmail Web & iOS Mail |
| "Encrypt-Only" (Microsoft Purview) | Enforces encryption even for external recipients; works cross-platform | Requires E3/E5 license; no offline access to content | ✅ Yes — opens in browser with login |
| "Do Not Forward" (IRM) | Blocks copy/paste/print; visible in Outlook & OWA | No encryption — just permissions; bypassed by screenshots | ⚠️ Partial — works in OWA but not native Gmail app |
| Manual S/MIME setup (certs) | True PKI encryption; verifiable signature + decryption | Requires certificate install on sender AND recipient; zero Mac support in Outlook 16.83+ | ❌ No — needs matching cert in recipient's Outlook profile |
Method 1: The "Encrypt" Button (S/MIME Default)
This is the big red lie. Clicking Message → Encrypt in Outlook desktop (Windows) triggers S/MIME — if you’ve configured certificates and the recipient has theirs installed and trusted.
But here’s what most people miss: Outlook won’t tell you it failed. If Sarah Chen (VP Marketing) replies from her iPhone using Apple Mail — which doesn’t store or use S/MIME certs — your encrypted email arrives as plain text. Outlook displays "Encrypted" in the subject bar anyway.
On Windows: Go to File > Options > Trust Center > Trust Center Settings > Email Security. That’s where S/MIME defaults live. Check "Encrypt contents and attachments for outgoing messages" — but this only applies if Outlook can locate a valid cert for the recipient.
On Mac: This option doesn’t exist in Outlook for Mac v16.83+ (released March 2024). Microsoft removed S/MIME encryption entirely from the UI. It’s gone — not hidden, not deprecated. Deleted.
Counterintuitive tip: Even if you see the lock icon in the message header, right-click it and choose "View Security Properties". If it says "No digital signature found" or "Encryption certificate not available", your email was sent unencrypted — regardless of the ribbon button you clicked.
Method 2: "Encrypt-Only" (Microsoft Purview Message Encryption)
This is the only method that reliably works across domains. When you select Encrypt-Only (not just "Encrypt") in the Permissions dropdown, Outlook routes the message through Microsoft Purview.
The recipient gets a notification email with a link. They open it in any browser, sign in with their Microsoft, Google, or Apple account (depending on your tenant config), and read the message. Attachments download separately — also protected.
To enable it: Your admin must assign an E3 or E5 license and configure templates in Microsoft Purview Compliance Portal. As an end user, you’ll see it under Message > Permissions > Encrypt-Only.
Works in Outlook desktop (Win/mac), Outlook Web App, and even Outlook mobile. But — and this trips up everyone — if you reply to an encrypted thread using the "Reply" button inside the protected portal, your reply stays encrypted. If you copy-paste the text into a new message? Back to plain text.
Keyboard shortcut: Alt+H, then P, then E opens Permissions — faster than hunting the ribbon.
Method 3: "Do Not Forward" (IRM)
This isn’t encryption. It’s Information Rights Management — a permissions wrapper. Selecting Do Not Forward prevents copying, pasting, printing, or forwarding. But the raw message body travels unencrypted over the wire.
It works only when both sender and recipient are in the same Microsoft 365 tenant — or when the recipient opens the message in Outlook Web App or desktop Outlook. Try opening it in Gmail’s web interface? You’ll get a blank page or an error.
Path: Message > Permissions > Do Not Forward. No license required — it’s included in all Business Standard+ plans.
Real-world example: IT Help Desk sends a password reset link with "Do Not Forward" applied. A user forwards it anyway via screenshot. IRM can’t stop that. Neither can encryption — but at least encryption would make the original message unreadable without the key.
Which Should You Choose?
Forget "what’s best." Ask instead: Who’s reading it? Where are they reading it? What’s the risk if it leaks?
| Your Situation | Best Method | Why | Setup Time |
|---|---|---|---|
| Emailing internal team only (same M365 tenant) | Do Not Forward | Fast, built-in, blocks casual forwarding | 15 seconds |
| Sending sensitive data to external law firm using Outlook | Encrypt-Only | Guarantees protection regardless of their client | Admin setup required; user action = 5 sec |
| You control both ends (e.g., internal audit team with certs deployed) | Manual S/MIME | Only method with true cryptographic proof and non-repudiation | Hours (cert install + testing per user) |
| You clicked "Encrypt" and now wonder if it worked | Don’t trust the UI — check headers | Open message > File > Properties > scroll to Internet headers. Look for "Content-Type: application/pkcs7-mime" | 90 seconds |
| Using Outlook for Mac (v16.83+) | Encrypt-Only only | S/MIME is fully removed. No workaround exists. | N/A — it’s your only option |
