365 S/MIME signed Emails

Hi @Sean Slaton 

The confusion usually comes from two factors: S/MIME uses two different certificates, and Classic Outlook and OWA handle certificates very differently.  

Classic Outlook 

Classic Outlook uses the local Windows certificate store and Windows cryptographic APIs (CAPI/CNG). It can: 

• use locally installed personal certificates 
• automatically extract and cache a sender’s public certificate from a digitally signed email 
• use that cached public certificate to encrypt a reply back to that sender 

Because of this, Classic Outlook can often reply successfully even if the user did not manually install a certificate themselves. 

OWA 

OWA works differently: 

• It does not use the full Windows certificate store directly 
• It relies on browser-based S/MIME support and Exchange Online configuration 
• Certificates must be accessible and trusted in the service context 

This introduces additional limitations for external S/MIME scenarios compared to Classic Outlook.

Why replies sometimes work “without a cert installed”  

There are actually two certificates involved:  

-Your user’s certificate: required for signing outbound mail and decrypting inbound encrypted mail. This normally must be installed locally or deployed via enterprise PKI/admin policy.  

-The sender’s public certificate: attached to their signed email, used to encrypt replies.  

Classic Outlook can automatically cache the sender’s public certificate from the signed message. So even if the user is not aware of having a personal S/MIME certificate installed, Outlook may still be able to reply because it can use an existing certificate in the local store together with the cached sender’s public certificate.

Proton 

Proton often uses OpenPGP-based encryption, which is not identical to Microsoft’s S/MIME workflow. While limited interoperability exists, differences in trust models and encryption expectations can cause inconsistencies between Classic Outlook, OWA, and New Outlook. 

New Outlook 

New Outlook for Windows is architecturally much closer to OWA than to Classic Outlook. That means certificate handling, S/MIME support, dependency on web-based behavior are much closer to OWA.  

Microsoft also notes that New Outlook does not automatically import digital certificates, and certificates must be installed manually or deployed by admin policy. So if OWA cannot handle the reply scenario properly, New Outlook will usually have the same limitation. 

Reference: Set up Outlook to use S/MIME encryption - Microsoft Support. 

I hope this information is helpful. 

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".          

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

Classic Outlook and Outlook on the web (OWA) handle S/MIME in different ways, and that difference explains the behavior.

1. S/MIME basics and endpoints S/MIME in Exchange/Microsoft 365 is supported on multiple endpoints, but each endpoint has its own requirements and trust store:

• Outlook 2010 or later (Classic Outlook)
• Outlook on the web (OWA)
• Exchange ActiveSync (mobile)

Supported scenarios and technical considerations describe that each endpoint must be explicitly set up for S/MIME.

2. Classic Outlook vs. OWA certificate usage

Classic Outlook

• Uses the Windows local certificate store on the client machine.
• Can use S/MIME certificates that are installed locally for the user profile, regardless of whether they are published in Azure AD/Exchange.
• When replying to an S/MIME signed or encrypted message, Outlook uses the sender’s public key (from the original message) and the local user’s private key (if needed) from the local store.

OWA (Outlook on the web)

• Does not use the Windows local certificate store directly.
• Relies on:
  • S/MIME being configured and enabled on the Exchange/Exchange Online side.
  • A virtual certificate collection and trusted roots configured in Exchange for S/MIME validation.
  • User certificates being published in directory attributes (UserSMIMECertificate/UserCertificate) for some scenarios.
• For OWA, S/MIME support must be explicitly configured on the server side, including the S/MIME control and virtual certificate collection.

This is summarized in the S/MIME guidance:

• For Exchange/Exchange Online, S/MIME requires:
  1. A PKI/CA issuing S/MIME certs (can be third-party or internal).
  2. Publishing user certs in AD DS attributes.
  3. A virtual certificate collection for OWA to validate signatures.
  4. Endpoint configuration for Outlook or OWA.

See “Supported scenarios and technical considerations for S/MIME” and “Set up S/MIME with Outlook on the web” in the S/MIME documentation.

3. Why Classic Outlook can reply but OWA cannot

Given:

• No third‑party CA certificate is deployed in Microsoft 365.
• The user can reply from Classic Outlook but not from OWA.

Likely explanation:

• Classic Outlook is simply using the S/MIME information embedded in the received message (the sender’s public key) and does not require tenant-level S/MIME configuration to reply to a signed message, especially if the reply is only signed or uses the sender’s public key for encryption.
• OWA, by contrast, requires the S/MIME feature to be configured on the Exchange side and a trusted certificate chain/virtual certificate collection to validate and use S/MIME. If that configuration is missing or incomplete, OWA will not allow composing/replying with S/MIME even though Classic Outlook can.

In other words, Classic Outlook is more “self-contained” and uses the local Windows certificate store and message content, while OWA depends on Exchange’s S/MIME configuration and directory-published certificates.

4. Proton and end‑to‑end encryption

Proton’s end‑to‑end encryption is not the same as Exchange/Outlook S/MIME, but if Proton is sending S/MIME‑signed or S/MIME‑encrypted messages, Outlook will treat them as S/MIME content:

• Classic Outlook: can consume and reply using the embedded S/MIME information and local certs.
• OWA: needs the Exchange S/MIME configuration and trust chain to validate and operate on those messages.

So the Proton side is less the issue; the key difference is how each Outlook endpoint is wired to S/MIME infrastructure.

5. What is required for OWA to behave more like Classic Outlook

To make OWA capable of replying to S/MIME messages similarly to Classic Outlook, the environment must:

1. Have a CA and PKI issuing S/MIME certificates (internal or third‑party).
2. Publish user S/MIME certificates into AD DS (UserSMIMECertificate/UserCertificate attributes).
3. Configure a virtual certificate collection in Exchange so OWA can validate S/MIME signatures and trust the issuing CAs.
4. Enable and configure S/MIME for Outlook on the web.

These steps are outlined in the S/MIME documentation for Exchange/Exchange Online.

References:

• S/MIME for message signing and encryption
• S/MIME for message signing and encryption in Exchange Server
• S/MIME for Outlook for iOS and Android in Exchange Online
• Send and receive S/MIME signed and encrypted email in Exchange Online
• S/MIME option disappears when you use Outlook Web App in Internet Explorer 11 in an Exchange Server 2010 environment
• Outlook doesnt recognize SMIME Certificate M365 - Microsoft Q&A