Setting up email encryption in Office 365 involves choosing between Microsoft's built-in tools (primarily Microsoft Purview Message Encryption and S/MIME) and configuring them through the Microsoft 365 admin center or Exchange Online PowerShell. The right approach depends on your security requirements, the sensitivity of the data you handle, and whether you need encryption that extends beyond Microsoft's ecosystem. This article walks through the key questions organizations ask when evaluating and configuring email encryption in Office 365.

What types of email encryption does Office 365 support?

Office 365 supports two main types of email encryption: Microsoft Purview Message Encryption (formerly Office 365 Message Encryption) and S/MIME (Secure/Multipurpose Internet Mail Extensions). Purview Message Encryption is a policy-based, cloud-managed solution that works without requiring recipients to manage certificates. S/MIME is a certificate-based standard that provides stronger cryptographic guarantees but requires both sender and recipient to have compatible certificates.

Beyond these two primary options, Office 365 also uses Transport Layer Security (TLS) to protect messages in transit between mail servers. However, TLS is a connection-level protection: it secures the channel while the message travels, not the message content itself. Once a message arrives at its destination mail server, TLS no longer protects it. This distinction matters significantly for organizations handling sensitive or regulated data.

In practice, the three approaches address different layers of protection:

• TLS: Encrypts the connection between mail servers during transit
• Microsoft Purview Message Encryption: Encrypts message content using Microsoft-managed keys with policy-based enforcement
• S/MIME: Encrypts message content using recipient-specific certificates, providing stronger end-to-end guarantees

How does Microsoft Purview Message Encryption work?

Microsoft Purview Message Encryption works by applying Rights Management Service (RMS) policies to outgoing messages. When a matching mail flow rule triggers, Microsoft encrypts the message content using Azure-managed keys. Recipients outside your organization receive a notification with a link to read the message through a secure web portal or by authenticating with a Microsoft account or one-time passcode.

The system is tightly integrated with Microsoft 365 and requires an Azure Information Protection plan, which is included in Microsoft 365 E3 and above. Administrators configure encryption through mail flow rules in Exchange Online, rules that inspect message properties such as sender, recipient domain, subject keywords, or sensitivity labels and apply the appropriate protection automatically.

One important characteristic of Purview Message Encryption is that Microsoft holds the encryption keys. This is convenient for administration and recovery, but it means your organization does not have sole control over who can technically access message content. For many organizations, this is acceptable, but for those operating under strict data sovereignty or confidentiality requirements, this architecture warrants careful consideration.

How do you configure S/MIME encryption in Office 365?

Configuring S/MIME encryption in Office 365 requires obtaining valid S/MIME certificates for users, publishing public keys so recipients can encrypt messages to your users, and enabling S/MIME support in supported email clients. The process involves steps across certificate management, Exchange Online configuration, and individual client setup.

The high-level configuration process follows these steps:

1. Obtain certificates: Each user who will send or receive S/MIME-encrypted mail needs an S/MIME certificate issued by a trusted Certificate Authority (CA). Your organization can use an internal CA or a commercial provider.
2. Publish public keys: Public certificates must be available to senders who want to encrypt messages to your users. In Exchange Online, you can publish certificates to the Global Address List (GAL) so internal senders can find them automatically.
3. Enable S/MIME in Exchange Online: Use the Exchange admin center or PowerShell to enable S/MIME for your organization and configure virtual certificate collection settings where needed.
4. Configure email clients: Users must configure their email client (Outlook on Windows, Outlook on Mac, or Outlook on the web) to use their personal certificate for signing and encryption. Each client has its own settings path.
5. Distribute private keys securely: Private keys must be installed on each device the user sends encrypted mail from. This is often the most operationally demanding aspect of S/MIME deployment at scale.

S/MIME works well in controlled environments where certificate infrastructure is already in place. In organizations without existing PKI (Public Key Infrastructure), the overhead of issuing, distributing, and renewing certificates for every user can be substantial.

What are the limitations of Office 365's built-in encryption?

Office 365's built-in encryption tools have several meaningful limitations that affect organizations with advanced security requirements. The most significant are Microsoft's control over encryption keys, limited support for recipients outside the Microsoft ecosystem, the complexity of S/MIME at scale, and the absence of protection for messages stored on the mail server beyond what Microsoft's infrastructure provides.

Key management and data sovereignty

With Purview Message Encryption, Microsoft manages the encryption keys through Azure Rights Management. Organizations that require sole control over their cryptographic keys (a common requirement in healthcare, finance, and public-sector environments) cannot achieve this with the default configuration. Microsoft does offer Customer Key as an add-on for higher licensing tiers, but this adds cost and complexity.

