info@ is not a user account: Making Microsoft 365 shared mailboxes work

A customer emails info@. Two colleagues open the message. Someone else marks it unread later. That afternoon, the manager asks who replied. Nobody is sure. The mailbox is working perfectly. The way the team uses it is not.

This does not immediately call for a new ticketing system. A properly configured shared mailbox and a few clear working rules may be enough. Microsoft 365 provides shared mailboxes for addresses such as info@, accounts@ and sales@ that several people need to handle.

The useful question is not “How does everyone get the password?” It is “Who has access, who takes ownership, and how do we know a request is finished?” Those decisions turn a general address into a workable place for a team.

A shared mailbox is an additional mailbox that authorised colleagues access through their own accounts. Microsoft does not intend its associated account for direct sign-in and recommends keeping that sign-in blocked. Each person accessing it needs a licensed Exchange Online mailbox. The shared mailbox itself may operate without a separate licence under the relevant conditions.

The address belongs to a function; the identity belongs to a person. When somebody leaves, IT removes their individual access rather than circulating a replacement info@ password. New colleagues receive the permissions their role actually requires.

A shared email address makes sense. A user account used by several people is the wrong foundation for it.

Our recommendation: before replacing an existing shared password, list the people and devices that use it. A scanner or an old website form may depend on those credentials too. Treat those technical dependencies separately rather than discovering them after messages stop arriving.

Microsoft: shared mailbox basics, sign-in and licensing

“I can see the mailbox but cannot reply” is entirely possible. Exchange Online separates access to its contents from permission to send using its address. Full Access lets a delegate open and manage the mailbox; it does not grant sending permission. Sending permission alone does not provide access to the inbox.

For a small customer service team, Full Access together with Send As is often a sensible choice. That is our recommendation, not a universal requirement. For a temporary deputy, showing “on behalf of” may be more appropriate. Decide how you want the business to appear to recipients.

Be particularly deliberate around finance and HR. Covering an absence should not automatically mean permanent access to years of sensitive correspondence. Agree on the scope and end date before configuring access.

Microsoft: mailbox access and sending permissions

Microsoft documents an easily missed default: messages sent from a shared mailbox are initially saved in the sender’s own Sent Items rather than automatically in the shared mailbox. Administrators can enable shared copies for the relevant sending modes.

That can explain a missing reply. Everyone sees the request, but the answer lives elsewhere. We recommend explicitly checking the Sent Items settings and testing the intended behaviour with two accounts.

Person A replies using the shared address. Person B then looks for that exact reply in the shared mailbox. Also check the sender shown to the recipient. A five-minute test gives a clearer answer than “It should work”.

Microsoft: shared mailbox configuration and Sent Items

A read flag says very little about progress. Someone may have opened the message on their phone or merely glanced at it. It does not reliably identify the person responsible for a response.

For a small team, we suggest a simple routine. One person checks incoming messages for a defined half-day or day. They answer straightforward requests and assign the others. A deputy is agreed in advance, and urgent enquiries have a clear escalation route.

The way ownership is recorded matters less than consistency. An agreed folder structure or a shared task list may work. Five different personal marking systems will create more confusion than clarity.

Consider this illustrative workflow: the administrator checks the inbox in the morning. A technical question goes to the relevant specialist and into a shared list with a deadline. The reply still goes out from info@. The request is marked complete only after that reply has been sent. This is a suggested process, not an invented customer success story.

According to Microsoft documentation checked on 16 October 2026, a shared mailbox of up to 50 GB generally does not require its own mailbox licence. Larger storage and certain archive, retention or compliance capabilities have additional licensing requirements. The people accessing it still require their personal licences.

Do not remove a licence simply because a mailbox is labelled “Shared”. First have IT review its size and the additional features actually in use. The relevant service and feature combination determines the answer, rather than a blanket claim in a forum.

For budgeting, also ask what handling messages costs the business. An unnecessary licence is frustrating. Repeatedly missed quotation requests or duplicate replies may matter more commercially. Evaluate the cost of licences and the working process together.

A functional address and the personal mailbox of someone leaving should not be treated as interchangeable. Microsoft supports converting a user mailbox into a shared mailbox while retaining existing email and calendar information. Its associated user object must not simply be deleted, because it anchors the mailbox. Conversion alone is not a complete offboarding process.

Our recommendation for a Swiss SME is to decide first which business information is still needed, who owns it and which access is appropriate. Choose the technical action afterwards. Giving an entire department indefinite access is rarely a good starting point.

Have IT review sign-in, existing sessions, forwarding, inbox rules and delegates as part of the departure. Set a date to reassess the transitional arrangement. “Temporary” needs an expiry date; otherwise, it easily becomes a permanent archive without a clear owner.

Microsoft: converting a user mailbox to a shared mailbox

A shared inbox is useful while the team can keep track. If people regularly struggle to identify who owns a request, another folder may provide only temporary relief. The missing element is reliable case management.

A ticketing system or CRM becomes worth considering when you need response deadlines, multiple handovers, approvals or dependable reporting. Email is not inherently the problem. A customer case simply needs more information than a subject line and a conversation history.

For two weeks, count three things: how often colleagues ask who owns a request, how often two people answer in parallel, and how often someone manually reconstructs an open case. A simple tally is enough. Use the friction you observe to decide whether a better routine will suffice or a different tool is justified.

Avoid building a large automation around an unclear process first. A flow can move messages. That does not mean it has established meaningful responsibility for the customer.

Start with one address that matters to daily operations. Write down its purpose, owner and deputy. With IT, check blocked direct sign-in, membership, sending permissions and the location of sent replies. Test receiving and sending with two authorised accounts.

Then agree on a short working rule: who checks the inbox, how a request is assigned, and when it counts as complete. Keep it where the team can find it. Review the arrangement after two weeks.

Our position is straightforward: a shared mailbox is entirely sufficient for many small teams. It does need an owner, appropriate permissions and a clear routine. The biggest improvement often comes from everyone knowing who will reply tomorrow morning.