---
title: "Comparing Outlook Add-in deployment methods"
slug: "deployment-mode-comparison"
description: "Compare Stamping, Plain Text Block, and Visual Preview for the Opensense Outlook Add-in: compliance, compose visibility, targeting, analytics, and encryption."
updated: 2026-08-21T18:17:59.000Z
canonical: "https://help.opensense.com/docs/deployment-mode-comparison"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.opensense.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Comparing Outlook Add-in deployment methods

## Overview

The Opensense Outlook Add-in supports three deployment methods: Stamping, Plain Text Block, and Visual Preview. Each method determines how and where signatures are applied. Each makes different tradeoffs across compliance control, compose visibility, analytics depth, and banner targeting. Choose the right method before you configure the add-in, to save significant rework.

## Quick decision guide

<ul class="kb-test-methods" role="list">
  <li>
    <span class="kb-test-methods__label">Server-side, after send</span>
    <strong>Stamping</strong>
    <p>Choose it if compliance and full server-side control are the priority, and you don't need the signature visible while composing.</p>
  </li>
  <li>
    <span class="kb-test-methods__label">Recommended</span>
    <strong>Plain Text Block</strong>
    <p>Choose it if you need both server-side compliance control and a signature preview while composing. This is the recommended method for most deployments.</p>
  </li>
  <li>
    <span class="kb-test-methods__label">Client-side, in compose</span>
    <strong>Visual Preview</strong>
    <p>Choose it if users need to see and interact with their signature before sending, or if your organization sends encrypted emails that can't be processed server-side.</p>
  </li>
</ul>

## Comparison table

<div class="kb-deployment-compare kb-deployment-compare--plain">
  <div class="kb-deployment-compare__viewport" role="region" aria-label="Outlook Add-in deployment methods compared" tabindex="0">
    <table>
      <colgroup><col class="kb-deployment-compare__feature-col"></colgroup>
      <thead>
        <tr>
          <th scope="col">Capability</th>
          <th scope="col"><a class="kb-deployment-compare__method" href="#stamping">Stamping</a></th>
          <th scope="col"><a class="kb-deployment-compare__method" href="#plain-text-block">Plain Text Block</a></th>
          <th scope="col"><a class="kb-deployment-compare__method" href="#visual-preview">Visual Preview</a></th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <th scope="row">Signature applied</th>
          <td>Server-side, after send</td>
          <td>Server-side, after send</td>
          <td>Client-side, in compose</td>
        </tr>
        <tr>
          <th scope="row">Compose visibility</th>
          <td>None. The add-in pane shows a preview of the recipient's signature.</td>
          <td>A token in compose. The add-in pane shows a preview of the recipient's signature.</td>
          <td>The full rendered signature in the compose window</td>
        </tr>
        <tr>
          <th scope="row">User can edit the signature before sending</th>
          <td>No</td>
          <td>No</td>
          <td>Yes</td>
        </tr>
        <tr>
          <th scope="row">Compliance enforcement</th>
          <td>Full</td>
          <td>Full</td>
          <td>Not enforced. User edits bypass Opensense.</td>
        </tr>
        <tr>
          <th scope="row">Banner targeting</th>
          <td>Recipient-based</td>
          <td>Recipient-based</td>
          <td>Sender-based only</td>
        </tr>
        <tr>
          <th scope="row">Analytics</th>
          <td>Advanced (views, clicks, video replays)</td>
          <td>Advanced (views, clicks, video replays)</td>
          <td>Basic (views and clicks only)</td>
        </tr>
        <tr>
          <th scope="row">Encrypted email support</th>
          <td><span class="kb-deployment-compare__mark is-no" title="No"><span class="sr-only">No</span></span></td>
          <td><span class="kb-deployment-compare__mark is-no" title="No"><span class="sr-only">No</span></span></td>
          <td><span class="kb-deployment-compare__mark is-yes" title="Yes"><span class="sr-only">Yes</span></span></td>
        </tr>
        <tr>
          <th scope="row">Mail flow rule required</th>
          <td>Yes</td>
          <td>Yes</td>
          <td>Optional (the rule handles unsigned emails)</td>
        </tr>
        <tr>
          <th scope="row">Custom Compose Fields</th>
          <td>Not compatible</td>
          <td>Compatible</td>
          <td>Compatible</td>
        </tr>
        <tr>
          <th scope="row">Mobile From switching</th>
          <td colspan="3">Not supported by any method (a Microsoft limitation)</td>
        </tr>
        <tr>
          <th scope="row">Best for</th>
          <td>Organizations that prioritize governance, with no compose visibility requirement</td>
          <td>Organizations that need compliance control, with employee signature awareness</td>
          <td>Organizations that prioritize the compose experience, or send encrypted email</td>
        </tr>
      </tbody>
    </table>
  </div>
