Cost management

Not every licensed mailbox needs a signature. Frontline and shop floor staff, kiosk accounts, Teams-only users and licensed service accounts all carry a licence, all count as seats, and many of them never send an email from Outlook at all.

Cost management is where you decide which mailboxes have Sigil. A mailbox kept out of Sigil receives no signature and is not counted towards your seats.

You keep one list, and there are two ways to put a mailbox on it. You can pick mailboxes individually, or you can name an Entra group and add whoever is in it. The second one keeps up with the group as people join and leave it.

A mode decides what that list means. In exclusion mode, which is the default, the list is the mailboxes that do not have Sigil. In inclusion mode it is the only ones that do. Most of this page is written in the exclusion-mode direction, because that is what most organisations use, and the section on modes says which parts read the other way round.

One switch, both effects

Keeping a mailbox out of Sigil does two things at once, and there is no way to do one without the other.

It stops being served a signature on every path: automatic application on compose, and the download in the “My signature” pane.

It comes off the seat quantity reported to Stripe.

The pairing is deliberate. A mailbox still served but no longer billed would be a way of taking the product for free, and a mailbox no longer served but still billed is the complaint the feature exists to answer.

Aliases are covered

The list holds mailboxes by their primary address, which is the one the directory picker offers and the one a group’s membership resolves to. A message can be sent from any of that mailbox’s other addresses, though, and Sigil checks the mailbox behind the sending address as well as the address itself.

So sending from an alias of an excluded mailbox gets no signature either. Without that, an alias would be served a full signature while the seat count, which works from the directory, had already stopped billing for it, which is exactly the served-but-not-billed state the pairing above exists to make unreachable.

This costs nothing for an organisation that excludes nothing, and the lookup only happens once the cheaper checks have already said there is something to look for. If your directory cannot be reached at that moment, Sigil serves the signature rather than withholding it, since a directory outage should not start removing signatures from people nobody excluded.

You can type an alias

The address box takes any address you type or paste, and that may well be a secondary alias rather than a primary. You do not have to look the primary up. Sigil resolves the address to the mailbox that owns it and lists the mailbox. The confirmation names the primary address it stored and the alias you reached it by, so what went on the list is never left to be inferred from what you typed.

That resolution happens when the entry is written rather than every time it is read, because the two halves of the switch would otherwise disagree. The signature gate resolves a sending address to its mailbox, so a raw alias on the list would be matched. The seat count works from the directory, where every account is keyed by its primary, so the same raw alias would match nothing at all. One address on the list would then stop the signature and leave the bill alone, or the reverse, which is the split the pairing above exists to prevent.

The other ways onto the list already yield primary addresses, so this applies only to the address box. The picker offers directory accounts, a group’s membership resolves to the accounts in it, and the suggestions come from the directory listing.

If your directory cannot be read at that moment, or no mailbox in it claims the address, it goes on the list exactly as you typed it. Refusing the entry instead would mean a directory outage, or a mailbox being set up an hour from now, standing between an administrator and switching a signature off.

Which way round the list reads

Two organisations want opposite things from the same list.

A large estate trimming a few dormant accounts wants “everyone is in unless I say otherwise”. An organisation where one team of twelve uses Sigil and four hundred other licences do not wants the reverse, because keeping that as an exclusion list would mean naming four hundred people and chasing every new starter.

So the list has a mode, set on the Cost management page.

Mode	Your list is	Everyone else is
Exclusion, the default	The mailboxes that do not have Sigil	Served a signature, and billed
Inclusion	The only mailboxes that have Sigil	Not served, and not billed

To change it, the list must be empty. You need the Admin or Billing role, or partner Owner or Admin inside a managed client.

1. Open Cost management in the portal sidebar.
2. On the card headed Exclusion mode or Inclusion mode, choose Switch to inclusion mode or Switch to exclusion mode. The button is disabled while anything is listed, with the reason beside it.
3. Read the confirmation. Switching to inclusion mode says nobody receives a signature and the seat count is zero until you add someone.
4. Choose Switch (nobody until I add them) for inclusion mode, or Switch for exclusion mode.

A message confirms the new mode, and the page’s wording, buttons and headline figures change to match it.

One mode at a time

A list cannot exclude some people and include others. Two lists with opposite meanings over the same mailboxes would have no single answer to “is this one billed”, and that is the question the nightly seat count sends to Stripe.

