Managing Outlook signatures across Microsoft 365

An email signature is a few lines of HTML, so it ought to be the easiest thing in a tenant to standardise. In practice it is one of the last things most organisations get under control, because Outlook stores signatures in several different places, users can edit them, and the mechanisms Microsoft gives you for applying one centrally each have a gap. This guide explains the gaps, then compares the options honestly, including the one Sigil uses.

Why Outlook signatures are hard to manage centrally

Roaming signatures and the new Outlook for Windows

Classic Outlook for Windows keeps each signature as a set of files on the PC (an .htm, an .rtf and a .txt, plus a folder for images). That is why the traditional answer was a login script or Group Policy that dropped files into that folder. The new Outlook for Windows stores signatures in the mailbox instead, in the cloud, and there is no supported administrative way to push a signature into that store; Microsoft’s own guidance for the new Outlook is that users set their signature themselves or that you use a third-party tool (Microsoft Learn: map classic Outlook policies to new Outlook).

Classic Outlook gained the same cloud-backed “roaming signatures” feature, which syncs signatures between installs through the mailbox. Tenants can hold it back with Set-OrganizationConfig -PostponeRoamingSignaturesUntilLater (Microsoft Learn: Set-OrganizationConfig), and several server-side signature vendors ask you to disable roaming signatures so their own stamping is not duplicated. The practical consequence: a file-drop script that worked for a decade quietly stops covering anyone who has moved to the new Outlook or whose classic Outlook now roams its signatures.

Signatures on Outlook for iOS and Android

Outlook mobile keeps its own per-account signature setting, which defaults to “Get Outlook for iOS” or similar and which nothing on the desktop side reaches. Until recently the only way to control it was a server-side rule. Microsoft now supports event-based add-ins on Outlook for iOS and Android, including the event that fires when a new message is composed, so a centrally deployed add-in can set the signature on the phone too (Microsoft Learn: event-based activation in Outlook mobile add-ins). There are limits on mobile worth knowing: an event-based add-in gets 60 seconds to run, only one runs at a time, and the compose event does not fire when a message is started from the iOS Share sheet (Microsoft Learn: behaviour and limitations).

Users editing their own signatures

Whatever you push, a user can open Settings and change it, add a quotation, or paste in last year’s logo. You can stop Outlook on the web and the new Outlook from offering the signature editor at all with an Outlook on the web mailbox policy (Set-OwaMailboxPolicy -SignaturesEnabled $false; Microsoft Learn: policy management in new Outlook), and classic Outlook has the equivalent Group Policy setting. That removes the editor. It does not put a correct signature in its place, so blocking edits is only half of a solution.

Your options for central signatures

Exchange Online mail flow rules

The built-in option. A mail flow rule (transport rule) with the “apply a disclaimer” action appends or prepends an HTML block to messages as they pass through Exchange Online, and it can merge directory attributes with tokens such as %%DisplayName%% and %%Title%% (Microsoft Learn: organisation-wide disclaimers, signatures, footers or headers). It is free and it covers every client, including phones and printers. Its limits are structural rather than cosmetic:

• It goes at the bottom of the whole message, not under your reply. The disclaimer is appended to the end of the body, so in a conversation it lands beneath the quoted thread. Microsoft’s own guidance is to add an exception so the block is only added once per conversation, which means it is only under the first message.
• Images are external and often blocked. The block can contain an <img> pointing at a web URL, and Outlook blocks external content by default; there is no way to embed the logo inline.
• Plain text loses the design. HTML in a disclaimer is ignored when the rule adds it to a plain-text message, and the text is capped at 5,000 characters including tags (Microsoft Learn: mail flow rule actions).
• The sender never sees it. The signature is added after sending, so it is not in the compose window and not in Sent Items as the sender wrote it.
• Signed and encrypted mail needs a fallback. When the body cannot be altered the rule has to wrap the message as an attachment, ignore it, or reject it.

Server-side signature services

