Overview
Domain Settings control how the Opensense Outlook Add-in behaves for users in your organization. This article covers each setting, what it does, and how to configure the right combination for common scenarios including shared inboxes, alias accounts, and multi-signature deployments.
Domain Settings are configured in the Opensense portal under Manage > Domain Settings > Outlook Add-in. You must have Domain Admin access to manage these settings.
Before you start
You will need:
Domain Admin access in the Opensense portal
The Opensense Outlook Add-in deployed to your users via Microsoft 365 Integrated Apps. See Outlook Add-in: Scope Users via Microsoft 365 Admin.
General settings
Automatic Signatures
When enabled, the add-in inserts the assigned signature automatically each time a user opens a new compose, reply, or forward window. No user action is required. Enable this setting for most deployments.
Default Signature Mode
When both Visual Preview and Plain Text Preview are enabled, this setting determines which mode is used as the default. Set this to match your primary deployment method.
Multiple Signatures
When enabled, users can switch between multiple assigned signatures directly from the add-in pane. Signature priority and assignment must be configured in Routes. See Outlook Add-in Multi-Signature Selector for full configuration detail.
Plain Text Preview
Enable this setting when using the plaintext block deployment mode. It allows the add-in to insert the [[#]] token into the compose window for server-side transformation.
Disable Default Signature
When enabled, the add-in removes any native Outlook signatures the user has configured. This prevents duplicate signatures when the Opensense signature is also present. Enable this for most routed and stamping deployments.
User Controlled Settings
When enabled, two manual toggles are exposed in the add-in pane for users: Disable Default Signature and Insert Automatically. Use this setting during testing or in environments where users need manual control over signature behavior.
Visual Preview
Enable this setting when using the visual preview deployment mode. It allows the add-in to render the full HTML signature in the compose window. If this setting is off, the visual preview will not display even if the user's signature template is configured for it.
Remove Signature for Unknown Domain
When enabled, the add-in clears the signature if the user switches the From address to a domain that Opensense does not recognize. This prevents a stale or incorrect signature from appearing when sending from an unrecognized domain.
For this setting to work correctly, all domains your organization sends from must be listed under Internal Domains in your domain settings. See Configuring Internal Domains below.
Allow Default Override
When enabled, users can choose between Plain Text Preview and Visual Preview directly from the add-in pane, and their selection persists across compose sessions. This setting is not commonly used and is primarily relevant when both Visual Preview and Plain Text Preview are enabled for a domain.
Allow Default Override (Multiple Signature)
Controls whether users retain their last selected signature from the multi-signature selector or always reset to the priority template when opening a new compose window.
Disabled: Users always reset to the priority template on each new compose.
Enabled: Users retain their last signature selection across compose sessions.
Inline Images
Inline images are supported across all Microsoft 365 Outlook clients including Classic Outlook, New Outlook, Outlook for Mac, OWA, and Outlook Mobile.
To enable inline images:
Turn on Inline Images in Domain Settings.
Append
?inline=1to all image URLs in the signature HTML. For example:https://smart.customer.com/v2/imagebucket/customer.com/logo.png?inline=1
SVG images are not supported in add-in-deployed signatures. SVG images in a signature template will cause the visual preview insert to fail entirely, not just render incorrectly. Use PNG or JPG for all images including logos and headshots.
Configuring Internal Domains
The Internal Domains list tells Opensense which domains are part of your organization. This is required for From Switching to work correctly when users send from alias addresses or multiple domains. If a user switches to a From address on a domain not in this list, the add-in will return a 400 Unauthorized error and no signature will appear.
In the left navigation, select Manage, then select Domains.
Click the ellipses (...) on the domain card you want to configure and select Manage Domain.
In the left navigation, select Domain Settings. Under the General section, locate the Internal Domains field and select Edit.
Add each alias or sending domain your users send from. Select Save when done.
If your organization has multiple primary domains, repeat this process for each domain, adding the other primary domains to each one's Internal Domains list.
A
400 Unauthorizederror when switching From addresses will not be resolved by clearing the add-in cache. The fix is always adding the domain to the Internal Domains list. If your organization has several primary sending domains and needs this update applied across all of them, contact help@opensense.com for assistance.
User and signature fields
Dynamic Fields
When enabled, signature fields can adjust in real time based on the recipient for full visual preview deployments.
Dynamic Fields conflicts with the HubSpot Sales add-in. It also applies only to the last recipient added to the To field, not all recipients. Avoid this setting unless no other option is available for your configuration.
Editable Fields
When enabled, users can modify select fields in their signature directly from the add-in pane. Only fields unlocked in the signature template will be editable. Fields with a lock icon are admin-controlled and cannot be edited by the user regardless of this setting.
Signature Fields Only
When enabled, the add-in pane displays only the fields that exist in the user's assigned signature template. Fields present in the user's Opensense profile but not in their template are hidden. This keeps the add-in pane focused and prevents confusion when templates use a subset of available profile data.
Custom Compose Fields
When enabled, additional fields appear in the add-in pane that users can toggle or populate before sending. These fields are configured under Custom Compose Fields Configuration and are used to control optional signature elements such as pronouns, phone visibility, or meeting links. See Outlook Add-in Custom Compose Fields for setup detail.
Email tracking
Activity Feed
When enabled, an Activity tab appears in the add-in pane showing the user engagement data for their sent emails, including opens and link clicks. This setting requires a compatible Opensense engagement tier. Contact help@opensense.com or your account manager to confirm whether your plan includes this feature. Learn more here.
Aliases and shared inboxes
The behavior of signatures when a user switches the From address is controlled by three settings: From Switching, Merge User Fields, and Ignore Empty Fields. The combination you choose depends on whether you want the signature to reflect the primary user's identity or the switched account's identity.
From Switching OFF
The signature always displays the primary user's information, regardless of which From address is selected. This is the simplest configuration and the right choice when employees should send from all accounts using their own personal signature.
For plaintext block deployments, the fields on the other account must be unlocked to allow the primary user's data to populate. For visual preview deployments, the primary user's data appears regardless of field lock state because signature insertion happens client-side.
Scenario: You want the primary user's information to always appear in the signature when sending from a shared inbox.
From Switching ON
When a user switches the From address, the signature template updates to display the data associated with the selected account. The primary user's data is not used. Use this setting when shared or alias accounts have their own distinct signature requirements.
Scenario: You want a shared inbox like
support@company.comto display its own signature data rather than the sending user's personal details.
From Switching ON + Merge User Fields ON + Ignore Empty Fields ON
This is the recommended configuration when you want data to merge from the primary user into alias or shared account signatures. When switching to an account that is missing certain data fields or has empty field values, the primary user's information is used as a fallback to populate those fields.
For merging to work correctly, the fields you want to merge must either not exist on the switched account or have their values cleared. If a field has data on the alias account, it will not be overwritten even with Merge User Fields enabled. This is why Ignore Empty Fields should always be enabled alongside Merge User Fields -- it ensures the primary user's data only fills fields that are genuinely empty, not fields that already have values.
For shared inbox configurations where the signature should show the primary user's name and title but retain the shared inbox's own email address and other data, the following setup is required:
Unlock the fields you want merged on the shared account (for example, name and title).
Break the directory sync on those fields so they accept the merged values rather than pulling from the shared account's directory data.
Clear the existing values for fields that should pull from the primary user.
Keep fields that should retain the shared account's own values locked with the correct data in place.
Scenario: A shared inbox like
help@company.comshould show the sending user's name and title, but the email address in the signature should always reflect the shared inbox address.