Recipient experience and interoperability

When a Purview-encrypted message reaches a recipient outside Microsoft 365, the experience depends on their mail provider. Recipients using Gmail or other modern providers may be able to read messages inline, but others are redirected to a web portal. This works for occasional secure communication but creates friction at scale. S/MIME avoids this problem only when both parties have compatible certificates, a condition that is often difficult to guarantee with external partners.

Additionally, Office 365's built-in tools do not natively support OpenPGP, the other widely used email encryption standard. Organizations communicating with partners who use PGP-based encryption will find no built-in path for that interoperability within Office 365.

When should organizations use a third-party encryption solution instead?

Organizations should consider a third-party email encryption gateway when they need support for both S/MIME and OpenPGP, require control over their own encryption keys, want to protect messages stored on the mail server independently of Microsoft's infrastructure, or need to introduce encryption gradually across a large user base without reconfiguring every client.

Specific scenarios where third-party solutions add clear value include:

• Mixed cryptographic environments: When external partners use OpenPGP rather than S/MIME, a gateway that supports both standards handles the translation centrally without requiring users to manage multiple tools.
• Centralized key management: A dedicated encryption gateway can manage keys for all users from a single point, reducing the per-device complexity that makes S/MIME difficult to scale.
• Protection for stored messages: Office 365's encryption primarily covers messages in transit. A gateway solution can also encrypt messages as they are stored in mailboxes, including copies saved in Sent folders, so that confidential content remains protected at rest.
• Gradual adoption: A gateway model allows organizations to begin encrypting communication with selected domains or addresses and expand coverage over time, without requiring every user and external recipient to be ready simultaneously.
• Compliance with specific standards: Some regulatory frameworks specify requirements around key custody or encryption standards that Microsoft's default tools do not meet without significant additional configuration.

What compliance standards does email encryption in Office 365 support?

Email encryption in Office 365 supports compliance with several major regulatory frameworks, including GDPR, HIPAA, ISO 27001, and various financial sector regulations that require protection of sensitive data in transit and at rest. However, whether Office 365's built-in encryption fully satisfies a specific compliance requirement depends on the details of that requirement and how the tools are configured.

GDPR, for example, does not mandate a specific encryption technology but requires that personal data be protected with appropriate technical measures. Microsoft Purview Message Encryption and S/MIME both qualify as appropriate technical measures for data in transit. The question for GDPR compliance often centers on data residency and key control (where data is processed and who can access it), areas where Microsoft's default architecture may require additional review for organizations in the EU.

HIPAA requires that electronic protected health information (ePHI) be safeguarded during transmission. Office 365 can support HIPAA compliance when configured correctly, and Microsoft offers a Business Associate Agreement (BAA) for covered entities. However, compliance is not automatic: it depends on mail flow rules being correctly configured to encrypt messages containing ePHI before they leave the organization's environment.

For organizations in regulated industries, email encryption is rarely a standalone compliance checkbox. It sits within a broader information security program that includes access controls, audit logging, incident response, and data classification. The encryption layer (whether built-in or provided by a third-party gateway) needs to fit that broader framework.

How Savignano Software Solutions helps with Office 365 email encryption

For organizations that need encryption capabilities beyond what Office 365 provides natively, Savignano Software Solutions offers Uptrust Email Encryption, a centrally managed encryption platform designed to work alongside existing mail infrastructure, including Office 365 environments.

Uptrust addresses the gaps that commonly arise with built-in Office 365 encryption:

• Support for both S/MIME and OpenPGP: Administrators can configure S/MIME only, OpenPGP only, or a preference for one standard with the other available as a fallback, enabling encrypted communication with a wider range of external partners.
• Centralized key management: Keys are managed at the gateway level, reducing the per-device complexity of S/MIME deployment and allowing encryption to be introduced without reconfiguring every user's email client.
• Protection for stored messages: Uptrust Email Encryption covers both outgoing SMTP delivery and IMAP storage, including copies saved in Sent folders, so that message content remains encrypted on the mail server, not just during transit.
• Gradual adoption: Protection can be scoped to selected domains or individual addresses and expanded over time, making it practical to roll out encryption without requiring all users and partners to be ready at once.
• Flexible deployment: Uptrust is available as an on-premises gateway or a cloud gateway, allowing organizations to choose the deployment model that fits their infrastructure and data sovereignty requirements.

Savignano Software Solutions also offers consulting services in information security and systems integration, helping organizations design an encryption strategy that fits their compliance requirements and existing technology stack. To discuss your organization's email encryption needs, get in touch with the team directly.