Requirements

What you need

Sigil requires Microsoft 365 with Exchange Online. The add-in is an Office.js add-in and the personalisation reads Microsoft Graph, so both halves are Microsoft-native and neither works elsewhere.

You need an account that can do two things:

Task	Permission needed
Grant admin consent to Sigil’s Entra application	Privileged Role Administrator or Global Administrator
Deploy an add-in under Integrated apps	Global Administrator

In practice one Global Administrator covers both. The consent step installs Sigil’s service principal in your tenant and grants the read-only Graph permissions listed in permissions.

No servers, connectors or mail flow rules are involved. Sigil never sits in your mail flow.

Client support

Client	Automatic on compose	“My signature” pane
Outlook on Windows (classic)	Yes	Yes
Outlook on Windows (new)	Yes	Yes
Outlook on the web	Yes	Yes
Outlook on Mac	Yes	Yes
Outlook for iOS	Yes	No
Outlook for Android	Yes	No

Outlook mobile activates add-ins in read mode only. Event-based activation is one of a small number of documented exceptions, but a compose task pane is not, so the manifest declares events and nothing else for the mobile form factor.

Mobile therefore has no manual fallback. Somebody whose signature fails on a phone recovers by opening the pane on a desktop client and choosing Sign in and apply, because consent is per user rather than per device.

Two mobile behaviours worth knowing: on a reply the signature is not visible until the compose window is expanded to full screen, and OnNewMessageCompose does not fire for a message started from the iOS Share sheet.

Domains Sigil uses

Host	Purpose
portal.usesigil.app	Admin portal and the signature API
static.usesigil.app	The add-in bundle and its manifest
e-clk.usesigil.app	Tracked link redirects and contact card downloads

If your organisation filters outbound traffic, allow all three. The add-in fetches from portal.usesigil.app and is itself served from static.usesigil.app. The link domain answers /r/ redirects, /vcf/ contact card downloads and certificate validation requests under /.well-known/, and returns 404 for every other path, so it carries no API or portal surface.

If you hold the branded link domain add-on, your own hostname serves tracked links and contact cards in place of e-clk.usesigil.app, and should be allowed in its stead. Only recipients reach it, so an outbound filter covering your own staff is rarely the thing that matters here.

Two hosts Sigil does not own are also involved. Both are Microsoft’s, and neither is specific to Sigil:

Host	Purpose	If it is blocked
appsforoffice.microsoft.com	Office.js, which Microsoft requires every Office add-in to load from here	The add-in does not run at all
ajax.aspnetcdn.com	MicrosoftAjax.js, part of the Office.js runtime. Outlook for Mac, iOS and Android load it from here, and so can Outlook for Windows	The add-in can fail to start on those clients

Office.js is loaded by both the automatic path and the pane, so blocking it stops signatures rather than degrading them. If you already permit Office add-ins, both are allowed, because the Office runtime needs them for any add-in.

Outlook on the web normally takes Microsoft’s copy of MicrosoftAjax.js from appsforoffice.microsoft.com instead, which is Microsoft’s choice rather than Sigil’s. So a network that blocks ajax.aspnetcdn.com can see the add-in work in the browser and fail in the other Outlook clients.

Office.js also opens a hidden frame to telemetryservice.firstpartyapps.oaspapps.com to send Microsoft its own usage telemetry. That host is in Microsoft’s published network requirements for Office, and Sigil sends nothing through it, so it needs no entry of its own beyond what Office already asks for.

Sign-in goes through login.microsoftonline.com, the same Microsoft sign-in service every Microsoft 365 app uses, so it is already allowed wherever Outlook works.

The card form on the portal’s Billing pages is drawn by Stripe, Sigil’s payment processor, and needs js.stripe.com, api.stripe.com and hooks.stripe.com. Only the people who add a card or pay an invoice in the portal need them. If they are blocked, the form reads “The card form couldn’t be loaded. A content blocker may be stopping Stripe; try again, or use the Stripe page instead.” and signatures are unaffected.

Nothing else needs allowing. The icons in the “My signature” pane were once fetched from unpkg.com; they now ship inside the add-in bundle, so an organisation that blocks general-purpose content delivery networks loses nothing at all.

The typefaces the pane and the admin portal are set in are served from Sigil’s own hosts, static.usesigil.app for the pane and portal.usesigil.app for the portal. No font host needs allowing, and neither fonts.googleapis.com nor fonts.gstatic.com is contacted. If an older allow-list still names them, or still names unpkg.com, those entries can be removed.

Template constraints

Outlook itself sets limits on what a signature can contain. Design within them from the start rather than discovering them at publish time.

A rendered signature must be no more than 30,000 characters. The portal blocks a publish that would exceed it, measured with sample data and without any banner or footer, so leave some headroom.

SVG is not supported. Use PNG or JPG.

Images are referenced as cid: and attached inline by the add-in. A hosted <img src="https://..."> would be suppressed by Outlook’s default image blocking and render as a broken image.

Outlook constraints explains each of these in more detail.

Only one event-based add-in runs at a time

If your organisation has other event-based add-ins deployed, they run sequentially rather than in parallel. This rarely causes a problem, but it is worth knowing if signatures appear more slowly than expected in a tenant with several such add-ins.