Limits and timings
Signature limits
Section titled “Signature limits”| Limit | Value | Imposed by |
|---|---|---|
| Rendered signature size | Under 30,000 characters | Outlook |
| Image formats | PNG and JPG. No SVG | Outlook, and enforced at upload |
| Image delivery | Inline cid: attachments, not hosted URLs |
Outlook |
The size limit applies to the HTML, including any footer. Attached images do not count toward it. A publish that would exceed it is blocked in the portal.
See Outlook constraints.
Image library
Section titled “Image library”| Limit | Value |
|---|---|
| Largest single image | 1 MB |
| Images per organisation | 250 |
| Library size, all images together | 50 MB |
| Formats an upload accepts | PNG and JPEG, judged from the file’s contents |
| Largest template import file | 20 MB |
Replacing an image under its existing name does not take another place, and its old size is freed. An import that would take the library past either limit is refused whole, before any of its images are stored. See images.
Designer limits
Section titled “Designer limits”| Limit | Value |
|---|---|
| Blocks per design | 200 |
| Columns per row | 6 |
| Nested rows | 4 deep |
| Canvas width | 100 to 900 pixels |
| Column width | 1 to 100 per cent, or 1 to 900 pixels |
| Text size | 6 to 72, in pixels or points |
| Line height | 6 to 120 |
| Block padding, per side | 0 to 200 pixels |
| Image width and height | 1 to 1000 pixels |
| QR code size | 60 to 400 pixels |
| Profile photo size | 16 to 400 pixels |
| Social icon size | 8 to 128 pixels |
| Gap between social icons | 0 to 60 pixels |
| Built-in social marks | 27, being 24 networks plus website, email and phone |
| Button corner radius | 0 to 40 pixels |
| Button padding, horizontal and vertical | 0 to 60 pixels |
| Divider thickness | 1 to 20 pixels |
| Divider width | 1 to 100 per cent |
| Spacer height | 1 to 200 pixels |
| Border width | 1 to 20 pixels |
| Block minimum height | 1 to 600 pixels |
A design that breaks one of these is rejected at publish with a message naming the block at fault. See the designer.
These are ceilings rather than recommendations. A signature is read in a preview pane a few hundred pixels wide, so the useful range for most of them sits well below the maximum.
Assignment rules
Section titled “Assignment rules”| Item | Value |
|---|---|
| Rules per organisation | 100 |
| Attributes a rule can match on | 11 |
| Values in one attribute rule | No limit, comma separated |
| How a group is named | Its Entra object id, typed or pasted, not checked when saved |
| Roles a rule must set | At least one of new messages and replies |
See assignment rules.
Retention
Section titled “Retention”| Data | Retention |
|---|---|
| Template version history | Last 10 published bodies per template |
| Recently deleted templates | 30 days, then purged by a daily sweep |
| Change log | For as long as your organisation uses Sigil |
| Individual signature requests and apply outcomes | 90 days, then purged by a nightly sweep |
| Per-mailbox activity rollup and daily apply totals | For as long as your organisation uses Sigil |
| Daily click totals per tracked link | For as long as your organisation uses Sigil |
| Per-click records behind the analytics splits | 90 days, then purged by a nightly sweep |
| Notes of Microsoft Graph asking Sigil to slow down | 30 days, then purged by a nightly sweep |
| Signature copy kept on a person’s device | 45 days from when it was last written. A compose renews it once it is more than a day old |
| A refusal noted on a person’s device | Ten minutes from the refused compose |
| Operator audit log | Indefinite |
| Onboarding attempt records | Indefinite, and kept after a deprovision |
| Sign-up diagnostics held on those records | 90 days, then cleared while the attempt stays |
| Campaign tags on a sign-up | The utm_ tags stay with the attempt. The Microsoft Advertising click id is cleared at 90 days with the diagnostics |
| Sign-ins from an organisation that never connected | 90 days from the last sighting, then removed in full |
Click totals and the daily chart outlive the per-click records they were built from, so they reach back to the day a link was created. The device, client, referring page and hour-of-day splits are computed from the per-click records and therefore only cover the last 90 days. See link clicks.
How much of the change log you can read at once
Section titled “How much of the change log you can read at once”| Item | Value |
|---|---|
| Entries in the portal’s Audit log view | Most recent 100 of each half on opening, then 100 more of each per Load more, with no upper limit |
| Entries a single API request returns | Most recent 100 by default, and at most 500 when the request asks for more |
| Entries in a tenant export | Most recent 5,000 |
All three are display limits rather than retention ones. The two halves are fetched separately, so template changes cannot be pushed out of view by a busy week of role changes. Narrowing by who or by action then works on what was fetched, and does not reach further back. See the change log.
Link analytics windows
Section titled “Link analytics windows”| Item | Value |
|---|---|
| Windows offered in the portal | 7 days, 30 days, 90 days, 12 months |
| Shortest and longest window the API accepts | 7 to 365 days, clamped rather than rejected |
| Trend column on the links table | Last 30 days |
| Referring hosts shown before the tail is bucketed | 8 |
| Clicks counted from one address on one link | 60 a minute. Above that the recipient is still redirected and only the record is dropped |
| Clicks counted on one link, across every address | 600 a minute at each location on Cloudflare’s network. Above that the recipient is still redirected and only the record is dropped |
Branded link domain
Section titled “Branded link domain”| Item | Value |
|---|---|
| Domains per organisation | One |
| Hostname | A subdomain, not a bare domain. At most 253 characters, each label at most 63 |
| Hostnames refused outright | Anything under usesigil.app, wildcards, and any hostname another organisation has claimed |
| Time from the CNAME appearing to the domain going live | Usually a few minutes |
| How often the certificate’s state is re-read | Nightly, and on demand from the Settings card |
| Re-checking on demand | Not rate limited. Claiming and releasing are |
See branded link domain.
How long changes take to reach users
Section titled “How long changes take to reach users”| Change | Time |
|---|---|
| Template publish | Seconds |
| Staged publish, for the mailboxes in the slice | Seconds |
| Promoting or abandoning a staged rollout | Seconds |
| Scheduled publish | Within 15 minutes after its instant, never before |
| Version restore | Seconds |
| Image upload or replacement | Seconds |
| Footer edit | Seconds |
| Banner window opening or closing | Immediately |
| Pausing delivery | Next compose |
| Resuming delivery, putting a mailbox back into Sigil, or paying an overdue invoice | Next compose, or up to ten minutes for somebody who was composing while stopped |
| Assignment rules change | Next compose |
| Directory change affecting which rule matches | Up to an hour, then one further compose |
| Profile field value saved, by anybody in the organisation | Next compose |
| Directory attribute change in Entra | Up to an hour, without a republish. After a publish or a quiet spell, up to an hour from that mailbox’s first message, then one further compose |
| Microsoft 365 profile photo added or changed | A day or so, then a few composes spread over more than an hour. The photo copy refreshes after a day and the finished signature at most hourly, both behind the message |
| Add-in manifest change | Fresh admin consent, plus 6 to 72 hours propagation. Delivered by Microsoft for a Marketplace deployment; a custom app upload must be updated by an administrator |
| Initial add-in deployment | 6 to 72 hours propagation |
Those are the times a change takes to reach what a mailbox is served. The first message somebody composes after a publish can briefly draw the previous signature and then replace it, because the add-in starts from the copy it kept on the device. What is sent is the new version either way. See why it sometimes changes as you watch.
The row covering resuming, re-including and paying is one delay rather than three, and it belongs to the add-in rather than to Sigil. A mailbox that has just been refused has that refusal noted on the device for ten minutes, and an automatic message inside the window stops without asking again. Pressing Apply in the “My signature” pane asks regardless, which is the way past it. See a refusal is remembered for ten minutes.
The two rules rows are different events. Saving a rule list changes the version its cached decisions are filed under, so the edit lands on the next compose. A change made in Entra changes nothing in Sigil, so a cached decision has to reach the end of its hour-long freshness window before the new department or group can route somebody differently. The re-check then happens in the background rather than while a message is being written, so the first compose after the window still uses the old decision and the one after it follows the directory.
A directory attribute change, such as a new job title, usually follows the same hour. The longer case is a mailbox whose signature has to be built from scratch, which happens when nobody has written from that address for a day. To keep that first message quick, Sigil builds it from the directory record it kept from that mailbox’s last message, which can be up to a week old, and reads a fresh one in the background. The signature built that way is then used for up to an hour like any other, so the new job title can take an hour from that first message, plus one more compose, to appear.
A publish used to fall into that case and now usually does not. Sigil re-renders both signatures for every mailbox that has composed in the last week after a publish, a version restore, promoting a staged rollout, assigning a template to a role or turning link tracking on or off, and again each night. The first message after any of those is normally a swap for something already built rather than a build from scratch. Those re-renders read the directory afresh, which is why a job title changed shortly before a publish generally arrives with it. A mailbox that has not composed in a week is not re-rendered and falls back to the paragraph above, and the re-render covers at most the thousand mailboxes that composed most recently.
Nothing is put in front of a mailbox that would have been refused. A paused organisation, an excluded mailbox and one whose billing has stopped are all skipped, so a re-render can never hand somebody a signature the next compose would have withheld.
Staged rollout defaults
Section titled “Staged rollout defaults”| Item | Value |
|---|---|
| Percentage steps | 10, 25, 50, then everyone |
| Rollouts per template | One at a time |
| Evaluation frequency | Every 15 minutes |
| Apply outcomes needed before any decision | 20 on the new version |
| Soak per step | 60 minutes |
| Failure rate that can trigger a rollback | Above 10% |
| Margin over the current version needed to call it a regression | 5 percentage points |
| Longest wait for enough outcomes at one step | 30 days, then the rollout is cancelled |
Both conditions on the last two rows must hold before a rollout is pulled. See staged rollouts.
Scheduled publishing
Section titled “Scheduled publishing”| Item | Value |
|---|---|
| Pending schedules per template | One. Booking a second replaces the first |
| Furthest ahead a publish may be booked | 365 days |
| How often schedules are checked | Every 15 minutes |
| Retries after a failed schedule | None. The failure and its reason are kept |
See scheduled publishing.
Approval and settings
Section titled “Approval and settings”| Item | Value |
|---|---|
| Publish approval | Off by default, per organisation |
| Rejection note | Required, and kept up to 1,000 characters |
| Approving your own submission | Permitted, and recorded as such |
| Profile editing | Off by default, per organisation |
| Health digest | Weekly by default. Weekly, monthly or off |
See publish approval and the health digest.
Profile fields
Section titled “Profile fields”| Item | Value |
|---|---|
| Fields per organisation | 24 |
| Field key | Starts with a lower-case letter, then letters and numbers, up to 32 characters |
| Field label | 60 characters |
| Help text | 200 characters |
| Types | Text, choice, URL, email, phone |
| Options on a choice field | 1 to 24, each up to 100 characters |
| Maximum length of a value | 500, and never above the field’s own maximum |
| Default maximum length | 200 characters |
| Whole profile per mailbox | 8 KB |
| Renaming a field key | Not offered. Delete and re-add |
| Saves per mailbox | Rate limited, well above normal use |
A required field is advisory. One nobody filled in renders empty rather than failing a compose. See profile fields.
Portal actions that cost something
Section titled “Portal actions that cost something”Most of what the portal does is a database read you have already paid for by signing in. A few actions cost more than that: they call Microsoft Graph, render a signature, or send an email. Those carry a ceiling, counted per administrator per organisation rather than per address, so an IT provider working across twenty client organisations is twenty separate callers rather than one.
| Item | Value |
|---|---|
| Actions that render, read the directory or resolve a mailbox | 120 a minute |
| Actions that send an email | 12 a minute |
| What counts in the first group | Preview, previewing a banner, previewing an archived version, downloading a mailbox’s signature, saving somebody else’s profile values, simulating assignment rules, syncing an excluded group now, uploading an image, importing a template, looking up your website for a new template, claiming or releasing a branded link domain, buying or dropping the add-on behind it |
| What counts in the second | Test email, the banner preview’s Send test to me, and sending the health digest on demand |
| Over the limit | 429 with a message saying to wait a moment. Nothing is changed or sent |
| An API key’s share | Its own, so a key cannot spend a person’s allowance |
| Searching the directory from an address box | 120 a minute from an allowance of its own, so typing into a picker never uses up what previews need |
| Asking the documentation a question | 20 a minute from an allowance of its own, since an answer is a model writing prose rather than a database read. See ask the documentation |
The figures are set well above what the portal’s own screens can generate by being used. Reaching one means a script, a stuck retry, or a page left refreshing itself.
Ask the documentation
Section titled “Ask the documentation”| Item | Value |
|---|---|
| Question length | 3 to 500 characters |
| Conversation carried into a follow-up | The last 8 messages, held in your browser and stored nowhere |
| Pages cited under an answer | Up to 4, and none whose match is weak |
| How long an answer may take | 25 seconds, then it asks you to try again |
| How soon a documentation change reaches the answers | Within about six hours |
| Cost | None. It is not priced and not an add-on |
The add-in’s own requests
Section titled “The add-in’s own requests”| Item | Value |
|---|---|
| Signature requests per signed-in mailbox | 120 a minute, with downloads counted alongside compose requests |
| Over that | 429 with Retry-After: 60. The add-in applies nothing and does not retry |
| Apply reports per signed-in mailbox | 120 a minute. Above that a report is accepted and dropped |
| Largest request body | 16 KB |
The count is kept per mailbox rather than per network address, because a whole
organisation usually reaches Sigil from behind one address. Two requests a
second, sustained, is far more than anybody composing mail produces, so reaching
the limit means a script or a client stuck in a loop. In
Activity a 429 appears under the server-error reason,
with the status recorded beside it.
API keys
Section titled “API keys”| Item | Value |
|---|---|
| Keys per organisation | No limit |
| Key name | 80 characters |
| Expiry | Optional. A key works to the end of the chosen day, UTC |
| Times the secret is shown | One, at creation |
| Requests per key | 600 a minute, then 429 until the rate falls back under it |
| Requests presenting a key, per calling address | 2,000 a minute, counting invalid keys as well as valid ones |
| Resolution of “last used” | One hour |
| Effect of revoking | Immediate, and irreversible |
| Endpoints reachable | Only those on the allow-list shown in the portal. Anything else answers 404 |
See API keys.
Trial and billing
Section titled “Trial and billing”| Item | Value |
|---|---|
| Trial length | 14 days |
| Price | £0.70 per licensed mailbox per month, excluding VAT |
| Billing period | Monthly |
| Billable seat | A licensed member mailbox that cost management has not kept out of Sigil |
| Free | Shared and resource mailboxes, accounts invited in from outside, disabled accounts, mailboxes kept out of Sigil |
| Longest agreed discount term | 60 months, or open-ended |
| Default invoice terms | 30 days from the invoice date |
| Longest agreed invoice terms | 90 days |
| After a failed payment, before signatures stop | 21 days from the first failure |
| After an invoice goes past its due date, before signatures stop | 21 days from the due date |
| Invoices listed in the portal | The most recent 24 |
| Purchase order reference | 140 characters |
| Seat sync | Daily, with no mid-cycle proration |
| Renewal or invoice day | Any day from the 1st to the 28th, moved by Tophhie Cloud on request. See changing your renewal day |
| Notice before a renewal day move | At least 2 days |
| Seat figure on the Billing view | Last night’s count, or a newer daytime correction. Counted live only when there is none from the last 26 hours |
| Exclusion suggestion window | 90 days without a successful apply |
| Exclusion note | 200 characters |
Once a trial ends without an active subscription, signatures stop being served. A failed payment on a live subscription is bounded rather than immediate: Stripe retries the card over roughly three weeks, and signatures stop 21 days after the first failure if the invoice is still unpaid. See billing.
On invoice terms the same 21 days are counted from the due date, so net 30 allows up to 51 days from the invoice being issued. See invoices and credits.
Client support
Section titled “Client support”| Client | Automatic on compose | “My signature” pane |
|---|---|---|
| Outlook on Windows, classic and new | Yes | Yes |
| Outlook on the web | Yes | Yes |
| Outlook on Mac | Yes | Yes |
| Outlook for iOS and Android | Yes | No |
Only one event-based add-in runs at a time. If several are deployed, they run sequentially.
Operator session limits
Section titled “Operator session limits”| Item | Value |
|---|---|
| Read-only impersonation session | 30 minutes, expiring on the server |
| Destructive operator actions | Require fresh interactive re-authentication |
