Email Encryption for Business: TLS, S/MIME, and Microsoft Purview Explained

Back to Blog

Email was designed in the 1970s for a network of trusted academic institutions. Security was not a design consideration — the protocol assumed that everyone on the network was authorized to be there. That design decision persists today. The SMTP protocol that carries your business email has no built-in encryption, no built-in authentication, and no built-in mechanism to prevent interception. Without additional security layers, email sent between organizations traverses the public internet in plaintext — readable by any party with access to the routing infrastructure between sender and recipient.

For most routine business communication this is an acceptable risk that is mitigated by opportunistic TLS (which most major email providers now implement by default). But for communication containing protected health information, attorney-client privileged material, financial account data, or any other sensitive content with legal protection requirements, opportunistic TLS is not sufficient. This guide explains the three layers of email encryption available to business users, how each works, what it protects against, and when it is legally required.

Why Email Is Inherently Insecure

When your Outlook client sends a message, it submits it to your mail server (or Exchange Online) over an SMTP connection. Your mail server then delivers it to the recipient's mail server — also over SMTP. That server-to-server SMTP connection is where the vulnerability lies. Without TLS enforced on that connection, the message travels as cleartext across the internet. Any router, switch, or network device in the path can read its contents.

Beyond transit interception, email is also stored on servers at rest. Messages sitting in an Exchange Online mailbox are encrypted at rest by Microsoft using BitLocker and service-level encryption — but that encryption protects against physical hardware theft, not against a legitimate service provider (Microsoft or your email administrator) reading the content. For true confidentiality, the message must be encrypted in a way that only the intended recipient can decrypt — which requires end-to-end encryption, not just transport-layer protection.

Understanding this distinction is central to choosing the right encryption mechanism for your requirements:

• Transport encryption (TLS): Protects the connection between mail servers. The message is decrypted at each server hop and re-encrypted for the next. Mail providers can read the content.
• End-to-end encryption (S/MIME): Message is encrypted by the sender's device and can only be decrypted by the recipient's device. No intermediary — including your mail provider — can read the content.
• Policy-based encryption (Microsoft Purview): Message is encrypted and access-controlled by policy, with a centrally managed key. Recipients can access through a secure portal even without installing anything.

Transport Encryption: TLS in Practice

Transport Layer Security (TLS) encrypts the SMTP connection between mail servers — the equivalent of putting your letter in a sealed envelope for the journey between post offices, but where each post office can open and read the envelope. TLS is now deployed by default on virtually all major email platforms, making opportunistic TLS the baseline for most business email sent between major providers.

Opportunistic TLS vs. enforced TLS: Opportunistic TLS means your server will use encryption if the recipient's server supports it, but if the recipient's server does not advertise TLS support, the message is delivered in plaintext rather than bouncing. This is the default behavior for most mail servers. Enforced TLS means your server will refuse to deliver to a recipient server that does not support TLS, bouncing the message rather than transmitting it unencrypted. For regulated communications with specific partners (healthcare referral partners, financial institutions), you can configure enforced TLS connector rules in Exchange Online that require TLS for specific domains.

DANE and MTA-STS for TLS enforcement at scale: Enforced TLS via connector rules requires manual configuration per partner domain, which does not scale. Two DNS-based standards allow domain owners to publish TLS requirements publicly:

• MTA-STS (Mail Transfer Agent Strict Transport Security): A DNS TXT record and HTTPS-hosted policy file that tells sending mail servers "you must use TLS version 1.2 or higher and verify my certificate before delivering to this domain." When a sender fetches your MTA-STS policy and then attempts delivery, it will refuse to deliver if TLS negotiation fails. MTA-STS is supported by Exchange Online and is the recommended mechanism for publishing enforced TLS requirements.
• DANE (DNS-Based Authentication of Named Entities): Uses DNSSEC-signed TLSA records to publish the expected TLS certificate for your mail server, allowing senders to verify they are connecting to the legitimate server rather than an impostor. DANE requires DNSSEC on your domain, which many business domain registrars still do not support, making DANE less universally applicable than MTA-STS for typical business use.

S/MIME: True End-to-End Email Encryption

Secure/Multipurpose Internet Mail Extensions (S/MIME) is the standard for end-to-end encrypted email. It uses public-key cryptography: each user has a certificate containing a public key (shared publicly) and a private key (stored only on their device). To send an encrypted email, you encrypt the message with the recipient's public key. Only the recipient's private key — which only they possess — can decrypt it.

S/MIME also enables digital signatures — a cryptographic proof attached to outbound messages that proves the message genuinely came from you and was not modified in transit. Recipients with email clients that support S/MIME (Outlook, Apple Mail, most enterprise clients) see a visual indicator confirming the message is signed and from a verified sender.

How to get an S/MIME certificate: S/MIME certificates are issued by Certificate Authorities (CAs). For business use, obtain certificates from a trusted commercial CA — DigiCert, Sectigo, GlobalSign, and Entrust are common business certificate providers. Individual user certificates (Class 1 or Class 2 S/MIME) typically cost $20–$50 per user annually. Enterprise CAs also allow issuance of S/MIME certificates from an internal PKI (Public Key Infrastructure) using Microsoft Certificate Services, which is how most large organizations provision S/MIME at scale.

