Overview
The Opensense Outlook Add-in is a centrally managed Microsoft 365 Integrated App that automatically applies your company's email signatures to every email composed in Outlook — on desktop, web, and mobile. It is deployed and managed by your IT, requiring no action from end users.
This article explains how the add-in works, the available deployment modes and their tradeoffs, and links to all resources in this section.
Who this article is for: IT admins configuring or managing the add-in.
End users looking to understand what the add-in does and how to use it on mobile can skip to the End user experience section.
GCC High compatible: The Opensense Outlook Add-in is compatible with Microsoft 365 GCC High environments. Opensense connects to the Azure Government cloud infrastructure purpose-built for GCC High, allowing user data to be sourced directly from your GCC High Azure AD tenant. Additional configuration is required. See Opensense Add-in Integration with GCC High Environments for details.
How it works
Once deployed, the Opensense Outlook Add-in loads automatically when a user opens a new compose window in Outlook and inserts their assigned signature.
How that signature is handled depends on your deployment mode:
Client-side: The signature is sent directly with the email from Outlook.
Server-side stamping: The signature is cleared from the compose window before the email is sent, and Opensense's servers apply the signature during routing.
The add-in is deployed via Microsoft 365's Centralized Deployment. Your admin assigns users or groups in the Microsoft 365 Admin Center, and the add-in installs silently across Outlook Desktop, Outlook Web Access (OWA), and Outlook Mobile.
Deployment Methods
The add-in supports three deployment methods. The right choice depends on how much compose-window visibility your employees need and how much server-side control your organization requires for compliance and marketing.
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.
Plaintext Block vs Visual Preview
Server-side stamping with add-in signature removal
The add-in removes any locally saved Outlook signatures before the email is sent. No signature is visible in the compose window. The email routes through Opensense's servers post-send, where the correct HTML signature and any marketing banners are applied before delivery.
Compliance: Signatures are applied entirely server-side. Users cannot modify them.
Marketing: Full recipient-based banner targeting and advanced analytics are supported.
End user experience: No signature visible while composing. Employees need to understand this is expected behavior before launch.
Best for: Organizations that require strict signature control and can communicate the compose-window experience to employees clearly.
Plaintext block (patented)
The add-in inserts a tokenized plaintext block containing Opensense's proprietary [[#]] trigger into the compose window, alongside a non-clickable visual preview showing what the final rendered signature will look like. When the email is sent, a mail flow rule detects the [[#]] token and routes the message to Opensense, where it is transformed server-side into the full HTML signature before delivery.
The plaintext block bridges the gap between stamping and visual preview: employees get a visual indicator that their signature will be applied, while the actual signature remains under server-side control.
Compliance: The final signature is applied server-side by Opensense. Users cannot modify the rendered output.
Marketing: Full recipient-based banner targeting and advanced analytics are supported.
End user experience: Users sees a plaintext trigger where a signature will render in the compose window. The add-in has a built-in preview of the HTML that is non-clickable and non-editable.
Best for: Organizations that want server-side compliance and the full marketing feature set, while giving employees visible confirmation that their signature is active.
Visual preview
The add-in renders a live HTML signature directly inside the Outlook compose window. The signature is inserted client-side before the email is sent.
Compliance: Because the signature exists in the compose window before send, users can manually edit it — content, formatting, layout — prior to sending. Those edits bypass Opensense servers entirely and are not tracked or blocked. This is a meaningful compliance risk for organizations with signature governance requirements.
Marketing: Banner targeting is limited to sender-based rules only. Recipient-based targeting is not supported. Analytics are limited to basic views and clicks; advanced banner analytics are not available.
End user experience: Users see and interact with a fully rendered HTML signature while composing.
Best for: Organizations where compose-window visibility is a priority and compliance risk and marketing limitations are acceptable tradeoffs.
Visual preview and compliance: If your organization uses email signatures for legal disclaimers, regulatory compliance, or brand governance, review the tradeoffs carefully before choosing this mode. See Outlook Add-in Visual Preview: Capabilities and Tradeoffs for full detail.
System requirements
The add-in requires Exchange Online, a supported Microsoft 365 or Office 365 license, and an Outlook client that meets the minimum version for Centralized Deployment. MSI-based installs and volume-licensed Office versions (Office 2016, 2019, and 2021) are not supported as they do not support the required API version.
See Supported Environments Outlook Add-in for the full version table, platform support matrix, and unsupported environments.
Key deployment considerations
Propagation time
After a user or group is added to the add-in's deployment scope in Microsoft 365, it can take up to 72 hours for the add-in to appear in Outlook. Plan your rollout timeline accordingly and add test users first to gauge propagation speed in your environment.
Admin consent
End users will be prompted to accept permissions when the add-in deploys unless an admin grants consent in advance. To avoid permission prompts disrupting employees, grant admin consent via Azure Active Directory before launch. See Scope Users for Opensense Outlook Add-in via Microsoft 365 Admin for steps.
Nested groups are not supported
Microsoft does not support nested groups for Centralized Deployment. Users must be directly assigned to a top-level Microsoft 365 group. If your user group structure uses sub-groups, users must be added to a top-level group manually.
Third-party email platforms
The Outlook Add-in only applies signatures to emails composed in Microsoft Outlook. Emails sent through third-party platforms such as Outreach, Salesloft, or Salesforce are not covered by the add-in. For those platforms, use Opensense's routed mail flow integrations.
Outlook Mobile — From switching limitation
On Outlook Mobile, the add-in only passes the primary account context to the API. If a user switches the From address to an alias or shared inbox, the add-in will not update the signature to reflect the switched identity. This is a Microsoft platform limitation.
End user experience
For most employees, the Opensense Outlook Add-in requires no setup or action. Once deployed by your IT admin, the signature appears automatically when composing a new email in Outlook. Locally saved Outlook signatures are replaced or removed by the add-in.
Depending on your organization's configuration, you may see:
A plaintext block in the compose window with a non-clickable preview of your formatted signature
A fully rendered HTML signature in the compose window (visual preview mode)
No visible signature in the compose window, with the signature applied automatically after send (stamping mode)
If your signature contains incorrect information, contact your IT helpdesk or the team that manages your Opensense account.
For instructions on accessing the add-in on your mobile device, see:
Article directory
All Outlook Add-in documentation is organized below by topic. If you are setting up the add-in for the first time, start with Requirements and deployment.
Requirements and deployment
Supported Environments for the Opensense Outlook Add-in — minimum version requirements, supported and unsupported platforms
Scope Users for Opensense Outlook Add-in via Microsoft 365 Admin — deploying and managing user scope in Microsoft 365
Configuration
Outlook Add-in Domain Settings with Scenarios and Best Practices — signature insertion settings, alias and shared inbox behavior, editable fields, and inline images
Outlook Add-in Multi-Signature Selector — enabling and configuring multiple signatures per user
Outlook Add-in Custom Compose Fields — configuring dropdown, checkbox, and free-text fields in the compose pane (not compatible with stamping)
Routed Key Behaviors, Limitations and Nuances — edge cases for stamping with field edits, shared account permissions, domain switching, and manual manifest installation
Visual preview
Outlook Add-in Visual Preview: Capabilities and Tradeoffs — what visual preview supports, compliance risks, marketing limitations, and when it makes sense to use it
GCC and GCC High environments
Opensense Add-in Integration with GCC High Environments — custom manifest deployment, directory sync requirements, and mobile configuration for GCC High
Outlook Mobile Add-in within GCC and GCC High Environments — enabling mobile add-ins in GCC environments where they are disabled by default
Troubleshooting and offboarding
Outlook Add-in Troubleshooting Guide — missing add-in, permission issues, signature not applying, cache clearing, and debugging
How to Remove the Opensense Outlook Add-in from Microsoft 365