Troubleshooting deployment

Work from the widest scope inwards. Most reports of “the signature is missing” turn out to be one of four things, and the order below finds them fastest.

Nobody in the organisation has a signature

Several of the causes below reach Activity as the same badge. Paused delivery, an organisation still onboarding, a suspended one, and a mailbox the cost management list does not cover are all reported by the add-in as not-activated, because none of them is anything the person composing could act on. The badge tells you the refusal was deliberate, not which of them it was. The served request recorded beside it names that. See refused requests.

Is Sigil itself up?

Check status.usesigil.app before anything else. It carries the current state of the service and any open incident, and it is hosted away from Sigil so it is readable when Sigil is not. Everything below assumes the service is running. See the status page.

If you can still reach the portal, the status pill beside the page title answers the same question without leaving it, and the public support page carries the same pill for anybody who cannot sign in.

An interruption to Sigil does not stop anybody sending email. What stops is the signature being applied and the portal being reachable.

Is delivery paused?

Open the Templates page and look at the In use card. If it says Paused, that is your answer: somebody switched delivery off for the whole organisation and it is still off. Resume it there.

This is worth checking first because it is silent. Nobody is warned that their signature has stopped, everything in the portal keeps working, and the add-in is behaving exactly as it was told to. See pausing delivery.

Is the trial still running, and is there a card on file?

Billing hard-gates the signature path. Once a trial ends with no active subscription, the add-in receives a 402 and applies nothing. This is the most common cause of a sudden organisation-wide stop.

Check the Billing view. If the subscription is cancelled, that is your answer, and the portal will be showing a notice at the top of every page saying so. A subscription shown as ending is not the answer: a cancellation that has been scheduled leaves signatures running until the day it names.

A past due subscription does not stop signatures straight away either: there is a 21 day window while the card is retried, and they stop at the end of it. So a past due status explains an organisation-wide stop only once that window has run. See billing.

An organisation on invoice terms has no card, so the question is whether an invoice is overdue instead. The invoice list on the Billing view says which, and the same 21 days run from its due date.

Is anybody included?

If cost management is in inclusion mode, only the mailboxes on the list receive a signature, and an empty list means nobody does. The Cost management page carries a warning above its figures for exactly this state, and the seat count on your next invoice would be zero. See which way round the list reads.

If consent has been withdrawn or the enterprise application removed, Sigil can no longer read your directory and cannot personalise anything. Re-visit /admin/consent and grant consent again. See connect your organisation.

Was the add-in ever actually deployed?

The Getting started checklist only marks the add-in step complete once Sigil has seen a real signature request from your tenant. If that step is still open, the deployment has not reached anyone yet.

If you deployed it in the last three days, this is probably just propagation. Allow 6 to 72 hours.

Is something on your network eating the request?

An outbound filter that inspects traffic to portal.usesigil.app can stop signatures without anything in the portal looking wrong. Activity shows the symptom: outcomes reported with a reason and no matching served request, because the add-in got far enough to describe the failure but its request for a signature never arrived.

Two reasons separate the cases, and the difference is worth reading before you open a ticket with anyone. server-error means Sigil answered and the answer was unexpected; the status it answered with is recorded alongside it. unreachable means the request produced no answer at all, which is what a dropped connection looks like and also what a filter or firewall blocking the request looks like from inside Outlook.

A run of unreachable confined to one office, one VPN or one network is a filtering problem rather than a Sigil problem. Where the host is blocked outright, nothing is reported at all and the mailboxes surface on the never-applied list instead, so both symptoms point at the same check: whether portal.usesigil.app is reachable from that network. The request carries nothing in its URL beyond the host, so there is no address or parameter in it for a content rule to object to. See domains Sigil uses.

Some people have a signature and others do not

Check the never-applied list

Open Activity. It cross-references your directory to list mailboxes that have never successfully applied a signature. That list is usually the fastest route to the pattern: one department, one office, one client platform.

The event handler runs in a runtime with no user interface, so it can only acquire a token silently. On somebody’s very first compose, or after an MFA prompt or an expired session, that silent acquisition fails and the add-in gives up quietly by design. An error bar on every compose would be worse than a missing signature.

The fix is for the person to open the “My signature” pane once on a desktop client, which can complete an interactive sign-in. It self-heals from there, and because consent is per user rather than per device, one desktop sign-in also fixes their phone.

These pre-token failures carry no verified identity, so they cannot be reported back. They appear as a mailbox’s absence from the telemetry rather than as a recorded failure.

Is the add-in assigned to them?

Check the assignment in Integrated apps. A pilot deployment that was never widened is a common cause of a clean split between two groups of people.

Is the signature missing only in a shared mailbox?

If somebody’s own messages are signed and only their shared mailbox sends are not, the question is how their Outlook holds that mailbox. Opened as a folder alongside their own, the add-in follows them into it. Added as an account of its own, or promoted to a full account in new Outlook for Windows, Outlook only loads add-ins whose manifest declares support for shared folders, which Sigil’s does from version 1.4.0.0.

An organisation still on an older manifest sees no Sigil at all in those compose windows, and no amount of waiting or redeploying to the mailbox changes that. The Add-in column in Activity says which manifest your organisation is on. The table of which clients need what is on sending on behalf of a mailbox.

On Android and iOS a shared mailbox added as its own account gets no signature from any add-in, and there is nothing to fix. Microsoft does not support the scenario.

Some people have a different signature from everyone else