For the same reason the mode can only be changed while the list is empty. Remove every mailbox and every group first, and the button becomes available. Until then it is disabled, with the reason beside it rather than left to be guessed at, and the API refuses the change and says how much is still listed.

That rule exists so a list written to keep people out is never silently re-read as the list of people to keep. Nothing carries over between the modes.

An empty inclusion list means nobody

Switching to inclusion mode necessarily starts from an empty list, and an empty inclusion list means nobody at your organisation is served a signature and your seat quantity is zero.

That is a real state rather than an error. The confirmation says so before you click it, and the page carries a warning above the figures for as long as it lasts. Zero seats reaches your next invoice like any other seat change, so an organisation that switches over and then forgets to add anybody has an active subscription serving nothing.

The intended sequence is to switch, then add the mailboxes and groups that should have Sigil. Switching back to exclusion mode restores everybody at once.

What reads the other way round

Most of this page holds in both modes, with “excluded” reading as “not on the list”. Four things genuinely differ.

Shared mailboxes swap sides, and so do the mailboxes of Microsoft 365 Groups. In exclusion mode, listing one saves nothing because it was never billed, and the picker hides them so nobody believes in a saving that is not there. In inclusion mode a shared or group mailbox nobody lists gets no signature at all, so the picker offers them and the row says it is included for free.

Aliases work in the same direction as the mailbox they belong to. In inclusion mode, sending from an alias of a listed mailbox is served, because Sigil resolves the mailbox behind the address before deciding.

There are no suggestions in inclusion mode. “These billed mailboxes never use Sigil” has no counterpart when everyone unlisted is already unbilled, so the button is not offered rather than returning an empty list.

A group that cannot be read still fails closed, and closed means the list stands. In exclusion mode that keeps its members switched off. In inclusion mode it keeps them switched on and billed, because treating an unreadable group as empty would stop the signature and the billing of every mailbox you are paying for, on the strength of a failed network call.

What the figures say

The headline figures on the page are written for the mode you are in.

Mode	Figures
Exclusion	How many mailboxes are excluded, and how many of those were actually coming off the bill
Inclusion	How many are included, how many seats that bills, and how many mailboxes are kept out

In inclusion mode the included count and the billed-seat count differ whenever the list holds a shared or disabled mailbox, since those are included for free.

The count of mailboxes kept out needs your directory, so if it cannot be read at that moment the figure is shown as unavailable rather than as zero.

What excluding actually saves

Only licensed, enabled member mailboxes are billed in the first place, so excluding anything else saves nothing. It still stops the signature.

Mailbox	Effect of excluding it
Licensed, enabled member mailbox	No signature, and one seat off the bill
Shared or resource mailbox	No signature. It was unlicensed and therefore already free
Disabled account	No signature. Already free
Account invited in from outside	No signature. Already free

The portal says so rather than leaving you to work it out from an invoice. Each row on the list records whether that mailbox was billable, and the headline figures separate how many mailboxes are excluded from how many are actually coming off the bill.

A prepaid block changes the arithmetic. While one is active you pay only for the mailboxes above the number you prepaid, so excluding a mailbox lowers your count but only lowers the bill once the count is above the block. Neither the headline figures nor the suggestion estimate on this page take a prepaid block into account.

The directory picker only suggests enabled mailboxes belonging to your own organisation, for the same reason. You can still type any address by hand.

Suggested exclusions

This is an exclusion-mode feature. See what reads the other way round.

Sigil records, per mailbox, whether a signature was ever successfully applied. So it can answer the question directly rather than leaving you to audit 400 licences by hand: which of these mailboxes have never once used the thing you are paying for.

Press “Suggest mailboxes” and Sigil lists the billable mailboxes that have never once successfully applied a signature, with an estimate of what excluding all of them would save each month.

Nothing is excluded until you choose it. The list is the starting point for a decision rather than an action.

The suggestion errs on the side of leaving people alone.

A mailbox that has applied a signature even once is never suggested, whatever its volume since.

There is no look-back window, so somebody on extended leave, in a seasonal role or who simply sends very little mail is not swept up as long as Sigil has signed their mail at least once. The panel’s own text mentions 90 days, but that figure is a minimum age for your organisation rather than a window on each mailbox.

An organisation connected less than 90 days ago gets no suggestions at all, because nobody in it has had a full quarter in which to apply anything. The panel says so rather than showing an empty list.

Two states are kept apart on the list, because they mean different things.

