DEV Community

Cover image for Sending & Opening Encrypted Emails with Outlook
Thomas Delfing
Thomas Delfing

Posted on

Sending & Opening Encrypted Emails with Outlook

#outlook #encryption #microsoft365 #security

Context: What “encrypted email” in Outlook really means

Many users say “encrypt Outlook” and simply mean “send securely.” From a technical perspective, that is too vague. In practice, there are three different protection levels that are often confused:

Transport encryption (TLS)

Protects the connection between mail servers. The content is better protected against “eavesdropping in transit,” but it typically still exists in clear text on the involved systems (or can be decrypted there).

Content encryption (message and rights management)

The content (body and attachments) is protected so that it can only be read by authorized identities, even outside the transport path.

In Microsoft 365, this is typically Microsoft Purview Message Encryption (the successor to OME/IRM).

End-to-end encryption (E2EE) with S/MIME or OpenPGP

The content is encrypted by the sender and can only be decrypted by the recipient. Ideally, the key material is not stored centrally on the mail server.

The German Federal Office for Information Security (BSI) typically associates S/MIME with government and enterprise environments, and OpenPGP more with private use.

Important (often overlooked):

With OpenPGP and S/MIME, classic email metadata (for example sender, recipient, subject, timestamps, routing headers) is usually not fully encrypted. A confidential subject line already reveals information.

Table of Contents

  • Which emails should be encrypted?
  • Sending encrypted emails: methods and decision support
  • Sending encrypted emails in Outlook (Microsoft Purview)
  • Opening encrypted emails (Microsoft Purview)
  • Sending encrypted emails with S/MIME (Outlook)
  • Opening S/MIME-encrypted emails (Outlook)
  • Troubleshooting (common issues)
  • Extra tips (operations, governance, rollout)
  • Limitations when working with Genese (EWS archiving & encryption)

1) Which emails should be encrypted in Outlook – and why?

1.1 The core issue: Email without content encryption is a “postcard”

If a message is sent unencrypted, it can be accessed by unauthorized parties depending on the transport path, involved systems, misconfigurations, or compromised accounts.

In an enterprise context, this quickly becomes a compliance and liability issue (GDPR, trade secrets, contractual and professional obligations).

True end-to-end encryption ensures that content is protected at the moment of sending and only becomes readable again by the recipient.

1.2 Practical categorization

Typical content that should be encrypted:

  • Personal data HR matters, salary data, applications, health information
  • Contracts and negotiations Draft contracts, NDAs, M&A documents, price lists
  • Financial data Bank details, payment schedules, invoice details
  • IP and legal matters Legal briefs, expert opinions, warnings, strategies
  • Credentials and secrets Passwords, tokens, admin information

Rule of thumb:

If you would not comfortably write the information on a postcard, it should be encrypted or shared via a secure data room.

2) How to send encrypted emails in Outlook

Outlook is typically used with:

  • Exchange Online (Microsoft 365)
  • Exchange on-premises
  • Hybrid environments

Two approaches are commonly used.

2.1 S/MIME – classic end-to-end encryption

Principle:

  • Each user has a certificate (public/private key).
  • The sender encrypts with the recipient’s public key.
  • Only the recipient can decrypt with their private key.

Characteristics:

  • Very strong end-to-end model
  • Operationally demanding (certificates, devices, renewals)
  • Limited usability in web and mobile clients

2.2 Microsoft Purview Message Encryption

Principle:

  • Encryption is applied server-side within Microsoft 365.
  • Access is tied to the recipient’s identity.
  • Well suited for external recipients without certificates.

Key considerations:

  • Included in specific Microsoft 365 licenses
  • Message and attachment size is typically limited to 25 MB
  • Usage rights such as “Do Not Forward” are available

2.3 Decision support

  • Frequent external communication: → Purview as the standard
  • Strict E2EE or government requirements: → S/MIME
  • Mixed requirements: → Purview as default, S/MIME for defined partners

3) Sending encrypted emails in Outlook (Microsoft Purview)

3.1 Prerequisites

  • Appropriate Microsoft 365 license or AIP Plan 1
  • Purview/IRM enabled in the tenant
  • Awareness of the size limit (typically 25 MB)

3.2 Outlook desktop

  1. Create a new email
  2. Go to Options → Encrypt
  3. Choose the desired option (for example Encrypt or Do Not Forward)
  4. Send

Practical tip:

Sensitivity Labels combine classification, encryption, and usage rights, reducing user error.

3.3 Outlook on the web

The process is similar, but visibility depends on tenant, policy, and license configuration.

4) Opening encrypted emails (Microsoft Purview)

4.1 Internal recipients

Usually seamless: the content is displayed directly in the mailbox.

4.2 External recipients

Typical flow:

  1. Recipient receives a notification email
  2. Clicks “Read the message”
  3. Authenticates or uses a one-time passcode
  4. Reads and replies in a secure web portal

5) Sending encrypted emails with S/MIME

5.1 Requirements

  • A valid S/MIME certificate per user
  • Import of the certificate including the private key
  • Exchange of certificates with communication partners

5.2 Sending (simplified)

  1. Activate the certificate
  2. New email → Options → Encrypt → S/MIME
  3. Send

Important:

If the private key is lost, the message cannot be decrypted.

6) Opening S/MIME-encrypted emails

  • Outlook desktop: automatic if the certificate is present
  • Outlook on the web: only with the S/MIME control or extension installed

7) Troubleshooting: common issues

“Encrypt” button is missing

  • Incorrect license
  • Purview/IRM not enabled
  • Sensitivity Labels not published

External recipient cannot open the email

  • Authentication problems
  • Portal links blocked by security tools

S/MIME: message cannot be decrypted

  • Private key missing
  • Certificate expired or revoked
  • No S/MIME control in the browser

8) Extra tips for operations and governance

  • Use Sensitivity Labels instead of relying on manual clicks
  • Do not place confidential information in the subject line
  • Share large files via secure links instead of attachments
  • Clearly define which content must be archived in clear text

9) Limitations when working with Genese (EWS archiving)

9.1 S/MIME and server-side archiving

S/MIME is strictly end-to-end.

Without the private key, the server cannot decrypt the content.

Implication for Genese (EWS):

  • Encrypted emails can be stored
  • Content cannot be indexed or analyzed in clear text server-side

9.2 Purview-encrypted emails

Here as well, readability depends on identities and rights management.

An EWS service cannot automatically decrypt content.

9.3 Practical guideline

  • Server-side storage: only encrypted
  • Clear-text archiving: often only possible client-side via Outlook
  • Alternative: store documents in a data room and include only a link in the email

Conclusion

  • Microsoft Purview Message Encryption is the most economical standard for many organizations.
  • S/MIME remains the method of choice for true end-to-end requirements.
  • For Genese, the rule is clear: Encrypted content can be stored reliably, but cannot be decrypted server-side without access to keys.

Ultimately, success depends not only on technology, but on a well-aligned combination of security, compliance, and archiving strategy.

Top comments (0)