Check whether a staged rollout is running. A rollout deliberately serves the new version to a slice of mailboxes and leaves everyone else on the previous one, so a report of “my signature does not match my colleague’s” during a rollout is the feature working rather than a fault.

The template editor shows a panel while one is in flight, with the percentage currently covered. Promote it to put everyone on the same version, or roll it back to do the same in the other direction.

One person has no signature

Ask them to open the “My signature” pane from the compose ribbon. It applies the signature on demand and, when it cannot, says why. That message is usually the whole diagnosis.

One message is misleading, and it is worth checking first. If the pane says Sigil is not set up for the organisation yet, and everybody else has a signature, that mailbox has almost certainly been excluded from Sigil. The add-in cannot tell the two apart, because the service refuses both the same way. Look for the address on the Cost management list and put it back if it should not be there.

If your organisation runs cost management the other way round, the same message means the mailbox is simply not on the list. Include it.

If the pane works but automatic application does not, the add-in is present and authenticated, and the problem is with event activation rather than with Sigil. An Outlook restart is worth trying, and on classic Outlook for Windows a client too old to support nested app authentication will report as unsupported.

The signature is wrong rather than missing

Missing name, title or phone number

The directory attribute is empty for that person. Run attribute coverage to see how widespread the gap is, then either populate the directory or wrap the affected part of the template in a conditional section so it disappears cleanly.

Text missing only for some recipients

If a line is there for most people and gone for a few, ask whether those few read their mail in dark mode. Clients built on Outlook on the web recolour a signature’s text and background colours and leave its images alone, so light text over a dark picture disappears entirely and a faint grey line becomes hard to read. It is a rendering behaviour rather than a fault in the template, and the same signature looks correct on your own screen. See dark mode.

The wrong template

Run Test a user on the rules page against the affected mailbox. It replays the same walk the compose path runs and reports which rule decided that person’s signature, so it answers the question directly rather than leaving you to read the list against your idea of their directory record. See simulating a mailbox.

The usual answer is ordering. Rules are evaluated in order and the first match wins, so a broad rule placed above a narrow one will shadow it, and the simulation marks the shadowed rule as having matched too late to decide anything.

Saving a rule list reaches everyone on their next compose, so a rules edit you have just made is rarely the explanation. What does lag is a change made in Entra: the decision reached for each mailbox stays fresh for ten minutes, and nothing tells Sigil that somebody has moved department. The re-check runs in the background after a message has gone, so the first compose past that window sends under the old decision and the next one follows the directory. If the simulation shows the right rule but the mailbox is still sending the old signature shortly after a directory change, that is the likeliest reason, and one more message settles it.

An old version of the template

Template edits are live within seconds, so a stale signature usually means the change was saved as a draft rather than published. Check the template’s draft state in the editor. See drafts and publishing.

A staged rollout produces the same symptom for most of the organisation, and legitimately so: the live template does not change until the rollout promotes.

Broken images

Images must be attached inline as cid: references. A hosted <img> pointing at an external URL is suppressed by Outlook’s default image blocking and renders as a broken image. SVG is not supported at all. See images.

A missing profile photo

A Photo block hides itself for anybody whose mailbox has no photo, so the usual answer is that the person has not set one. Photos are also cached for a day, so a photo added this morning may not appear until tomorrow.

If nobody in the organisation gets one, the photo read is being refused rather than each mailbox lacking a picture. Check what was consented to under permissions.

A missing QR code

A contact-card code is left out when the person’s directory record is too long to fit in a readable code, which is rare but not impossible. The rest of the signature is served normally.

Codes that scan for some readers and not others are usually a contrast problem. The light colour has to be pale and opaque. See per-user images.

Mobile-specific behaviour

Three things on mobile are documented Outlook behaviour rather than faults:

On a reply, the signature is not visible until the compose window is expanded to full screen.

OnNewMessageCompose does not fire for a message started from the iOS Share sheet.

There is no “My signature” pane on mobile, because Outlook mobile activates add-ins in read mode only. A mobile-only failure is fixed from a desktop client.

Other things that look like faults

A new message with no other edits will not autosave a draft, even though the signature was set. That is Outlook’s behaviour, not a signature failure.

If other event-based add-ins are deployed in your tenant, they run sequentially rather than in parallel, which can make signature application feel slower.

The pane’s “Edit my details” button is missing for most organisations, and that is the normal state. It appears only where profile editing is switched on and at least one profile field is available to fill in, and it stays hidden for a mailbox that has been excluded from Sigil. The add-in asks the server rather than deciding for itself, so a button that leads nowhere is not a state it can reach.

Still stuck

Collect the affected email address, the Outlook client and platform, and whether the “My signature” pane works. Those three facts narrow almost everything.

Help in the portal’s sidebar is the shortest route from there. It carries a link to this documentation, the support address, and the response commitment, and it starts an email for you with your organisation name and Microsoft 365 tenant id already in it. Those two are the details support otherwise has to ask for, and each round trip costs another day.

If an IT provider manages Sigil for your organisation, Help names them and points you at them first. They configure your signatures, so they can usually resolve it faster, and Tophhie Cloud stays listed underneath if you cannot reach them.

The public support page at portal.usesigil.app/support says the same things for anyone who is not signed in.

Help also carries the feedback board at feedback.tophhie.cloud, which is where to ask for something Sigil does not do yet. It is one board across Tophhie Cloud’s products rather than a Sigil-only one, and it is the one thing in the dialog that is not routed through your IT provider: a request for a feature is about the product rather than about your configuration, and an idea passed on second-hand usually does not arrive.