# Email encryption types for business: which do you need?

URL: https://iblockspam.com/blog/email-encryption-types-for-business
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Email security basics
Author: iBlockSpam Team

> TLS, S/MIME and PGP, Microsoft Purview Message Encryption, Gmail client-side encryption and encryption at rest: what each one protects and when to use it.

## Short answer

Business email uses four kinds of encryption. TLS protects each server-to-server hop. Encryption at rest protects stored mailboxes. Provider message encryption, such as Microsoft Purview Message Encryption, protects a message to any recipient through a portal. End-to-end encryption (S/MIME or OpenPGP) hides content from everyone but the recipient. Every business needs the first two.

"Is our email encrypted?" sounds like a yes-or-no question, but the honest answer is usually "some of it, against some threats." Business email uses several kinds of encryption at different points, and each one protects against something different. This guide sorts them out so you can match each to a real need.

## What are the main types of email encryption?

There are four layers. They aren't alternatives; most businesses use two or three together.

| Type | Examples | What it protects | Who can still read the message |
|---|---|---|---|
| **In transit (TLS)** | STARTTLS between servers; TLS on ports 587 and 465 for sending | The connection, one hop at a time | Every mail server that handles it, and both mailbox providers |
| **At rest** | BitLocker and service encryption in Microsoft 365; Google's default storage encryption | Stored data on the provider's disks | Anyone who can sign in to the mailbox, and the provider's services |
| **Provider message encryption** | Microsoft Purview Message Encryption | The message itself, to any recipient, through Outlook or a web portal | Sender, recipient, and the provider's service that manages the keys |
| **End-to-end** | S/MIME, OpenPGP, Google Workspace client-side encryption | The message content from sender to recipient | Only people holding the right private key (or, with client-side encryption, the key service you control) |

The rest of this guide takes each layer in turn, then answers the practical question: which do you need, and when?

## What does TLS encryption in transit protect?

TLS encrypts the connection between two systems while a message moves. It's what stops someone on the network path from reading mail as it passes.