Row says	What it means
Never seen by Sigil	No add-in has ever asked for a signature for this mailbox. Usually the person does not send mail from Outlook
Fetched but never applied	A signature was served and never landed. That can mean the add-in is broken for them

The second is worth investigating before excluding. Excluding it would bury a real fault rather than save money.

The estimate uses the list price and ignores any agreed discount, so treat it as an upper bound.

The list is fetched only when you ask for it. It walks your whole directory and cross-references the telemetry, which is not work to do every time somebody opens the page.

Using the suggestions

1. Open Cost management in the portal sidebar.
2. Choose Suggest mailboxes. The button is only offered in exclusion mode.
3. A panel headed Never applied a signature lists the mailboxes, each with the reason it is there, and the saving the whole list represents.
4. Choose Exclude on a row to exclude that mailbox, or Exclude all followed by the count to exclude every mailbox listed. Excluding them all asks you to confirm with Exclude all.

Each mailbox excluded this way joins the list below with the note “No signature applied in the last quarter”, and can be put back like any other.

Excluding a mailbox by hand

Pick the mailbox and add an optional note of up to 200 characters. The note is free text and is never interpreted. It exists so the list is still legible in six months, so “warehouse floor” or “Teams-only licence” is the kind of thing worth writing.

An address typed rather than picked is resolved to the mailbox behind it first, so pasting somebody’s alias out of a ticket works. See you can type an alias.

You need the Admin or Billing role, or partner Owner or Admin inside a managed client.

1. Open Cost management in the portal sidebar.
2. Choose Exclude a mailbox. In inclusion mode the button reads Include a mailbox.
3. In Mailbox, start typing a name or address and pick the mailbox from the suggestions, or type or paste an address.
4. Add a Note if you want one.
5. Choose Exclude mailbox, or Include mailbox in inclusion mode.

A message names the mailbox that went on the list, and the address you typed if that was an alias of it, and says it gets no signature and comes off the next invoice. The mailbox appears in the list at the bottom of the page with the note, the date and who added it.

Excluding an Entra group

Ticking 120 boxes is a poor way to manage 120 warehouse staff who are already a group in your own directory, and it goes stale the first time somebody is hired.

So you can name a group instead, and its membership is what gets excluded. Search for it by name, or paste its object ID if you have arrived from the Entra portal with one on the clipboard. Either way Sigil confirms the group exists in your directory before saving it, so a mistyped ID is refused there and then rather than becoming a group that quietly excludes nobody for ever.

Membership is resolved as soon as you add the group, so you can see who it covers without waiting for anything.

Nested groups count. Sigil walks the group’s membership transitively, so a group of groups excludes the people inside all of them. Members that are not people, such as devices and service principals, are ignored because they have no mailbox to exclude.

1. Open Cost management in the portal sidebar.
2. Under By Entra group, choose Exclude a group. In inclusion mode the button reads Include a group.
3. In Group, start typing the group’s name and pick it from the suggestions, or paste its object ID.
4. Add a Note if you want one.
5. Choose Exclude group, or Include group in inclusion mode.

A message names the group and how many mailboxes it excluded. A group that is empty is still added, and the message says it currently covers no mailboxes. If its membership could not be read, the message says that instead, and the group is added with the error shown on its row so you can retry it with Refresh.

It tracks

Membership is not a one-off import. Somebody added to the group next month is excluded then, with no further action in Sigil, and somebody removed from it gets their signature and their seat back. That is the difference between managing a group and bulk-ticking its members once.

Sigil refreshes every excluded group once a day, immediately before the daily seat sync, so a seat count is never derived from a membership a day older than itself. Between those refreshes the group is not watched, which means a new joiner keeps their signature and their seat until the following night. That is the direction worth being wrong in: nobody unexpectedly loses a signature the moment HR edits a group.

If you have just changed the group in Entra and want it applied now, press Refresh on the group’s row.

The two lists do not overwrite each other

Mailboxes you picked individually and mailboxes covered by a group are kept apart, and one can never undo the other.

Somebody excluded both by hand and by group stays excluded when they leave the group, because their individual entry is still there. Removing a group releases only the people it was the sole reason for excluding, and the portal says so before you confirm it.

The individual list in the portal shows only the mailboxes you picked yourself. Group members are not enumerated in it, since one group can cover several hundred people and that is not a table anybody reads. Each group’s row carries its own member count, and the headline figures at the top of the page count both origins together, without counting anybody twice.

When a group cannot be read

A refresh that fails leaves the previous membership exactly as it was, and shows the error against the group.

If the very first read fails, there is no previous membership to keep. The group is still added, carrying its error, so you have a row you can see and retry rather than nothing at all. Nobody is excluded by it until a read succeeds.

The portal is careful to say which of two things happened, because they look identical from the dialog and mean opposite things. “It currently covers no mailboxes” means the group is empty. “Its membership could not be read” means your directory refused the question, almost always for want of the permission below.

Treating an unreadable group as an empty one would restore signatures to, and resume billing for, everybody it covers, on the strength of a failed network call. So Sigil holds what it last read instead. The row shows when it was last refreshed successfully, which is what tells you whether the count beside it is current or stale.

A group that has genuinely been deleted from your directory is treated differently, and does release its members. There is no membership left to honour, and leaving people excluded by a group that no longer exists would be unexplainable to whoever is reading the list.

The most likely cause of a failure is the permission. Reading group membership needs GroupMember.Read.All, which Sigil requests at admin consent for group assignment rules, so almost every organisation already has it. An organisation that consented before it was requested will see the group search report that plainly rather than return an empty list. See permissions.

A renamed group member sorts itself out

Membership is re-read from your directory on every refresh, so if somebody in an excluded group changes address, the group picks them up again under the new one at the next refresh.

Individual exclusions do not behave this way. See a renamed mailbox stops being excluded below.

Reviewing the list

1. Open Cost management in the portal sidebar.
2. Read the headline figures at the top: Excluded, Coming off the bill and, when any row no longer resolves, Not in directory. In inclusion mode they are Included, Billed seats and Kept out, again with Not in directory when any row no longer resolves.
3. Under By Entra group, each group’s row shows how many mailboxes it covers and when it was last checked. Choose Refresh to re-read it now.
4. The table at the bottom lists the mailboxes you picked individually, with the note, when each was added and by whom. A row that was never billable says so, and a row whose address no longer resolves is marked as not in the directory.

Putting a mailbox back

You need the Admin or Billing role, or partner Owner or Admin inside a managed client.

1. Open Cost management in the portal sidebar.
2. In the list at the bottom of the page, find the mailbox and choose Put back. In inclusion mode the button reads Stop including.
3. Read the confirmation, which says the mailbox starts receiving signatures again and returns to the seat count on your next invoice.
4. Choose Put back, or Stop including in inclusion mode.

A “Back in.” message confirms it and the row disappears. If one of your listed groups also covers the mailbox, it stays excluded through that group even though its own row has gone. Take it out of the group in Entra, or remove the group.

To release a whole group, choose Remove on its row under By Entra group and confirm with Stop excluding. The confirmation says that anybody covered only by that group starts receiving signatures again, and that anybody you also excluded individually stays excluded. A message then says how many mailboxes are back in.

When each half takes effect

Effect	When
The signature stops	Immediately. The next compose is refused
The signature comes back	At the next compose, or up to ten minutes later for somebody who was composing while excluded
The seat count changes	At the next daily seat sync
The Billing view’s seat figure	After the next nightly count. This view shows the change at once, so the two disagree until then
The price changes	On your next invoice

Seat changes never produce a mid-cycle invoice or a credit, so excluding twenty mailboxes today does not refund part of this month. That is the same treatment a leaver already gets. See billing.

An IT provider whose partner invoice is worked out on the period’s average sees it sooner. There is still no mid-cycle invoice, but the excluded mailboxes stop counting towards that average from the day they are measured, so the current period’s charge already reflects them. See how the average is worked out.

Putting a mailbox back works the same way in reverse, with one delay worth knowing about. The seat returns on the next invoice, and Sigil serves the signature to the next message that asks for it. The add-in may not ask straight away: a mailbox that was refused in the last ten minutes has that refusal noted on the device, and an automatic message inside the window stops without contacting Sigil at all. Somebody who has been writing throughout therefore waits out the rest of the window before a signature appears.

Opening the “My signature” pane and pressing Apply skips the wait, because the pane always asks. See a refusal is remembered for ten minutes.

What a mailbox kept out of Sigil sees

This is the same whether the mailbox was excluded by name or simply never included.

Nothing, on compose. The add-in is refused and applies no signature rather than interrupting a message with an error.

