Deploy the Outlook add-in

This is the step that makes signatures appear. It is also the step most likely to be misdiagnosed, because propagation is slow enough that a correct deployment looks broken for the first day.

Administrator deployment is required

Event-based add-ins only auto-launch when an administrator deploys them. If somebody installs the Sigil add-in themselves from their own Outlook, it will not fire on compose and they will get no automatic signature.

There is no way around this. It is a Microsoft platform rule, not a Sigil restriction.

Deploy from the Microsoft Marketplace

Sigil is listed on the Microsoft Marketplace as Sigil by Tophhie Cloud, for every Outlook client including mobile. Deploying it from there is the supported way to install it.

1. Signed in as a Microsoft 365 administrator, open Sigil on the Microsoft Marketplace and choose Get it now. You can also start in the Microsoft 365 admin centre: go to Settings, then Integrated apps, choose Get apps and search for Sigil.
2. Choose who gets it. Start with a pilot group rather than the whole organisation.
3. Accept the permissions request and finish the deployment.

The same link is on the Getting started checklist in the portal.

It is the same add-in for every organisation. It is multi-tenant and works out which organisation somebody belongs to from their sign-in, so there is nothing tenant-specific to configure and nothing to keep secret.

The publisher name

Integrated apps shows the add-in as “Sigil by Tophhie Cloud”, published by Tophhie Cloud Ltd. That matches the privacy policy, the terms, the data processing agreement and your invoices, so a security review comparing the publisher against the contracting entity finds the same company on both.

It has not always. Until August 2026 the manifest named the sole trader Sigil traded as before the company was incorporated, and a review that stopped on the difference was stopping on something real. The correction is in the manifest now.

A Marketplace deployment shows the corrected name. An organisation that uploaded the manifest as a custom app before then sees it only once an administrator updates the custom app, because a custom app is not self-updating. If yours still shows the old name, that is what it is telling you, and the update carries a fresh consent prompt like any other manifest change. See compliance for the company details in full.

Wait for propagation

Allow 6 to 72 hours before treating a missing add-in as a fault. Nothing you do speeds this up, and it is normal for the add-in to appear for some people well before others.

While you wait, the Getting started checklist tracks this step honestly: it only marks the add-in as deployed once Sigil has actually heard from the add-in in your tenant. It is not a checkbox you tick. The step after it, Check your signature in Outlook, goes further and waits for the add-in to report that it applied a signature.

Pilot first

Pick ten to twenty people across more than one department, and across more than one client if you can. Somebody on Outlook for Windows, somebody on Mac, somebody who lives in Outlook on the web, and somebody who sends from a phone will between them surface most of what a rollout can surface.

Ask them to check new messages, replies and forwards. If anyone uses a shared mailbox, ask them to send from it, because that path goes through OnMessageFromChanged rather than OnNewMessageCompose. Include somebody who opens a shared mailbox as an account of its own rather than as a folder if you have one, since Outlook treats that as a different case entirely. See where the add-in runs in a shared mailbox.

Then look at Activity. You want to see signature requests arriving and apply outcomes succeeding.

1. Open Activity in the portal sidebar.
2. In the By mailbox table, find each pilot’s mailbox. Outcome should read Applied, and the Add-in column should show the add-in’s manifest version.
3. Ask anybody missing from the table to start a new message and choose My signature on the ribbon, on a computer. Outlook on a phone has no My signature button. The pane says why nothing was applied.

Go tenant-wide

Once the pilot is clean, widen the assignment in Integrated apps to the whole organisation or to the groups you intend to cover. Allow the propagation window again.

Watch the never-applied list in Activity over the following week. It cross-references your directory, so it lists mailboxes that have never had a signature applied rather than only reporting on the ones that have.

1. In the Microsoft 365 admin centre go to Settings, then Integrated apps.
2. Open Sigil by Tophhie Cloud and widen the assignment to the groups you intend to cover, or to Entire organisation.
3. Allow 6 to 72 hours.
4. Open Activity in the portal sidebar and watch the Never applied count in the Signature adoption card. Export mailboxes (CSV) lists which they are.

What needs a redeploy, and what does not

Almost everything the manifest points at is a URL, so most changes never touch it.

Change	New add-in version needed?
Signature templates, images, banners, footers	No. Published from the portal, live in seconds
Add-in code and icons	No. Outlook picks up new code within a compose or two, and caches icons, so allow a restart
New buttons inside the pane, such as “Edit my details”	No. The pane is add-in code
Hostnames, support URL, permissions, events, requirement set	Yes, and admin consent again

The practical version: your day-to-day work as an administrator never requires a redeploy. Only a change to the add-in’s declared shape does, and those are made by Tophhie Cloud rather than by you. A Marketplace deployment receives them from Microsoft without you uploading anything.

New add-in code arrives without anybody being kept waiting for it. Outlook uses the copy it already has and fetches the newer one in the background, so a client holding an older copy writes one more message with it and has the new code from then on. The alternative would put a download in front of every message somebody starts, which is a worse trade than one message written with the previous code.

