Overview
The Opensense Outlook Add-in supports three deployment methods: stamping, plaintext block, and visual preview. Each method determines how and where signatures are applied, and each makes different tradeoffs across compliance control, compose visibility, analytics depth, and banner targeting. Choosing the right method before configuration saves significant rework.
Quick decision guide
Choose stamping if compliance and full server-side control are the priority, and compose-time visibility is not required.
Choose plaintext block if you need both server-side compliance control and a signature preview in compose — this is the recommended method for most deployments.
Choose visual preview if users need to see and interact with their signature before sending, or if your organization sends encrypted emails that cannot be processed server-side.
Comparison table
Capability | Stamping | Plaintext Block | Visual Preview |
|---|---|---|---|
Signature applied | Server-side (post-send) | Server-side (post-send) | Client-side (in compose) |
Compose visibility | None — add-in pane shows preview of recipient's signature | Token in compose — add-in pane shows preview of recipient's signature | Full rendered signature in compose window |
User can edit signature before send | No | No | Yes |
Compliance enforcement | Full | Full | Not enforced — user edits bypass Opensense |
Banner targeting | Recipient-based | Recipient-based | Sender-based only |
Analytics | Advanced (views, clicks, video replays) | Advanced (views, clicks, video replays) | Basic (views and clicks only) |
Encrypted email support | No | No | Yes |
Mail flow rule required | Yes | Yes | Optional (rule handles unsigned emails) |
Custom Compose Fields | Not compatible | Compatible | Compatible |
Mobile From switching | Not supported (Microsoft limitation) | Not supported (Microsoft limitation) | Not supported (Microsoft limitation) |
Best for | Organizations prioritizing governance with no compose visibility requirement | Organizations that need compliance control with employee signature awareness | Organizations prioritizing compose experience, or those sending encrypted email |
Stamping
Stamping removes any locally drafted signature from the outbound email and applies the full HTML signature server-side after the message is sent. Nothing is inserted into the compose window. Users can open the add-in pane to see a preview of the signature recipients will receive. Because the signature is applied entirely by Opensense servers, it cannot be altered by the sender.
Strengths:
Full compliance enforcement — signature content is always controlled centrally
Recipient-based banner targeting and advanced analytics
No changes to the compose window for users
Add-in pane preview gives users confirmation of what recipients will see
Limitations:
No signature in the compose window — users see the preview only by opening the add-in pane
Not compatible with Custom Compose Fields
Cannot apply signatures to encrypted outbound email
Best for: Organizations where compliance and legal disclaimer enforcement take priority, and where a compose-window signature is not required.
Learn more: Outlook Add-in Routed Key Behaviors
Plaintext block
The plaintext block method inserts a [[#]] token into the compose window. The add-in pane displays a non-clickable preview of what recipients will see. The mail flow rule detects the token, routes the email to Opensense, and applies the full HTML signature server-side. The add-in pane preview gives users confirmation that a signature will be applied without granting them the ability to edit it.
This is Opensense's patented approach and is the recommended method for most deployments.
Strengths:
Full compliance enforcement — signature is applied and controlled server-side
Add-in pane preview shows users exactly what recipients will receive
Recipient-based banner targeting and advanced analytics
Compatible with Custom Compose Fields
Limitations:
Mail flow rule is always required
Cannot apply signatures to encrypted outbound email
Preview is in the add-in pane only — the compose window shows only the token
Best for: Organizations that need server-side compliance control and want employees to have signature awareness via the add-in pane. This method bridges the gap between stamping and visual preview.
Learn more: Outlook Add-in Routed Key Behaviors
Visual preview
Visual preview renders the full HTML signature client-side in the compose window. Users can see and manually edit the signature before sending. Emails sent with a manually edited signature bypass Opensense servers — those changes are not tracked, blocked, or enforced.
Strengths:
Full compose visibility — users see the rendered signature as it will appear to recipients
The only method that supports encrypted outbound email (sensitivity labels)
Compatible with Custom Compose Fields
Limitations:
Users can edit the signature before sending — compliance cannot be enforced
Banner targeting is sender-based only — no recipient-based targeting
Analytics are basic (views and clicks) — no advanced analytics or video replays
Best for: Organizations where compose experience takes priority over strict governance, or those with encrypted email workflows where server-side processing is not possible.
Learn more: Outlook Add-in Visual Preview: Capabilities and Tradeoffs
Making your decision
The right method depends on how your organization weighs compliance control against compose experience, and whether advanced marketing capabilities are a priority. Most organizations with active governance or legal requirements should default to plaintext block — it delivers server-side control with the compose visibility that stamping lacks. Visual preview is the correct choice when encrypted email is in scope, or when organizational culture requires employees to see and own their signature before sending.
Consider these factors:
Compliance requirements: If legal disclaimers or brand standards must be enforced on every email without exception, stamping or plaintext block are the only viable options.
Marketing and analytics: Recipient-based banner targeting and advanced analytics require a server-side method. Visual preview supports sender-based targeting only.
Encrypted email: If your organization uses Microsoft sensitivity labels or other encryption that processes before mail flow rules evaluate, visual preview is the only method that will apply a signature.
User experience: If employees need to see their signature before sending — for example, to verify personalized fields — plaintext block provides that awareness without sacrificing compliance control.
Methods can be combined. Some organizations use visual preview for encrypted email workflows while using plaintext block for standard outbound email. Contact help@opensense.com if you need guidance on a hybrid configuration.