Shared Contact Address: Set Up Microsoft 365 Without a Common Password

Choose between a shared mailbox, alias, group and user mailbox

A contact@, reception@ or support@ address can hide several different requirements. Before configuring Microsoft 365, I ask who must read messages, who should reply, which identity the recipient should see and whether a shared history must remain visible. The solution follows those workflows, not simply the address name.

A shared mailbox is suitable for information, support or reception addresses used by several people. For the other forms—alias, group or user mailbox—I do not infer behaviour from the name: I compare the requirement with the documented behaviour in the tenant before choosing. If the expected workflow goes beyond shared reading and replying, the solution must be assessed separately.

I therefore write a short brief: incoming recipients, authorised readers, sending identity, deletion rules, expected history and devices in use. A shared mailbox is not automatically suitable for every collaborative workflow; it must match how the organisation actually handles messages.

I also check whether one person remains responsible for follow-up or several members must cover for one another. That answer determines the need for shared visibility and avoids choosing an unnecessarily complex solution for simple forwarding.

Keep one named account per person without a common password

I advise against distributing the password of a generic address to the entire team. In Microsoft 365, users access the shared mailbox through their own licensed Exchange Online mailbox and delegated permissions. Each person signs in with a named account and receives only the rights required for their work.

The shared mailbox is not intended for direct sign-in with its associated user account; Microsoft says that sign-in should remain blocked. This prevents a technical mailbox from becoming a collective account whose password circulates and whose access is difficult to attribute or revoke.

• one named account for every person;
• authentication belonging to that account;
• delegated permissions based on actual tasks;
• no common password sent in a message or document;
• a removal process when someone changes role or leaves.

If a Microsoft account has already been exposed or compromised, the guide to regaining control of a hacked Microsoft account covers the first checks. Creating a shared mailbox does not replace securing the individual accounts.

Distinguish Full Access, Send As and Send on Behalf

Reading and sending permissions are not interchangeable. Full Access lets someone open and manage the mailbox, but it does not by itself grant permission to send from its address. I assign it to people who must read, organise or delete messages under the agreed procedure.

Send As makes the shared mailbox appear as the sender. The recipient therefore sees the generic address. Send on Behalf tells the recipient that a person sent the message on behalf of the shared mailbox. This choice is visible outside the organisation, so I validate it rather than selecting a permission by habit.

When someone must both manage messages and reply as the shared address, Full Access and Send As must be assigned separately. I record both permission lines. This separation allows reading without sending, or sending on behalf without unnecessarily granting every management operation.

• read and organise: Full Access;
• send as the generic address: Send As;
• send with an “on behalf of” indication: Send on Behalf;
• manage and send as the mailbox: Full Access and Send As, assigned separately.

Configure members, replies and sent messages

A member list is not enough. I define who may read, reply, delete, move and inspect history. Members and their permissions can be added or removed separately in the administration centre. I limit each permission to the actual requirement rather than giving everyone the same capabilities.

By default, messages sent from the shared mailbox are stored in the Sent Items of the person who sent them. Other members may then be unable to see that a reply has already gone out. A setting can also keep sent messages in the shared mailbox’s Sent Items folder.

I choose that setting according to the workflow and then test it. I also check what happens when a message is deleted, moved into a folder or handled by two people at nearly the same time. The technology must support a simple rule: who owns the message, how others know and where the reply can be found.

Verify licensing, size, archiving and external-user limits

A shared mailbox can store up to 50 GB without its own licence, but this is not a universal rule: some uses, capacities or advanced features require an appropriate licence. I check current size, expected growth, archiving needs and required features before concluding that no additional licence is needed.

Everyone who accesses the mailbox uses their own licensed Exchange Online mailbox. I also check account type: only people inside the organisation can receive direct access to a Microsoft 365 shared mailbox. If an outside provider or volunteer must participate, I do not promise identical direct access; the workflow needs a solution suited to that requirement.

I do not quote prices because plans and conditions can change. The review concerns required functions, assigned licences and documented limits rather than an assumed commercial package.

If the mailbox is approaching a limit or archiving becomes necessary, I address that requirement before the change. I do not promise that a configuration needing no mailbox licence today will cover future uses.

Test Outlook, web, mobile, receiving and sending

I test every client that will genuinely be used: desktop Outlook, web access and mobile when those workflows are planned. The objective is not merely to see the mailbox in a list, but to open folders, receive a message, reply with the correct identity and find the response in the expected place.

• receive from a controlled external address;
• open and classify as an authorised member;
• send with Send As or Send on Behalf as chosen;
• confirm the reply in the expected Sent Items;
• delete and move according to the internal rule;
• check every client that is actually used.

I also test with a user who does not have the relevant permission. An expected refusal confirms that delegation is not broader than intended. If automatic mailbox addition differs between clients, I record the method that was actually validated instead of promising identical behaviour everywhere.

To retain individual accounts without memorising more passwords, the guide to using a password manager explains how to organise access without sharing it.

Document permissions and revocation

I finish with a simple register: person, named account, role, Full Access, Send As or Send on Behalf, assignment date, approving owner and tested client. This document contains no password. It makes it possible to understand why access exists and what it authorises.

When someone changes role or leaves, I remove their permissions separately and verify the result. I do not change a common password because no common password was ever shared. I then confirm that legitimate members can still use the mailbox and that the former account can no longer open it or send with its identity.

A periodic review covers members, sending permissions, message history and clients in use. A shared mailbox remains healthy when its rights follow real responsibilities, not when an old list keeps working through inertia.

Finally, I schedule a check after each important change: someone joining or leaving, a new owner or a different reply method. The register and the tested permissions then remain aligned with reality.