Products such as Exclaimer and CodeTwo offer a server-side mode that does what the transport rule does, with a proper designer, better image handling and reply-aware placement. In Microsoft 365 they work by routing outbound mail through the vendor’s service and back, using connectors and mail flow rules (Exclaimer: server-side vs client-side; CodeTwo: how the signature modes work). The strength is coverage: every client and device, because the signature is added after the message leaves Outlook. The costs are the same as any mail-flow change: the vendor becomes part of your delivery path, senders cannot see the final signature before it goes, and the connectors have to be configured, monitored and one day removed.

Client-side Outlook add-ins

An Outlook add-in that Microsoft activates when a message is composed, and that inserts the signature into the compose window using the Office JavaScript API. Microsoft supports this on Outlook on the web, classic and new Outlook for Windows, the new Outlook for Mac, and Outlook for iOS and Android (Microsoft Learn: activate add-ins with events). It is deployed once, centrally, through Integrated apps in the Microsoft 365 admin centre, and Microsoft says a new deployment can take up to 24 hours to appear for every user (Microsoft Learn: centralised deployment FAQ). The sender sees the real signature as they write. Nothing touches mail flow. The gap is that it only runs where Outlook runs the add-in: a message sent from Apple Mail, a scanner or a line-of-business application gets nothing.

Client-side vs server-side: the trade-offs

Some vendors offer both modes at once (client-side where the add-in runs, server-side for everything else). That closes the coverage gap at the price of running both mechanisms and their two sets of rules.

Signatures in replies and forwards

The compose event that add-ins hook into fires for new messages, replies, reply-all and forwards alike, but not when a saved draft is reopened (Microsoft Learn: supported events). A good add-in uses that to apply a shorter signature on replies, which is what most organisations want: the full block once, then name and title on the back-and-forth. A transport rule cannot tell a reply from a new message unless you build the distinction into its conditions, and even then it appends at the bottom of the thread.

Signatures for shared mailboxes and send-as

Two things have to be true for a shared mailbox to get the right signature from an add-in. Outlook has to run the add-in in that mailbox at all, which needs the add-in to declare shared-folder support and the client to support requirement set 1.13; Microsoft documents this for Outlook on the web, the new and classic Outlook for Windows and Outlook for Mac, and not for Android or iOS (Microsoft Learn: shared folders and shared mailbox scenarios). And the add-in has to notice when the sender switches the From field, which Microsoft exposes as a separate event (Microsoft Learn: OnMessageFromChanged). Sending as a Microsoft 365 Group is the awkward case: Outlook does not run add-ins in a group’s own space, so the message must be started from the person’s mailbox with the From field changed. Server-side mechanisms sidestep all of this because they act on the sender address after the fact.

Keeping directory data clean for better signatures

Every central mechanism, including a plain transport rule, fills the signature from the directory. The signature is therefore only as good as Entra ID. Things worth fixing before you roll anything out:

• Job titles. Decide on capitalisation and abbreviations once. “Snr Mgr” and “Senior Manager” will both appear in mail.
• Phone numbers. Pick one format (E.164 or a national one) and apply it to every mobile and business phone.
• Department and office. These are usually what a template is assigned by. Empty values mean the default template, which may be wrong.
• Addresses. Street, city and postcode are separate attributes; fill all of them or none, and let the template hide what is empty.
• Extension attributes. If you need something the schema does not have, such as a regulatory registration number, put it in an extension attribute rather than in the notes field.
• Synced tenants. If users sync from on-premises Active Directory, correct the data there. A cloud-side edit will be overwritten.

A tool that reports which attributes are actually populated per mailbox turns this from a guess into a list.

How Sigil handles this

Sigil is a client-side Outlook add-in only. It runs on the clients Microsoft supports for event-based activation, is deployed once through Integrated apps, personalises from Microsoft Graph with read-only permissions, applies a shorter signature to replies and forwards, switches signature when the From field changes, and logs every render and apply so the portal can show which mailboxes have applied their signature and which never have. It has no server-side mode, so mail from non-Outlook clients is not covered; that trade-off is spelled out on the supported clients table. The homepage shows how a deployment works end to end, and the deployment guide walks through it step by step. Moving from a server-side product? See migrating from Exclaimer or migrating from CodeTwo.

Microsoft behaviour described here was checked against the linked Microsoft Learn pages on 15 September 2026. Outlook changes often; if a statement no longer matches what you see, tell us and we will correct it.