When a manifest change does happen

Tophhie Cloud publishes a new version to the Marketplace, and Microsoft rolls it out to organisations that deployed from there. You do not upload anything.

One rule still reaches you. Any manifest change to an admin-deployed event-based add-in requires admin consent again, and users are blocked from the add-in until it is granted. Give the consent as soon as the admin centre asks for it.

If you uploaded the manifest as a custom app

Before Sigil was on the Marketplace, organisations deployed it by uploading the manifest as a custom app. Those deployments keep working. The difference is that a custom app does not update itself: Microsoft took its own copy at upload time, and updating remains an explicit administrator action, either through the admin centre or with Set-OrganizationAddIn.

The portal tells you when a newer manifest is worth taking, in Activity, and which manifest version you are on covers what it shows.

The manifest itself changes rarely. It names the add-in, the events it listens for and where its files live, and none of those move when Sigil’s own features change. Most releases reach you without a manifest at all.

Which manifest version you are on

Because a custom app upload is a copy, an organisation can sit on a manifest from months ago without noticing. The add-in’s own code is not the problem: everything the manifest points at is a fixed URL, so every client runs the current code whatever manifest it was installed from. What an old manifest is missing is exactly the part only a manifest can declare, such as shared mailbox support, and the code cannot see that it is missing.

So the add-in reports which manifest it was installed from, on the same beacon that reports whether the signature applied, and Activity shows you the answer. When any mailbox that has applied a signature in the last 30 days is on an older manifest than the one Sigil is serving, the view carries a notice naming the manifest version Sigil now serves and how many mailboxes are behind, with an Update button that opens the steps and the manifest link to re-upload. The per-mailbox table has an Add-in column with each mailbox’s version in it.

A mailbox reading pre-1.5 is one whose manifest is older than the stamp itself, which arrived in 1.5.0.0. It can also be classic Outlook for Windows on a build too old to report the version at all, which is old in its own right. Either way it means out of date rather than not known, and it is labelled that way rather than left blank, because blank invites the wrong reading.

Version	What it added
1.4.0.0	Shared mailbox support for the clients that require the manifest to declare it, including a mailbox promoted to a full account in new Outlook for Windows
1.5.0.0	The version stamp itself, so the portal can tell you when your organisation is behind

The notice never appears while Sigil cannot read its own served manifest, so it will not tell you to update towards a version nobody can name. It also counts only mailboxes that have actually applied a signature in the last 30 days, so somebody who left in March does not hold your organisation at “behind” for ever.

Until you update, those mailboxes keep working exactly as they did. They simply do not get whatever the newer manifest declares.

1. Open Activity in the portal sidebar.
2. If your organisation is behind, a notice at the top of the page says which manifest Sigil now serves and how many mailboxes are on an older one. Choose Update to open the steps, with a Copy button for the manifest link.
3. In the By mailbox table, read the Add-in column for each mailbox.

If you deployed from the Marketplace you may still see this notice for a while after a new version is released, because Microsoft rolls it out over time. The Update steps are for a custom app, so there is nothing for you to re-upload. Watch the Add-in column instead, and the notice clears as mailboxes move on.

Updating the add-in

This applies to an organisation that uploaded the manifest as a custom app. A Marketplace deployment is updated by Microsoft. Updating a custom app takes about five minutes. The notice in Activity opens these steps with the manifest link ready to copy, so the version and the URL do not have to be carried between two browser tabs by hand.

1. In the Microsoft 365 admin centre go to Settings, then Integrated apps, open Sigil by Tophhie Cloud and choose Update add-in.
2. Select “Provide link to manifest file”, enter the manifest URL, then Validate and Next.
3. Accept the permissions prompt as soon as it appears.
4. Leave the deployment assigned to the same users and groups, or to the entire organisation if that is what you chose.

Step 3 is the one that catches people out. Microsoft blocks users from the add-in between the upload and the consent, so doing the upload today and the consent tomorrow is a day without signatures for everybody. Do both in one sitting.

Step 4 catches out the organisations that have shared mailboxes. The add-in runs for the person sending, never for the mailbox, so assigning the deployment to a shared mailbox achieves nothing and taking it off the people who send from that mailbox stops it working. See where the add-in runs in a shared mailbox.

Allow Microsoft’s usual 6 to 72 hours for the update to reach clients before treating “it has not appeared” as a fault. The Add-in column in Activity shows each mailbox’s version as it comes through, which is how you watch an update land rather than guess at it.

Removing the add-in

Remove it from Integrated apps in the same place you deployed it. Signatures stop being applied once the removal propagates. Existing messages are unaffected, because Sigil only ever writes into the compose window.

1. In the Microsoft 365 admin centre go to Settings, then Integrated apps.
2. Open Sigil by Tophhie Cloud.
3. Remove the deployment, and allow the propagation window for it to leave every client.