How Does Opensense Work with Microsoft 365?

Overview

Opensense integrates with Microsoft 365 through Exchange Online mail flow rules and the Opensense Outlook Add-in. Together, these allow Opensense to centrally manage email signatures across your organization — enforcing brand consistency, legal compliance, and marketing campaigns on every outbound email. User data is sourced from Azure AD (Entra ID) or another connected directory and synced to Opensense for dynamic signature population.

How the integration works

Opensense connects to your Microsoft 365 environment through two components that work together:

Mail flow rules in Exchange Online — route qualifying outbound emails to Opensense via a transport rule. Opensense applies the correct HTML signature and any configured marketing banners, then returns the email to Microsoft via TLS for final delivery. A custom header is appended to processed emails to prevent re-processing.
The Opensense Outlook Add-in — a Microsoft 365 Integrated App deployed via Centralized Deployment. It loads automatically when a user opens a compose window in Outlook. Depending on configuration, it handles removing local signatures, inserting the plaintext block token, or rendering a visual preview in compose. For server-side methods, the add-in pane also displays a preview of what recipients will receive.

Mail flow rules handle where and how signatures are applied. The add-in handles the compose window experience. The combination you use depends on your deployment method.

Deployment Methods

Opensense supports three deployment methods for Microsoft 365. Each determines how signatures are applied, what users see in compose, and what compliance and marketing capabilities are available:

Stamping — signatures applied entirely server-side post-send. Nothing inserted into compose. Add-in pane shows a preview of what recipients will receive.
Plaintext block — the add-in inserts a token into compose. Mail flow rule routes the email to Opensense for server-side transformation. Add-in pane shows a preview of what recipients will receive. Opensense's patented approach and recommended for most deployments.
Visual preview — full HTML signature rendered client-side in the compose window. Users can see and edit before sending.

For a full breakdown of tradeoffs and guidance on choosing the right method, see Outlook Add-in Deployment Methods: Stamping, Plaintext Block, and Visual Preview.

Opensense O365 Architecture Diagram — Opensense M365 Architecture Diagram

Outlook Add-in requirements

Mailbox: Exchange Online. On-premises Exchange does not support the add-in.
License: Microsoft 365 or Office 365 subscription. Volume licenses (Office 2016, 2019, 2021) do not support the required API version.
Deployment method: Centralized Deployment via Microsoft 365 Admin Center.
Outlook for Windows: Version 2104 (Build 13929.20296) or later, Click-to-Run only. MSI-based installs are not supported.
Outlook for Mac: New Outlook version 16.38.506 or later. Legacy Outlook for Mac is not supported.
Outlook on the Web (OWA): Supported in modern browsers with an M365 mailbox.
Outlook Mobile (iOS and Android): Supported. GCC and GCC High environments require additional PowerShell configuration to enable mobile add-ins.
Office JavaScript API: v1.10 or later required. Some features require v1.13 (M365 subscriptions only).
Admin consent: Recommended before launch to prevent per-user permission prompts.
Propagation: Allow up to 72 hours after deployment for the add-in to appear for users.

On-premises Exchange

Organizations running on-premises Exchange are supported through ExSBR by MessageConcepts, a transport agent installed directly on Exchange servers. This is a separate integration path. The Outlook Add-in is not supported in on-premises Exchange environments. ExSBR licensing is separate from Opensense and is passed to the customer. Setup is completed with an Opensense implementation engineer. Contact help@opensense.com to discuss requirements.