The Short Version
Outlook uses three distinct encryption layers — and most people assume they’re all active at once. They’re not. Here’s how each one actually behaves:
| Method | What It Protects | Pros | Cons |
|---|---|---|---|
| TLS (Transport Layer Security) | Emails in transit (server-to-server) | Automatic, no setup, enabled by default | Fails silently if recipient server doesn’t support TLS; no protection at rest |
| S/MIME | Message body & attachments — end-to-end | Verifiable sender identity, decrypts only for intended recipients | Requires certificates on both ends; won’t work with Gmail or Outlook.com unless manually configured |
| Microsoft Purview Message Encryption (formerly OME) | Body & attachments — viewable via secure portal | Works with any recipient (Gmail, Yahoo, etc.), no certs needed | Recipient must click a link and sign in or enter a one-time code; not truly end-to-end |
| Exchange Online Protection (EOP) encryption rules | Automated encryption based on content or policy | Admin-configurable, applies to outbound mail without user action | Only available in Microsoft 365 E3/E5 plans; requires Exchange admin rights |
Method 1: TLS — What You Get (and Don’t Get)
This is the baseline. Every time you send from Outlook desktop (2016+), Outlook Web App (OWA), or Outlook for Mac, Microsoft attempts TLS encryption between your Exchange Online or on-premises server and the recipient’s mail server.
It’s silent. You won’t see a lock icon. You won’t get an error if it fails — unless your admin has turned on strict TLS enforcement. In most tenants, Outlook just falls back to plain SMTP and keeps going. I’ve seen this trip up even experienced users who assumed their messages were protected because they saw ‘https’ in the browser bar.
Here’s the catch: TLS only covers the pipe. Once the message hits the destination server, it’s typically stored in plaintext — whether that’s Gmail, Yahoo, or another company’s Exchange server. And if the recipient forwards it? No protection at all.
To check if TLS succeeded for a specific message: open the message in Outlook desktop > File > Properties > scroll down to Internet headers. Look for Received: from … with ESMTPS or with TLS. If you see with ESMTP (no S) or nothing mentioning TLS, it likely fell back.
Note: Outlook for iOS and Android use TLS for outbound delivery, but don’t expose header inspection. You’ll need to rely on your admin’s message trace reports in the Microsoft 365 Defender portal.
Method 2: S/MIME — Real End-to-End (But Only If Everyone Plays Along)
S/MIME gives you actual cryptographic proof of identity and confidentiality. When you digitally sign and encrypt with S/MIME, only the intended recipient — and only with their private key — can read the message.
Setting it up isn’t hard, but it’s fragile. You need a certificate issued by a trusted Certificate Authority (CA), installed in Windows Certificate Manager (for desktop Outlook) or in your device’s profile (for mobile). Your recipient needs the same — plus your public key in their address book.
In Outlook desktop: File > Options > Trust Center > Trust Center Settings > Email Security. Under Encrypted email, click Settings. That opens the S/MIME Settings dialog where you select your signing and encryption certificates.
Then, when composing: Alt+H, then S (for Sign) or E (for Encrypt). Or click the Sign or Encrypt buttons on the Message tab.
Here’s what most people miss: S/MIME doesn’t encrypt the subject line. Ever. So “Confidential — Q3 Budget Review” stays visible in notifications, previews, and search results. Also, if your recipient replies unencrypted, that reply is plaintext — even if your original was locked down.
S/MIME works reliably between two Outlook desktop clients on Exchange Online or on-premises Exchange. It fails silently with Gmail, Outlook.com, and most consumer mail services — unless the recipient manually imports your cert and configures their client (which almost never happens).
Method 3: Microsoft Purview Message Encryption — The Practical Compromise
This is what most organizations actually use for external sharing. Formerly called Office 365 Message Encryption (OME), it wraps your message in a secure HTML page hosted on emea01.content.office.net (or similar regional endpoint). Recipients receive a notification email with a link. They click it, then either sign in with their work/school account or enter a one-time passcode sent to their personal email.
You don’t need certificates. You don’t need the recipient to install anything. And it works with anyone — Gmail, iCloud, ProtonMail, even old-school AOL accounts.
How to trigger it manually:
- In Outlook desktop: Options tab > Permissions > choose Do Not Forward, Encrypt-Only, or Confidential (if your admin published those labels)
- In Outlook Web App: Click the More options (⋯) button > Set permissions > pick a sensitivity label
Behind the scenes, this uses Azure Rights Management (Azure RMS) — now part of Microsoft Purview. The encryption key is tied to your tenant, and decryption happens in the browser using JavaScript crypto. No plaintext ever touches the recipient’s device storage.
But here’s the counterintuitive bit: Even if you use Purview encryption, your internal recipients — people in your own organization — still get the message delivered directly to their mailbox, unencrypted. Why? Because Microsoft assumes your internal network is trusted. So if you send an encrypted message to alice@yourcompany.com and bob@gmail.com, Alice sees it in her inbox like normal. Bob gets the portal link.
This behavior is controlled by the encryption policy your admin configures in the Microsoft Purview compliance portal. There’s a checkbox labeled Apply encryption to internal recipients — but it’s unchecked by default, and rarely enabled.
Also worth noting: Purview encryption doesn’t protect against screenshots, copy/paste, or forwarding *after* the recipient logs in. It only controls initial access.
Which Should You Choose?
Let’s cut through the noise. You don’t pick based on preference — you pick based on who you’re sending to, what you’re sending, and who controls the environment.
If you’re emailing within your company (e.g., team@yourcompany.com): TLS is sufficient for day-to-day. No action needed. But if you’re attaching salary data or HR records, ask your admin to enable automatic encryption via Purview sensitivity labels — and make sure the label is set to apply to internal mail.
If you’re emailing outside your company and need strong confidentiality: Use Purview Message Encryption. It’s the only method that works reliably without pre-coordination. Just remember — the recipient experience is clunkier than native email.
If you’re exchanging highly sensitive data with another organization that also uses Exchange Online or on-premises Exchange *and* has S/MIME deployed: Go with S/MIME. You’ll get better auditability and tighter control — especially if your compliance framework (HIPAA, GDPR, FINRA) requires signed, non-repudiable messages.
Here’s a quick decision table — match your scenario to the right method:
| Your Situation | Best Method | How to Enable (User Level) | Admin-Level Notes |
|---|---|---|---|
| Sending internally — routine updates | TLS (automatic) | No action required | Ensure Enable TLS reporting is on in Exchange Admin Center → Mail flow → Connectors |
| Sending externally — contract PDFs, NDAs | Purview Message Encryption | Compose → Options tab → Permissions → Encrypt-Only | Requires Microsoft 365 E3/E5 or A3/A5; must be enabled in Purview portal under Encryption |
| Sending to known partner with S/MIME certs | S/MIME | Install cert → File > Options > Trust Center > Email Security | Group Policy can deploy certs; admins can enforce S/MIME via Intune or GPO |
| Sending PII to government agency requiring FIPS 140-2 | S/MIME + FIPS-compliant cert | Cert must be issued by a FIPS-validated CA (e.g., DigiCert, Sectigo) | Outlook 2019/365 supports FIPS mode when Windows is configured accordingly (via Local Group Policy → System Cryptography) |
| You’re using Outlook for Mac | Purview only (S/MIME unsupported) | Click ⋯ > Set permissions > choose label | S/MIME is not supported in Outlook for Mac — confirmed in versions up to 16.85 (2024) |
| You’re on Outlook Web App (OWA) and need to encrypt | Purview or S/MIME (if certs installed in browser) | S/MIME requires cert import into Chrome/Edge; Purview works natively | OWA doesn’t read Windows Cert Store — so desktop S/MIME certs won’t auto-load |
One last thing: Are Outlook emails encrypted? Yes — in transit. Is Outlook mail encrypted? Same answer. Is Outlook email encrypted? Still yes… but not the way most people think. Don’t assume security. Verify it. And when in doubt, use Purview Message Encryption — it’s the only method that answers all three questions with a real, working 'yes' for external recipients.
