Not all users of a O365 environment can be joined to a domain that is part of the O365 infrastructure. Many of us use a website OWA access that belongs in a government domain, but are required to use their o365 email for all communication. Edge and Chromium SMIME extensions must work for external computers that are not joined to the domain, since millions of our corporate computers will never be joined to these domains. We remain stuck to 32bit Internet Explorer for SMIME. Either remove the domain requirement, take on the acceptance and control of domains that are acceptable to our customer, or fully deprecate SMIME.

The page on message encryption mentions third party providers like GPG / PGP encryption. I clicked the "Encrypt" button (Outlook Web UI) and sent an email to my ProtonMail account, but it didn't encrypt, just sent a link that can be used to view the email (with a passcode that it sends in a separate email, also not encrypted).

It would be good to expand the use of Encrypt to interoperate with other providers, by looking up where key discovery exists (such as WKD), or using Opportunistic Security (RF 7435), e.g. where a message arrives with an OpenPGP key attached, use that key to encrypt replies.

This would make the message exchange encrypted but not verified, and give the option to verify (such as WKD or manual verification).

The current system is vulnerable to active man-in-the-middle attacks, as the passcode can simply be requested to be sent to the same email address the "encrypted" message was.

Where the other side support standardised security, such as OpenPGP, even using something like ToFU would prevent active MitM attacks (unless they were active from first use).

If Microsoft were to deploy out WKD infrastructure that would also help with adoption of interoperable security, e.g. with third party providers like ProtonMail, etc