If they open the “My signature” pane, it tells them “Sigil isn’t switched on for your organisation yet. Ask your IT team.” That message is wrong for this case. The add-in cannot tell an excluded mailbox apart from an unconnected organisation, because the service refuses both the same way. Worth knowing before somebody raises a ticket about it.

Where excluded mailboxes stop appearing

Excluding a mailbox also removes it from the reports that would otherwise keep asking about it.

Report	Effect
The never-applied list	Excluded mailboxes are dropped
Attribute coverage	Dropped from the total. The API reports how many were dropped, but the page does not show the figure
The health digest	Dropped, since it reports on both of the above

The digest is the important one. Left in, it would email your administrators every week, indefinitely, about mailboxes they switched off on purpose.

Refused requests are still recorded in the activity feed, with an outcome of excluded. An excluded mailbox should not be asking for a signature at all, so a steady stream of them points at an add-in still deployed to somebody who no longer needs it.

A renamed mailbox stops being excluded

This applies to mailboxes you excluded individually. Group members are re-read on every refresh and are not affected.

An individual exclusion is held against the email address, because the address is what the rest of Sigil keys on: the compose path, the assignment cache, the activity rollup and the coverage audit all use it.

If a mailbox is renamed, the entry no longer matches it. In exclusion mode that mailbox starts receiving signatures again, and returns to the bill at the next daily seat sync. In inclusion mode the opposite happens and it quietly loses its signature, which is the more urgent of the two. Sending from the old address as an alias is still covered, because aliases are checked, but a rename that leaves no alias behind is not.

The portal flags this rather than leaving it to be found on an invoice. Any row whose address no longer resolves in your directory is marked as not in the directory, and the number of them appears as its own headline figure. Re-exclude the mailbox under its new address to put it back.

That figure covers two situations, and only one of them costs anything.

Why the row no longer resolves	What it costs, in exclusion mode
The mailbox was renamed	It is billed again, under its new address
The mailbox was deleted	Nothing. A deleted mailbox is not in the directory the seat count comes from, so it is not billed either way. The row is merely stale

In inclusion mode a renamed mailbox costs nothing and loses its signature instead, and a deleted one is still merely stale.

Nothing repairs these automatically.

What is recorded

Every change to who has Sigil is written to the change log, naming who did it and when. The entries record people rather than list rows, so adding somebody to an inclusion list is logged as a mailbox being included, and a member leaving a listed group in inclusion mode is logged as one being excluded. Reading the log does not require knowing which mode the list was in.

Changing the mode is its own entry, because it is the one change that moves the bill without naming anybody.

This is the one thing outside signature editing that changes what a colleague’s outgoing mail looks like, so “who switched off my signature” has to be answerable.

Each entry shows the addresses involved (the first three, then a count of the rest), the group it came through, and the note. A change made by your IT provider carries a Your provider badge. The same detail is in the API and in a tenant export.

Group refreshes are logged the same way, and this matters more than it might sound. Because membership tracks, a mailbox can lose its signature without anybody having touched Sigil at all: an edit to a group in Entra is enough. Each refresh that changes who is excluded therefore writes an entry naming the group, so the question resolves to “the Warehouse Staff group, on the 12th” rather than to nobody. A nightly refresh that changes nothing writes nothing, and the entries it does write are recorded against the system, since no person at your organisation did anything that day.

Who can use it

The Admin and Billing roles, from Cost management in the portal. Editors, Marketing, Viewers and the Compliance role do not reach it.

Inside a managed client, partner Owners and Admins reach it. A partner Technician does not, because switching off a mailbox’s signature is an account decision rather than signature work.

Cost management is a separate permission from billing. That is what lets a managed service provider trim a client’s dormant mailboxes, which it carries on its own consolidated bill, without also being given sight of that client’s card, invoices or subscription. See roles and capabilities.

What it will not do

You cannot exclude on a directory attribute. There is no way to say “everybody whose department is Warehouse”, the way an assignment rule can. Groups covered the case that actually came up, and an attribute rule wants a preview of its own before it is allowed to pull people out of both billing and signatures.

For one mailbox, there is no way to switch its signature off while continuing to pay for it, and no way to stop paying while keeping its signature. The two halves of an exclusion move together.

Organisation-wide, the first of those is a separate control: pausing delivery stops everybody receiving a signature and changes nothing about the bill. It is a rollout tool rather than a cost one, so a pause left on for a month still costs a month.

Excluding a mailbox has nothing to do with portal access. Who can sign in to the portal, and at what role, is users and roles.