Installing and using S/MIME in Outlook: In Outlook for Windows, S/MIME certificates are installed in the Windows Certificate Store and then configured in Outlook under File → Options → Trust Center → Email Security. Once configured, Outlook adds Sign and Encrypt buttons to the message composition ribbon. For Exchange Online, Microsoft 365 supports S/MIME via a published certificate policy — administrators can push S/MIME certificates to managed devices through Intune, and Exchange Online will automatically use published public keys for encryption when sending to recipients whose public certificates are in the Global Address List or LDAP directory.

The S/MIME limitation: Both sender and recipient must have S/MIME configured. If your client emails you and they do not have an S/MIME certificate, you cannot encrypt messages to them using S/MIME. This makes S/MIME most practical for closed ecosystems — internal communications, established business-to-business relationships with partners who have also implemented S/MIME, or regulated industry communications where all parties are required to support it.

Microsoft Purview Message Encryption: Practical Encryption for External Recipients

Microsoft Purview Message Encryption (formerly Office 365 Message Encryption, or OME) solves the interoperability problem that makes S/MIME impractical for ad-hoc external communications. Purview encryption does not require the recipient to have any software installed, any certificate configured, or any Microsoft account. It works for any email recipient, anywhere.

How it works for Office 365 recipients: When a message protected with Purview encryption is sent to another Microsoft 365 user, the encrypted message is delivered directly into their mailbox and Outlook decrypts it transparently using Microsoft's key management service. The recipient sees no difference from a normal email — the experience is seamless.

How it works for external recipients (Gmail, Yahoo, corporate non-M365 systems): The recipient receives an email notification informing them that an encrypted message is waiting. They click a link to the Microsoft Purview portal, authenticate (using their Google account, a one-time passcode sent to their email, or a Microsoft account), and read the message in the secure browser-based portal. They can reply securely from the same portal, and the reply is delivered encrypted back to the sender in Exchange Online.

Policy-based automatic encryption: Purview's real power for compliance scenarios is automatic policy-based encryption using Data Loss Prevention (DLP) policies or sensitivity labels. You define rules: "Any email containing Social Security numbers must be encrypted and protected." Exchange Online's mail flow rules scan outbound messages against these criteria and apply encryption automatically — users do not need to remember to click an encryption button. This is how HIPAA-compliant healthcare organizations use Purview to ensure that PHI transmitted by email is always encrypted, even when staff forget to manually apply protection.

Licensing requirement: Microsoft Purview Message Encryption is included in Microsoft 365 Business Premium and Microsoft 365 E3/E5. It is not included in Business Basic or Business Standard — those plans require an Azure Information Protection Plan 1 add-on to access Purview encryption capabilities.

When Email Encryption Is Legally Required

Regulation	Industry / Data Type	Encryption Requirement
HIPAA Security Rule	Healthcare / PHI	Encryption of PHI in transit is an "addressable" safeguard — required unless documented alternative is equivalent. In practice, any covered entity transmitting PHI over email must encrypt or document why they are not.
PCI DSS	Payment card data	Cardholder data must be encrypted in transit using strong cryptography. Email containing PANs (primary account numbers) must be encrypted or the use of unencrypted email must be eliminated.
California CCPA / CPRA	California consumer data	Reasonable security measures required. Unencrypted email containing personal information exposed in a breach triggers mandatory breach notification obligations.
Attorney-Client Privilege	Legal communications	No statutory mandate, but bar associations in multiple states have opined that attorneys have an ethical duty to use reasonable care to protect client confidentiality, which may require encryption for sensitive matters.
GLBA Safeguards Rule	Financial institutions / NPI	Non-public personal financial information must be protected with encryption in transit. The FTC's updated Safeguards Rule (effective 2023) explicitly requires encryption of customer financial data.

Choosing the Right Encryption for Your Business

Most businesses need a layered approach rather than a single solution:

• MTA-STS: Implement this for all outbound email. It costs nothing and ensures all mail transit uses modern TLS. Configure it in your DNS with Microsoft's guidance for Exchange Online domains.
• Microsoft Purview Message Encryption: The right choice for any organization on M365 Business Premium that needs to send encrypted email externally — especially healthcare, legal, and financial services. Automatic DLP-based policies remove the human-error component.
• S/MIME: Add this for internal communications and for established external relationships where both parties have implemented it. Provides the strongest confidentiality guarantee (true end-to-end, not provider-accessible) and adds digital signatures that recipients can verify.

How IT Center Manages Email Encryption

IT Center implements and manages email encryption for Southern California businesses through our email security services and compliance services. For healthcare clients, we configure Microsoft Purview DLP policies aligned to HIPAA's minimum necessary standard — ensuring PHI is automatically encrypted without relying on staff awareness. For law firms and financial services clients, we implement S/MIME certificate provisioning via Intune, configure enforced TLS connectors for known partners, and deploy MTA-STS. Our compliance team documents the encryption controls as part of your HIPAA Security Risk Assessment or FTC Safeguards Rule compliance program.