This is a div block with a Webflow interaction that will be triggered when the heading is in the view.
- Outlook cannot override a signature it never applies. Stamping and Plain Text Block run on the server, after send, through an Exchange Online mail flow rule.
- Visual Preview and an add-in-only deployment run in the client. What the user sees in compose, the user can change, and a client without the add-in sends unsigned.
- Two locks with two jobs: field locks decide what Opensense writes into the signature, and a GPO or Intune policy stops Outlook offering a competing local one.
- The gap to plan for: if security will not approve a mail flow rule, the add-in is the path, and it cannot promise that Outlook never wins.
- Verify with a deliberately bad paste from a pilot user, then read the received HTML. Repeat after every template change.
Outlook cannot override a signature it never applies. Deploy the company signature server-side, through an Exchange Online mail flow rule that hands each message to Opensense after the user clicks send, and whatever anyone pasted into Outlook Options stops mattering. That is the whole answer. The rest of this page is the setup, the verification, and the one tenant where the answer is not available.
Where the override actually happens
Outlook gives every user a signature editor under Options, and that editor is the failure. Someone pastes last quarter’s Word lockup over the managed block. Someone else swaps the directory title for a stylized PNG of the same words, which reads fine on a laptop and says nothing to a screen reader. None of it surfaces in a brand review, because brand reviews look at the template. It surfaces when a recipient’s screenshot lands in a support queue.
So the problem is rarely the HTML. The same template, with the same alt text and the same directory fields, either survives every send or survives none of them, and which one you get is decided by the deploy path. That decision is usually made by whoever connected the tenant, on technical grounds, before anyone asked about accessibility.
The policy side of this, ADA Title II dates, WCAG criteria, what counsel has to decide, lives on accessible email signatures for Microsoft 365 and Google Workspace. This page is the operational half: how to deploy so the markup you approved is the markup that leaves.
Four ways Opensense can apply a signature, and which ones Outlook can beat
Opensense documents four deployment methods for Microsoft 365. Two run on the server. Two run in the client, and a client-side signature is, by definition, one the client can change.
| Method | Where it runs | What the user sees while composing | Can Outlook Options replace it? |
|---|---|---|---|
| Stamping | Server, after send | Nothing | No |
| Plain Text Block | Server, after send | A text placeholder | No |
| Visual Preview | Client, in compose | The full signature | Yes |
| Outlook add-in on its own | Client, in compose | The full signature, with the unlocked fields editable | Partly. Mail from a client without the add-in goes out unsigned |
Stamping and Plain Text Block both depend on an Exchange Online mail flow rule. The rule routes outbound mail through Opensense, the managed HTML is applied, and the message continues to the recipient. The help center’s own guide, Choose a deployment method, recommends Plain Text Block for most tenants: people get a placeholder in compose, and IT keeps server control. Stamping shows nothing in compose at all, which is fine until someone decides the signature must be missing and adds their own.
Visual Preview is the one people like best in a demo. Full signature, right there, looks finished. It is also the one that can be edited, and if a disclaimer or an accessibility requirement rides in that signature, the edit path is your gap. Keep it for teams that need to see the block and can live with that.
The tenant where the promise is not available
Some security teams will not approve routing outbound mail through a third party, and a mail flow rule is exactly that. If yours says no, the server-side methods are off the table and the Outlook add-in is the deployment path. Opensense says this plainly on the Office 365 page: on the add-in path, mail sent from a client where the add-in cannot run leaves without the managed signature.
Write that into the project decision rather than discovering it in an audit. The add-in path still works, and plenty of tenants run it deliberately. What it cannot do is promise that Outlook never wins.
You can also run both, mail flow for enforcement and the add-in for compose preview and the fields you leave editable, which is where a lot of Microsoft 365 tenants with a mixed client population end up.
Step 1. Audit what Outlook is sending today
Do not redesign yet. Ask a handful of people across departments to send a normal message to a mailbox you control, from each client in use:
- Outlook for Windows, classic and new if both exist
- Outlook for Mac
- Outlook on the web
- Outlook Mobile on iOS and on Android
- Any shared mailbox that matters
Then read the received HTML, not the rendered preview. View source, or open the message in a browser inspector, and check four things:
- Does the logo carry a meaningful
alt, and are spacer imagesalt=""? - Are the name, title, phone, and URL real text, or one image?
- Is there a second, personal signature stacked above or below the company block?
- Is there a plain-text part at all?
Record sender, client, and defect. That spreadsheet is the baseline you will test against after deploy. It usually also turns up empty phone fields and stale titles, which is a directory problem rather than a signature problem, and cleaning Entra ID before go-live is most of the real work.
Step 2. Build the template so the markup survives the trip
Templates in Opensense are HTML and CSS, edited in the signature editor. There is no dedicated alt-text property sheet, no contrast checker, and no WCAG conformance mode. The accessibility markup lives in the HTML IT saves, which is the point: once it is in the locked template, nobody downstream has to remember it.
For the template that will be locked:
- Contact lines pulled from Entra ID or Google Directory as text. A person’s name should never exist only as an image.
- A meaningful
alton the logo, and an emptyalton spacers so screen readers skip them. - A text alternative on any banner that carries an offer or a call to action (WCAG 2.1 SC 1.1.1). Static creative beats a looping GIF, which recipients cannot pause.
- A filled plain-text block alongside the HTML block, including on the reply signature.
- Colors you intend to keep, checked in the editor’s Dark Mode Preview after every change.
Empty directory attributes render as blanks. Fix the attribute, not the template.
Step 3. Lock the fields, then take the Outlook editor away
Two controls, and they do different jobs.
Field locks decide what Opensense will put in the signature. Fields are unlocked by default. You can lock them per user in the platform, or in bulk by appending -locked to a field name in the sync CSV, so a column called name-locked overrides whatever the user typed. When a message is sent, Opensense fills each field in this order: locked fields in Compliance, then the user’s own Signature Block data, then unlocked fields in Compliance (Locking and unlocking compliance fields). Lock anything you are not willing to let drift, starting with legal lines and the required contact fields. Leave editable only what you actually want people to edit, such as pronouns or a second phone.
Endpoint policy decides whether Outlook still offers a competing local signature. Even on a server-side deploy, a leftover local signature stacks under the managed one and generates the ticket “why do I have two signatures.” On domain-joined machines, the Group Policy setting is called “Do not allow signatures for e-mail messages” (GPO steps). Cloud-managed Windows endpoints get the same result through Intune. Neither replaces the mail flow rule. They reduce the noise. The rule does the enforcing.
Step 4. Deploy, scope, and wait out the add-in
Most organizations finish the first deploy in about 45 minutes: connect the tenant, authenticate with Entra ID, save the first template, roll out. The mail flow rule is created as part of that if security approved it. If you also want the add-in, it is deployed through the Microsoft 365 admin center and can take up to 72 hours to reach user profiles, so plan the pilot window around that rather than around the 45 minutes.
Scope by whatever directory attribute you already maintain: department, region, group. One template set can cover the tenant while rules target the segments. And tell people what is happening. On Stamping in particular, compose shows nothing, and an unbriefed user will assume the signature is missing and paste a backup.
On-premises Exchange is a different path, with a transport agent and no add-in support. If that is your estate, this article is not your runbook, and your Opensense implementation contact is.
Step 5. Prove it with a deliberately awful signature
One happy-path send from your own laptop proves nothing. Pick a user in scope, have them paste the worst signature you can think of into Outlook Options, neon Comic Sans and a logo with no alt, and send to your test inbox. On the server-side path the recipient gets the managed HTML and the paste is gone. Repeat from Outlook on the web and from Outlook Mobile.
Then read the source of what arrived, against the same four checks as the audit. If the tenant is add-in-only, also send from a client without the add-in and confirm the message went out unsigned. That is the documented gap, and you want it documented in your own results rather than discovered later.
Re-run this after every logo change, disclaimer edit, or banner campaign that touches the signature HTML.
Google Workspace, briefly
Same principle, different pipes. On Google Workspace the server-side path is the Gmail API, the compose path is the Google Workspace Add-on, and the fields come from Google Directory. The Workspace page has that stack’s detail. This page stays with Outlook because “pasted into Outlook Options” is the named failure.
What it costs, and what it does not include
Pricing is the same as opensense.com/pricing, and there is no accessibility SKU.
| Plan | Per user per month |
|---|---|
| Signature | $1 |
| Pipeline | $3 |
| Complete | $5 |
Every plan carries a $500 per month minimum plus a service plan. Microsoft 365 GCC High tenants pay $2 per user per month more on any plan and have extra setup steps, so the 45-minute figure above does not apply to them. Security documentation, including the SOC 2 Type II report, is on opensense.com/security.
Locking deployment does not make anyone ADA-compliant. Opensense signatures are not certified against WCAG or Section 508, ADA Title II covers public entities rather than every private-sector email, and counsel owns the conformance question. What locking does is narrower and more useful: the markup your accessibility program approved is the markup that leaves, on every send, from every client that routes through the tenant.
FAQs about deploying signatures Outlook cannot override
Can Outlook users still override a company email signature?
Not on the server-side path. With Stamping or Plain Text Block, Exchange Online mail flow hands the message to Opensense after send and the managed HTML is applied, so a block pasted into Outlook Options does not replace it. On Visual Preview or an add-in-only deployment, users can edit what they see in compose, and clients without the add-in send unsigned.
What is the difference between Stamping and Plain Text Block?
Both are applied after send. Stamping shows nothing in compose. Plain Text Block puts a text placeholder in compose that is transformed into the full signature on the way out. The help center recommends Plain Text Block for most tenants because the placeholder stops people from assuming the signature is missing.
What if security will not approve a transport rule?
Deploy the Outlook add-in, disable native Outlook signatures with GPO or Intune where you can, keep unlocked fields to a minimum, and record that mail from clients without the add-in goes out unsigned. Revisit the rule if “cannot override” becomes a hard compliance requirement.
How do we keep alt text from being stripped?
Put it in the central template, populate the contact lines from the directory, and deploy server-side. The alt attribute lives on the img tag in the HTML IT edits, and there is no separate property sheet for it. Once the template is what leaves the tenant, no user action can remove it.
Should we disable native Outlook signatures if we already deploy server-side?
Yes. The managed signature is applied after send either way, but a leftover local signature stacks under it and produces duplicate-footer tickets. GPO on domain-joined machines, Intune on cloud-managed ones.
How long does Microsoft 365 setup take?
About 45 minutes to the first deployed template. The Outlook add-in, if you use it, can take up to 72 hours to appear for users after it is deployed through the Microsoft 365 admin center.
Does locking deployment make us ADA-compliant?
No. It makes the approved markup survive. Conformance is decided by your accessibility program and counsel, and Opensense holds no WCAG or Section 508 certification. The legal framing is on accessible email signatures.
Run the pilot before the rebrand
The cheapest time to find out Outlook is winning is on a pilot group of ten, with a test inbox and a deliberately bad paste, not after marketing ships a new logo to two thousand people. Book a demo to pick Stamping, Plain Text Block, or the add-in for your tenant and run that pilot, or start with the Office 365 deployment page.