Microsoft describes it as encryption "in the service": "Microsoft 365 uses Transport Layer Security (TLS) to encrypt the connection, or session, between two servers," with nothing for you to configure. [Encryption in the Microsoft cloud](https://learn.microsoft.com/en-us/purview/office-365-encryption-in-the-microsoft-cloud-overview) adds that customer-facing servers negotiate TLS 1.2 by default.

TLS has hard limits:

- **It's hop by hop.** Each server decrypts the message, handles it, and re-encrypts it for the next hop.
- **It's often optional between servers.** If the receiving server doesn't offer TLS, many senders deliver in plain text. [STARTTLS and email encryption in transit](https://iblockspam.com/blog/starttls-email-encryption-in-transit) explains this "opportunistic" behavior and the downgrade attacks it allows, and [MTA-STS and TLS-RPT](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) shows how a domain makes TLS mandatory for inbound mail.
- **It isn't end-to-end.** [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314.html), which requires TLS for mail submission and access, says its recommendations "are not intended as a substitute for, end-to-end encryption of electronic mail."

Treat TLS as the baseline every business should have, not as protection for sensitive content.

## What does encryption at rest protect?

Encryption at rest protects mail stored on the provider's disks. If a drive is lost, stolen or decommissioned without being wiped, the data on it is unreadable.

- **Microsoft 365.** Microsoft says "email data at rest is encrypted using BitLocker Drive Encryption," and service encryption adds another layer. An option called Customer Key lets you supply your own keys stored in Azure Key Vault.
- **Google Workspace.** Google describes client-side encryption as adding "another layer of encryption" on top of the default encryption Workspace already applies.

The limit is just as important. Encryption at rest does nothing against someone who signs in to the mailbox. A stolen password, a malicious inbox rule or a phished session all see mail in plain text. Account security (multifactor sign-in, conditional access, alerting on unusual sign-ins) is the control for that risk. [Signs your email account is compromised](https://iblockspam.com/blog/signs-email-account-compromised) covers what to watch for.

## How does provider message encryption work?

Provider message encryption encrypts an individual message, usually based on a rule or a button in the mail client, and handles the keys for you. In Microsoft 365, this is **Microsoft Purview Message Encryption**.

According to [Microsoft Learn](https://learn.microsoft.com/en-us/purview/ome), it's "built on the Azure Rights Management service" and works "with Outlook.com, Yahoo!, Gmail, and other email services." Recipients in Microsoft 365 using Outlook read the message normally. Recipients elsewhere get a wrapper message that sends them to an encrypted message portal, where they sign in or use a one-time passcode. Microsoft's [comparison page](https://learn.microsoft.com/en-us/purview/email-encryption) adds that recipients "don't need a Microsoft 365 subscription to view encrypted messages or send encrypted replies," and that "Microsoft securely manages and stores the keys, so you don't have to."

Admins can apply it automatically with mail flow rules, for example to every external message containing certain keywords. Our guide to [Microsoft 365 mail flow rules for security](https://iblockspam.com/blog/microsoft-365-mail-flow-rules-for-security) covers rule design.

Two things to know before you rely on it:

- **It doesn't restrict what recipients do.** Microsoft says message encryption on its own "doesn't let you apply usage restrictions"; options such as Do Not Forward come from Information Rights Management (IRM), which uses the same Rights Management service.
- **Availability depends on your plan.** Which encryption features you get, and whether advanced options such as message expiry and revocation are included, depends on your Microsoft 365 subscription. Check the Exchange Online and Microsoft Purview service descriptions for your plan before promising it to customers.

Microsoft recommends this approach "when you want to send sensitive business information to people outside your organization," with examples such as a bank sending statements or a doctor's office sending records to a patient.

## What is end-to-end email encryption?

End-to-end encryption encrypts the message on the sender's side so that only the intended recipient can decrypt it. Servers in between, including your own provider's, see only ciphertext. There are three options a business is likely to meet.

### S/MIME

S/MIME ([RFC 8551](https://www.rfc-editor.org/rfc/rfc8551.html)) uses X.509 certificates, the same kind of certificate infrastructure as websites. It both encrypts and digitally signs messages. It's built into Outlook and many other business mail clients. [NIST SP 800-177 Rev. 1](https://csrc.nist.gov/pubs/sp/800/177/r1/final), NIST's guidance on trustworthy email, recommends S/MIME for encrypting and authenticating message content.

The catch is key management. Microsoft notes that "to use S/MIME, you must have public keys on file for each recipient," and recipients must keep their own private keys secure. Microsoft recommends S/MIME "when either your organization or the recipient's organization requires true peer-to-peer encryption," such as government-to-government mail.

### OpenPGP

OpenPGP ([RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html)) uses key pairs that users generate and exchange themselves. It's common in technical and security communities but rare in everyday business use. If you use Microsoft 365, note Microsoft's statement that it "does not support PGP/MIME and you can only use PGP/Inline."

### Google Workspace client-side encryption

Google Workspace client-side encryption (CSE) encrypts content in the browser or app before it reaches Google, using keys held in an external key service that your organization controls. Google describes it as "end-to-end encryption that Google servers and third parties can't decrypt," and its setup guide covers Gmail, Drive, Calendar and Meet. For Gmail, Google says "external users just need to use S/MIME" to read your users' encrypted messages.

[Google lists](https://knowledge.workspace.google.com/admin/security/about-client-side-encryption) the supported editions as Frontline Plus, Enterprise Plus, Education Standard and Education Plus. It also requires an external key management service, which is a project in its own right.

### The trade-off: encrypted mail can't be filtered

End-to-end encryption hides content from everyone in the middle, including security tools. Microsoft says plainly that "S/MIME doesn't allow encrypted messages to be scanned for malware, spam, or policies." Google's [CSE FAQ](https://knowledge.workspace.google.com/admin/security/client-side-encryption-faq) says encrypted email isn't scanned for threats "because Google's servers don't have access to the content," and that DLP scans can't read it either.

That includes inbound filters such as a gateway in front of your mailbox. An encrypted attachment from an unknown sender should be treated with extra suspicion, not trusted because it's encrypted. [Dangerous email attachment types](https://iblockspam.com/blog/dangerous-email-attachment-types) explains why attackers like password-protected and encrypted files.

## Which type of email encryption do you need?

Use this as a starting point, then confirm against any contract or regulation that applies to you.

1. **Every business: TLS and encryption at rest.** Make sure your provider uses TLS between servers and requires TLS 1.2 or later for apps and devices that send mail (see [SMTP ports 25, 587 and 465](https://iblockspam.com/blog/smtp-ports-25-587-465)). Confirm stored mail is encrypted. On Microsoft 365 and Google Workspace, both are on by default.
2. **Domains that receive sensitive mail: enforce TLS inbound.** Publish MTA-STS so senders that support it must use TLS to reach you. Check your current policy with the [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker).
3. **Sending sensitive data to customers, patients or clients: provider message encryption.** Recipients can read it without certificates or special software. Set a mail flow rule so staff don't have to remember.
4. **Partners who require it, or regulated exchanges between organizations: S/MIME.** Exchange certificates in advance and test with each partner.
5. **Data your own provider must not be able to read: client-side encryption or OpenPGP.** Budget for key management, accept that the content can't be scanned, and limit it to the users who need it.

| Scenario | Minimum | Better |
|---|---|---|
| Everyday internal and external mail | TLS + at rest | Add MTA-STS for inbound |
| Invoices and contracts to clients | TLS + at rest | Provider message encryption by rule |
| Patient or financial records to individuals | Provider message encryption | Plus expiry and revocation, where your plan includes them |
| Regular exchange with a government agency or partner that requires it | S/MIME | S/MIME with signing on all mail to that partner |
| Trade secrets your provider must not access | Client-side encryption or OpenPGP | With strict key access lists and a recovery plan |

Medical and dental practices can see what HIPAA says about email on our [healthcare page](https://iblockspam.com/solutions/healthcare).

## What encryption doesn't do

Encryption keeps content private. It doesn't prove who sent a message or stop phishing. A phishing email can arrive over perfect TLS, and an attacker can send encrypted mail too. Sender identity comes from SPF, DKIM and DMARC (see [SPF vs DKIM vs DMARC](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc)), and malicious content is caught by filtering before delivery.

## Next steps

- Open a recent external message in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) and check whether each hop used TLS.
- Check whether your domain publishes MTA-STS with the [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker).
- Write down which kinds of data must never go out unencrypted, and set a provider encryption rule to match.
- Review the rest of your setup with the [email security checklist for small businesses](https://iblockspam.com/blog/email-security-checklist-small-business). iBlockSpam filters inbound mail at the MX level before it reaches your mailboxes; it complements encryption rather than replacing it.

## Frequently asked questions

### Is Microsoft 365 email encrypted by default?

Partly. Microsoft says Microsoft 365 uses TLS to encrypt connections between servers by default and encrypts stored mailbox data at rest with technologies such as BitLocker and service encryption. The message content itself isn't encrypted end to end unless you or your users apply Microsoft Purview Message Encryption, S/MIME or IRM.

### Is Gmail end-to-end encrypted?

Not by default. Gmail uses TLS when the other server supports it and encrypts stored data. For content that Google's servers can't decrypt, Google Workspace offers client-side encryption, which Google lists for Frontline Plus, Enterprise Plus, Education Standard and Education Plus editions and which needs an external key service you control.

### What is the difference between S/MIME and Microsoft Purview Message Encryption?

S/MIME encrypts with each recipient's own certificate, so both sides need certificates and a compatible client. Purview Message Encryption uses keys Microsoft manages and lets any recipient read the message through Outlook or a web portal, for example with a one-time passcode. Microsoft recommends S/MIME when true peer-to-peer encryption is required, and message encryption for sending to outside people generally.

### Does encrypted email get scanned for spam and malware?

TLS-protected mail does, because each server decrypts it on arrival. End-to-end encrypted mail usually can't be. Microsoft says S/MIME doesn't allow encrypted messages to be scanned for malware, spam or policies, and Google says DLP scans can't access client-side encrypted content. Plan other controls for that mail.

### Is TLS enough for sending sensitive data by email?

Often not on its own. TLS protects each hop, but every server along the way can read the message, it may fall back to plain text if the other side lacks TLS, and stored copies aren't covered. For contracts, health or financial data, add message-level encryption or use a portal-based service.

## Sources

- [Microsoft Learn: Email encryption in Microsoft 365](https://learn.microsoft.com/en-us/purview/email-encryption)
- [Microsoft Learn: Microsoft Purview Message Encryption](https://learn.microsoft.com/en-us/purview/ome)
- [Microsoft Learn: Encryption in the Microsoft cloud](https://learn.microsoft.com/en-us/purview/office-365-encryption-in-the-microsoft-cloud-overview)
- [Google Workspace Admin Help: About client-side encryption](https://knowledge.workspace.google.com/admin/security/about-client-side-encryption)
- [Google Workspace Admin Help: Client-side encryption FAQ](https://knowledge.workspace.google.com/admin/security/client-side-encryption-faq)
- [NIST SP 800-177 Rev. 1: Trustworthy Email (2019)](https://csrc.nist.gov/pubs/sp/800/177/r1/final)
- [RFC 8551: S/MIME Version 4.0 Message Specification](https://www.rfc-editor.org/rfc/rfc8551.html)
- [RFC 8314: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access](https://www.rfc-editor.org/rfc/rfc8314.html)

## Free tools for this guide

- [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker): Fetch and validate your MTA-STS policy, match it to your MX hosts and check TLS-RPT.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/email-encryption-types-for-business (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt