Documentation7 min read

Encrypted Email: When You Need It, How It Works, and How to Deploy It

Not every email needs encryption — but some absolutely do. This guide covers the difference between transport encryption and end-to-end encryption, when each applies, and how to deploy Microsoft Purview Message Encryption for M365 organizations.

Published August 15, 2026Updated August 25, 2026
Encrypted EmailMicrosoft PurviewOMETLSHIPAAData Loss PreventionEmail Security

Two very different things called "email encryption"

When people say "encrypt our email," they usually mean one of two completely different things — and confusing them leads to either false confidence or unnecessary complexity. The distinction matters for compliance, usability, and cost.

  • Transport encryption (TLS): Encrypts the connection between mail servers. The email is encrypted in transit but decrypted at each server hop. This is the default for all modern email platforms including M365 and Gmail. It protects against network interception but not against server-side access.
  • End-to-end / message-level encryption: Encrypts the message content itself so only the intended recipient can read it — not even the mail servers in between. This is what compliance frameworks like HIPAA require for ePHI sent outside your organization.
TLS vs. MESSAGE-LEVEL ENCRYPTION TLS (Transport) Sender 🔒 TLS Sending mail server (decrypts) 🔒 TLS Receiving mail server (decrypts) 🔒 TLS Recipient Server admin can read ⚠ Message Encryption (OME / S/MIME) Sender 🔒 E2E Sending mail server (opaque) 🔒 E2E Receiving mail server (opaque) 🔒 E2E Recipient only Server admin sees ciphertext ✓ Figure 1 — TLS encrypts the connection; message encryption encrypts the content. Only message-level encryption satisfies HIPAA and financial data requirements.

Figure 1 — TLS vs. message-level encryption. TLS protects data in transit between servers but each server can read the content. Message encryption keeps the content opaque to everyone except the intended recipient.

When is encrypted email required?

ScenarioRequirementSolution
Sending ePHI outside your organization (healthcare)HIPAA Technical Safeguard — transmission securityMicrosoft Purview Message Encryption (OME)
Sending cardholder data via emailPCI DSS Requirement 4.2.1 — strong cryptographyOME or S/MIME; better to avoid email for PAN entirely
Attorney-client privileged communicationsProfessional obligation; not a regulatory mandateOME or S/MIME depending on recipient capability
Financial data, SSNs, tax documentsState privacy laws (CCPA, SHIELD Act, etc.)OME with DLP auto-encryption policy
Internal email between M365 usersGenerally not required — TLS + M365 server-side encryption covers thisNo additional action needed

Microsoft Purview Message Encryption (OME)

OME is Microsoft's built-in message encryption solution for M365. It replaced the older Azure Rights Management-based OME and is included with M365 Business Premium, E3, and E5. It requires no software installation on the recipient's end — recipients receive a link to a secure portal where they authenticate and read the message.

How OME works

  1. Sender applies an encryption label (manually or via DLP policy trigger).
  2. M365 encrypts the message and sends the recipient a notification with a secure link.
  3. Recipient authenticates via Microsoft account, Google account, or one-time passcode.
  4. Recipient reads and replies in the encrypted portal — replies are also encrypted.

Automatic encryption with DLP policies

The most effective deployment is automatic — users should not have to remember to encrypt. A DLP policy can detect sensitive content patterns and apply encryption automatically:

  • Emails containing Social Security Numbers → encrypt automatically
  • Emails containing ePHI keywords → encrypt and apply HIPAA label
  • Emails containing credit card numbers → encrypt or block
OME requires Azure Information Protection (AIP) to be activated on your tenant. This is included with M365 Business Premium but must be explicitly enabled. IDENETY activates and configures OME as part of the M365 Security Baseline deployment — including DLP policies for HIPAA, PCI, and PII auto-encryption.

S/MIME — the alternative for high-security environments

S/MIME (Secure/Multipurpose Internet Mail Extensions) provides true end-to-end encryption using digital certificates. Unlike OME, S/MIME encrypts the message at the client level — Microsoft's servers never see the plaintext. It is preferred in legal, government, and high-security financial environments.

The tradeoff: S/MIME requires both sender and recipient to have certificates installed and exchanged in advance. It is not practical for ad-hoc external communication. For most SMBs, OME provides the right balance of security and usability.

What encrypted email does not protect against

Encryption protects data in transit and at rest. It does not protect against:

  • A recipient who forwards the decrypted message to an unauthorized party.
  • A compromised recipient mailbox — if the attacker has the recipient's credentials, they can read encrypted messages too.
  • Screenshots or physical observation of the screen.

For the highest-sensitivity communications, combine encryption with Rights Management restrictions (prevent forwarding, set expiry) using OME Advanced Message Encryption, included with M365 E3/E5 and Business Premium.

See our HIPAA Technical Safeguards checklist for the full compliance context, and our Spam Filter vs. Email Security Gateway article for the broader email security stack.

Contact our engineers to configure Microsoft Purview Message Encryption and DLP auto-encryption policies for your organization.

About the Author