</div>

## 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 Opensense's servers apply the signature, the sender can't change it.

:::tip[Best for]
Organizations where compliance and legal disclaimer enforcement take priority, and a signature in the compose window is not required.
:::

<div class="kb-pros-cons">
  <div class="kb-pros-cons__pros">
    <p class="kb-pros-cons__label" id="stamping-strengths">Strengths</p>
    <ul aria-labelledby="stamping-strengths">
      <li>Full compliance enforcement: signature content is always controlled centrally</li>
      <li>Recipient-based banner targeting and advanced analytics</li>
      <li>No changes to the compose window for users</li>
      <li>The add-in pane preview confirms what recipients will see</li>
    </ul>
  </div>
  <div class="kb-pros-cons__cons">
    <p class="kb-pros-cons__label" id="stamping-limitations">Limitations</p>
    <ul aria-labelledby="stamping-limitations">
      <li>No signature in the compose window. Users see the preview only when they open the add-in pane.</li>
      <li>Not compatible with Custom Compose Fields</li>
      <li>Can't apply signatures to encrypted outbound email</li>
    </ul>
  </div>
</div>

For edge cases, see [Expected behaviors in routed Outlook Add-in deployments](https://help.opensense.com/docs/clone-outlook-add-in-routed-key-behaviors-and-nuances).


## Plain Text Block

The Plain Text Block method inserts a `[[#]]` token into the compose window, and the add-in pane shows 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 preview confirms that a signature will be applied, without letting users edit it.

This is Opensense's patented approach, and the recommended method for most deployments.

:::tip[Best for]
Organizations that need server-side compliance control, and want employees to have signature awareness through the add-in pane. This method bridges the gap between Stamping and Visual Preview.
:::

<div class="kb-pros-cons">
  <div class="kb-pros-cons__pros">
    <p class="kb-pros-cons__label" id="plain-text-block-strengths">Strengths</p>
    <ul aria-labelledby="plain-text-block-strengths">
      <li>Full compliance enforcement: the signature is applied and controlled server-side</li>
      <li>The add-in pane preview shows users exactly what recipients will receive</li>
      <li>Recipient-based banner targeting and advanced analytics</li>
      <li>Compatible with Custom Compose Fields</li>
    </ul>
  </div>
  <div class="kb-pros-cons__cons">
    <p class="kb-pros-cons__label" id="plain-text-block-limitations">Limitations</p>
    <ul aria-labelledby="plain-text-block-limitations">
      <li>A mail flow rule is always required</li>
      <li>Can't apply signatures to encrypted outbound email</li>
      <li>The preview is in the add-in pane only. The compose window shows only the token.</li>
    </ul>
  </div>
</div>

For edge cases, see [Expected behaviors in routed Outlook Add-in deployments](https://help.opensense.com/docs/clone-outlook-add-in-routed-key-behaviors-and-nuances).

## Visual Preview

Visual Preview renders the full HTML signature client-side in the compose window. Users can see the signature and edit it manually before sending. Emails sent with a manually edited signature bypass Opensense's servers, so those changes are not tracked, blocked, or enforced.

:::tip[Best for]
Organizations where the compose experience takes priority over strict governance, or with encrypted email workflows where server-side processing is not possible.
:::

<div class="kb-pros-cons">
  <div class="kb-pros-cons__pros">
    <p class="kb-pros-cons__label" id="visual-preview-strengths">Strengths</p>
    <ul aria-labelledby="visual-preview-strengths">
      <li>Full compose visibility: users see the rendered signature as it will appear to recipients</li>
      <li>The only method that supports encrypted outbound email (sensitivity labels)</li>
      <li>Compatible with Custom Compose Fields</li>
    </ul>
  </div>
  <div class="kb-pros-cons__cons">
    <p class="kb-pros-cons__label" id="visual-preview-limitations">Limitations</p>
    <ul aria-labelledby="visual-preview-limitations">
      <li>Users can edit the signature before sending, so compliance can't be enforced</li>
      <li>Banner targeting is sender-based only, with no recipient-based targeting</li>
      <li>Analytics are basic (views and clicks), with no advanced analytics or video replays</li>
    </ul>
  </div>
</div>

For details, see [Outlook Add-in Visual Preview capabilities and tradeoffs](https://help.opensense.com/docs/outlook-add-in-visual-preview-capabilities-and-tradeoffs).

## Making your decision

The right method depends on how your organization weighs compliance control against the compose experience, and whether advanced marketing capabilities are a priority. Most organizations with active governance or legal requirements should default to Plain Text 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 your organization's culture requires employees to see and own their signature before sending.

Find your situation in each factor to narrow down the right method.

<dl class="kb-insights-summary kb-decision-factors">
  <div>
    <dt>Compliance requirements</dt>
    <dd><ul role="list">
      <li><span>Legal disclaimers or brand standards must be enforced on every email, without exception</span><span><a href="#stamping">Stamping</a> or <a href="#plain-text-block">Plain Text Block</a>, the only viable options</span></li>
    </ul></dd>
  </div>
  <div>
    <dt>Marketing and analytics</dt>
    <dd><ul role="list">
      <li><span>Recipient-based banner targeting and advanced analytics</span><span>A server-side method: <a href="#stamping">Stamping</a> or <a href="#plain-text-block">Plain Text Block</a></span></li>
      <li><span>Sender-based targeting</span><span><a href="#visual-preview">Visual Preview</a> supports this only</span></li>
    </ul></dd>
  </div>
  <div>
    <dt>Encrypted email</dt>
    <dd><ul role="list">
      <li><span>Microsoft sensitivity labels, or other encryption that processes before mail flow rules evaluate</span><span><a href="#visual-preview">Visual Preview</a>, the only method that will apply a signature</span></li>
    </ul></dd>
  </div>
  <div>
    <dt>User experience</dt>
    <dd><ul role="list">
      <li><span>Employees need to see their signature before sending, for example, to verify personalized fields</span><span><a href="#plain-text-block">Plain Text Block</a>, which gives that awareness without sacrificing compliance control</span></li>
    </ul></dd>
  </div>
</dl>

You can combine methods. Some organizations use Visual Preview for encrypted email workflows, and Plain Text Block for standard outbound email. Contact [help@opensense.com](mailto:help@opensense.com) if you need guidance on a hybrid configuration.

:::note[Still unsure which method fits?]
Reach out to your Opensense account manager or [help@opensense.com](mailto:help@opensense.com). They can walk through your compliance and marketing requirements, and recommend a configuration.
:::


## What's next

- [Outlook Add-in overview](https://help.opensense.com/docs/outlook-add-in-overview-1)
- [Outlook Add-in supported environments](https://help.opensense.com/docs/supported-environments-for-the-opensense-outlook-add-in)
- [Configuring the Outlook Add-in in Domain Settings](https://help.opensense.com/docs/clone-outlook-add-in-domain-settings-with-scenarios-and-best-practices)