If your Microsoft 365 renewal lands after 1 July 2026, the easy licence cleanup has probably already been done. The remaining waste is usually quieter: shared mailboxes that were licensed like people, automation accounts that still have user mailboxes, SMTP relay identities nobody wants to touch, and edge cases that slipped through every joiner-mover-leaver process. Microsoft says its commercial Microsoft 365 pricing updates took effect from 1 July 2026 for new customers and for renewing customers globally, with local market adjustments, so renewal reviews have become more detailed than a simple active-user count (Microsoft FAQ). For an Australian IT manager, the question is not only which users should move first. It is which non-human identities should stop consuming full business or enterprise seats. Microsoft’s own guidance gives you the first big clue: a shared mailbox can hold up to 50 GB without its own licence, but a licence is required for cases such as going above 50 GB, enabling archive growth, or placing the mailbox on litigation hold (About shared mailboxes in Microsoft 365). Microsoft also recommends that service workloads use managed identities or service principals instead of Entra user accounts used as service accounts (Securing Microsoft Entra service accounts). That means many tenants are carrying avoidable seat cost simply because old technical choices were never revisited. This post gives you a practical order of exit: which shared mailboxes and service-account patterns to move off full per-seat licensing first, which ones must stay licensed, and what to ask before you touch anything in production.
01Start with the four non-human patterns that most often inflate renewals
In most tenants, non-human sprawl falls into four buckets: shared mailboxes, user-based service accounts, device or application relay identities, and operational edge cases such as room-style mailboxes, queue mailboxes or archived ex-project accounts. Each bucket has a different licensing answer, so the first mistake is treating them all as “mailboxes”.
Shared mailboxes are the cleanest win. Microsoft says they are meant for addresses used by multiple people such as support, reception or info mailboxes, and that the shared mailbox itself does not need a separate licence if it stays within the included limits. Accessing users still need their own licensed Exchange Online mailbox (Microsoft Learn).
User-based service accounts are the next target. Microsoft explicitly says that if you can use a managed identity or service principal, you should do so, and recommends not using a Microsoft Entra user account as a service account (Microsoft Learn). If an account signs in only so an application, script or connector can do work, it is a governance smell and often a licensing smell too.
Relay and send-only identities sit in the middle. Some exist only because a line-of-business application needed SMTP years ago. Others now exist because every scanner, ERP connector or monitoring platform was given a mailbox rather than a better mail flow design. These are not always removable in one pass, but they should be reviewed separately from user mailboxes because the target design may be relay, application permissions, or platform-native outbound mail rather than another paid seat.
- Shared mailboxes: often easiest savings, but only if they are really shared and under licence-free limits.
- User-based service accounts: high-value cleanup because they carry both security and cost risk.
- Relay identities: usually need design work, not just a licence swap.
- Edge cases: keep for last unless they obviously break the rules.
| Pattern | Typical signs | Likely action | Main risk if you move too fast |
|---|---|---|---|
| Shared mailbox under 50 GB, no hold, no archive | Used by a team, no interactive logon needed | Remove direct licence from mailbox if one is assigned | Permissions or delegated access misunderstood |
| User account used only by app, script or integration | Non-human name, unattended sign-in, static password | Replace with managed identity or service principal where possible | Application outage if authentication method is not redesigned |
| SMTP relay or send-only mailbox | Used by scanners, ERP, alerts, forms | Move to relay or app-specific method, then remove user licence | Mail flow interruption, SPF or connector gaps |
| Shared mailbox over 50 GB or on hold | Large historical content, legal retention, archive use | Keep licensed or redesign retention and archive approach | Data retention or compliance breach |
02Shared mailboxes: the easiest accounts to move, but only when the limits fit
Microsoft’s rule is straightforward. A shared mailbox can store up to 50 GB without a licence. If you need the shared mailbox to go to 100 GB, it must be assigned Exchange Online Plan 2. If you need in-place archiving, or if the mailbox is on litigation hold, Microsoft says you also need qualifying licensing such as Exchange Online Plan 2 or Exchange Online Plan 1 with Exchange Online Archiving add-on, depending on the scenario (About shared mailboxes in Microsoft 365).
That makes your first pass simple. Pull every mailbox with shared mailbox type, current size, archive status, hold status and assigned licences. Any shared mailbox under 50 GB with no archive and no hold should be reviewed for licence removal first. This is where renewal waste hides because admins often assign a full Microsoft 365 Business or E-plan seat to solve a one-off issue, then never revisit it.
Be careful with the phrase “shared mailbox” in local admin language. Some organisations call anything non-personal a shared mailbox, even when it is technically a user mailbox that somebody disabled sign-in on. Those are the ones that keep billing like a person. Your job is to identify the mailbox type in Exchange Online, not the nickname used by the service desk.
The important edge case is access. Microsoft says users who access a shared mailbox must themselves have a licensed Exchange Online mailbox (Microsoft Learn). So this optimisation removes the mailbox licence, not the team’s underlying user licences.
- Move first: support@, accounts@, reception@, tenders@, projects@ style mailboxes under 50 GB.
- Do not move blindly: any mailbox with archive enabled, hold enabled or unusual compliance policy links.
- Check mailbox type, not display name.
- Confirm who actually needs Send As or Full Access before changing anything.
03Service accounts should usually leave the user-mailbox model before they leave the licence ledger
Microsoft’s identity guidance is clear: for services hosted in Azure, use a managed identity if the service supports it, and a service principal if not. For services not hosted in Azure, Microsoft recommends a service principal. Microsoft does not recommend using Entra user accounts as service accounts (Securing Microsoft Entra service accounts, Governing Microsoft Entra service accounts).
That matters because many Microsoft 365 renewals still include “automation users” that own a full mailbox, hold a costly suite licence, and sign in only so a script can read mail, drop calendar items, or call Graph with a stored password. Those accounts are expensive, but the bigger issue is that they are the wrong identity pattern altogether.
The right migration sequence is usually: document owner and purpose, find the application or script using the account, confirm whether the workload can use managed identity or service principal, redesign authentication, test least privilege, then remove the user licence and if possible the user object itself. Microsoft recommends documenting owner, purpose, permissions, linked resources, review period and lifetime for service accounts, which gives you a good minimum dataset for this review (Governing Microsoft Entra service accounts).
Do not start by deleting licences from service accounts whose authentication model you have not replaced. The cost saving is real, but the outage risk is higher than with shared mailboxes. In practice, shared mailbox rationalisation is a licence exercise. Service-account rationalisation is an identity and application change exercise.
- Fast candidates: unattended accounts with no mailbox activity except app-driven access.
- Ask whether the workload needs mail at all, or only identity.
- If the service runs in Azure, check managed identity first.
- If the service is external or multi-tenant, check service principal first.
04Relay, scanners and send-only mailboxes: remove the seat only after you redesign the path
The noisiest category in renewal data is often not the biggest by count, but it is the one most likely to cause an after-hours incident: scanner accounts, ERP notification mailboxes, CRM senders, alerting accounts and “do-not-reply” identities. These often sit on user licences because somebody needed mail to leave the tenant and a user mailbox was the easiest way to make that happen.
Your review here is architectural. Is the application receiving mail, or only sending it? Does it need a mailbox, or just a way to submit mail? Does the vendor support modern authentication, connector-based relay, Graph-based sending, or a third-party transactional mail service? If the answer is send-only, a licensed user mailbox is often the wrong end state, even when it was the easiest original fix.
The trade-off is operational risk. Shared mailbox changes are usually reversible and visible to end users. Relay changes can fail silently and hit invoices, shipment notices, password resets or system alerts. For that reason, rank these accounts by business impact before rank by licence cost. The payroll printer can wait. The ERP invoice sender cannot.
A practical approach is to move low-impact senders first, prove logging and delivery, then tackle regulated or revenue-linked flows. If you need to keep a technical sender temporarily, mark it as an exception with owner, dependency, and target removal date rather than letting it survive another full renewal by inertia.
- Separate receive-capable mailboxes from send-only identities.
- Check whether the sender is business-critical before touching authentication or connectors.
- Demand evidence from application vendors about supported outbound mail methods.
- Create dated exceptions, not permanent mysteries.
05Which non-human accounts should leave first, second and last
First out should be low-risk shared mailboxes that fit Microsoft’s licence-free pattern: genuine shared mailboxes, under 50 GB, no archive growth requirement, no litigation hold, and no special compliance dependency. These are usually the cleanest savings because Microsoft’s own documentation supports the model directly (About shared mailboxes in Microsoft 365).
Second should be user-based service accounts that do not need mailboxes at all and can be moved to managed identities or service principals with limited redesign. Microsoft recommends these identity types over user accounts, so the savings come with a security improvement, not just a finance win (Securing Microsoft Entra service accounts).
Third should be send-only and relay identities where the application path can be changed safely. These often require testing across SPF, connectors, application settings and operational monitoring, so they tend to take more effort than shared mailbox cleanup even when the monthly waste looks obvious.
Last out, or not out at all, should be shared mailboxes above 50 GB, mailboxes on hold, mailboxes with archive dependency, and any mailbox tied to compliance workflows. Microsoft says these scenarios require additional licensing, so trying to force them into the licence-free pattern is usually a false economy (Microsoft Learn).
- Leave first: compliant shared mailboxes with accidental licences.
- Leave next: true non-human user accounts that can become workload identities.
- Leave later: relay and application senders after design validation.
- Leave last: hold, archive and over-50 GB shared mailboxes.
06What to ask your team or vendor before you remove any non-human licence
A rushed rationalisation exercise saves one renewal line and creates six incidents. The right questions are boring, specific and technical.
For every mailbox or service account, ask who owns it, what business process fails if it stops, whether it must receive mail, whether it must send mail, whether it is on hold, whether it needs archive, what applications authenticate with it, and what the supported replacement pattern is. If nobody can answer those in one place, your first deliverable is not licence removal. It is an account register.
For vendors, ask for supported authentication methods, modern-auth support, mail submission options, dependency on basic SMTP patterns, logging for outbound mail, and documented limits or prerequisites. For internal app teams, ask where credentials are stored, how secrets rotate, how failures alert, and whether the process can move to Graph, service principal or managed identity.
Expect some work. Shared mailbox cleanup can be done in days if the inventory is good. Service-account and relay cleanup often needs discovery, testing and staged rollout because it crosses identity, mail flow and application ownership. If the estate is messy, treat it as a contained infrastructure project rather than a finance tidy-up.
- Who owns it?
- What breaks if it stops?
- Does it really need a mailbox?
- Does it need receive, send, or both?
- Is there hold, archive or compliance dependency?
- What is the supported non-user identity pattern?
- How will you test and roll back?
Sources
Topics
SyncTrix Editorial
SyncTrix · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.