Microsoft just shipped Mailbox requirement set 1.16 for Outlook add-ins to GA. If you have ever tried to retire a legacy COM/VSTO add-in and hit a wall on signed or encrypted mail, the Outlook add-ins Mailbox 1.16 release is the one that finally moves the needle. The official announcement is on the Microsoft 365 Developer Blog and it is worth a careful read.
I have been watching this gap close slowly for years. This one is a real jump.
What shipped in Mailbox 1.16
Mailbox 1.16 is the next API surface for Outlook web add-ins. The headline capabilities focus on message and information security. Add-ins can now decrypt protected messages and attachments inside an event-based workflow, read and act on sensitivity labels, and handle a broader set of signed and encrypted mail scenarios that previously forced teams to keep a COM add-in in production.
For anyone who has not been tracking it, the Mailbox requirement set is the contract between your add-in manifest and the Outlook host. You declare the minimum requirement set you need, and Outlook tells you whether the host can run it. Hitting 1.16 GA means it is now safe to target this version on production Outlook surfaces across Windows, Mac, web, and the new Outlook for Windows.
What it actually does
The two pieces I care about most are event-based decryption and sensitivity label handling.
Event-based decryption is the one that unblocks real migrations. Before 1.16, a web add-in that needed to read the body of a protected message basically could not, which is why so many compliance and DLP add-ins stayed on COM. You can now wire an OnMessageRead or similar event, decrypt the protected payload, and run your logic against the actual content. That is the difference between a working add-in and a stub that fails on every rights-protected mail.
Sensitivity label APIs let the add-in read the applied label, react to label changes, and gate behavior on classification. If you are building anything that has to respect Purview labels, this is the surface you wanted.
It is not a full COM parity. Deep MAPI access is still off the table. If your old add-in pokes at properties through extended MAPI, you are still doing a rewrite, not a port.
Why it matters
COM add-ins are on a deprecation path. Microsoft has been signaling this for a long time, and the new Outlook for Windows does not run them the way classic Outlook does. Every team I talk to with a legacy Outlook add-in has the same backlog item: figure out the web add-in story before the runway runs out.
Until now, that backlog item had a hard blocker for any add-in that touched protected or classified mail. Compliance add-ins, encryption helpers, journaling tools, archive integrations. They all needed APIs that did not exist on the web side. So the migration plan stalled and the COM add-in stayed.
Mailbox 1.16 removes that blocker for a real chunk of those scenarios. Not all of them. But enough that the conversation changes from “we cannot migrate” to “we have a path, let us scope it.”
The other reason this matters: event-based activation plus decryption means you can do server-light add-ins that react to mail as it is read or sent, without standing up a full middle tier. For internal tooling teams, that is a smaller surface to maintain.
What I would do with it this week
If I had a legacy COM add-in I was trying to retire, I would do three things.
First, pull the manifest of the old add-in and list every property and event it touches. Map each one to the current Outlook JavaScript API requirement sets. The ones that now map cleanly to 1.16 are your quick wins. The ones that still do not map are the work you have to scope separately.
Second, build a small proof of concept that handles one protected message end to end. Event-based activation, decrypt, read the body, write something useful back. If that pipeline works on your tenant with your label policy, you have de-risked the hardest part of the migration.
Third, think about where the add-in talks to the rest of your stack. If you are landing extracted data into Dataverse or kicking off a Power Automate flow from the add-in, the same question I covered in Stop Reaching for Desktop Flows When a Cloud Flow Would Do the Job applies here too — choose the right automation layer before you wire anything up. Decryption failures, label mismatches, and event timeouts all need explicit handling, not a generic retry.
And if you are prototyping any of the logic locally before wiring it into the add-in, the notes from Thirty Days Running Ollama Locally for Automation Work are worth a look — the same trade-offs around local versus cloud processing show up when you are deciding where to run label inspection or decryption logic.
I have been waiting for this one. Time to see if it holds up on a real mailbox. More notes on my LinkedIn once I have something running.
The COM to web migration story for Outlook just got a lot more believable.
This post was inspired by Mailbox requirement set 1.16 now available for Outlook add-ins via Microsoft 365 Developer Blog.
Leave a Reply