Microsoft 365 Shared Mailboxes

A Shared Mailbox is the mailbox a team works out of together — support@, billing@, info@. Microsoft 365 gives it an address and a folder tree, but no password of its own: people reach it through their personal Microsoft accounts, and Exchange decides who may open it.

A Shared Mailbox is the mailbox a team works out of together — support@, billing@, info@. Microsoft 365 gives it an address and a folder tree, but no password of its own: people reach it through their personal Microsoft accounts, and Exchange decides who may open it.

MailDesk connects a shared mailbox the same way Outlook does — through a member's login — and that single fact explains every requirement on this page.

How it works, in plain terms

When a colleague clicks Connect Microsoft Graph (OAuth), they sign in as themselves. Microsoft hands MailDesk a token that belongs to that person. Two things then have to be true for the shared mailbox to be readable:

1. Exchange must allow it. The signing-in person needs Full Access to the shared mailbox — that is Microsoft's own permission, granted in the admin center.
2. The token must be allowed to leave its owner's mailbox. A plain Mail.Read permission only ever reaches the signed-in person's own mail, no matter what Exchange permits. Reading somebody else's mailbox needs the .Shared variant of the permission.

MailDesk also has to ask for the right mailbox. Microsoft's /me endpoint always means "the mailbox of whoever signed in" — it can never point at a shared mailbox, regardless of permissions. That is why the account form has an explicit switch: when M365 Shared Mailbox is enabled, MailDesk addresses the mailbox by its own address instead of /me.

What you need before you start

The permission to grant

Grant the Delegated permission that matches your edition. The shared variant is additional — keep the plain one as well:

Pro needs the read-write variants because it writes back to the mailbox: marking messages read, moving them, and deleting them all happen on the server. Basic never writes to the mail server, so read permission is enough.

Connecting the mailbox

1. Create the mailbox account in MailDesk as usual (MailDesk → Configuration → Mailboxes → Mailbox Accounts → New), and put the shared mailbox's address in Email Address — for example [email protected].
2. Choose the Outlook / Microsoft 365 provider and select your Graph application.
3. Tick M365 Shared Mailbox.
4. Add yourself under Users with Access and save. This step is easy to skip and it blocks everything else: mailbox administrators are not members automatically, and Connect Microsoft Graph refuses to run for a mailbox you are not a member of. Managing a mailbox and reading it are deliberately separate rights.
5. Click Connect Microsoft Graph (OAuth).
6. In the Microsoft account picker, sign in with your own account — not the shared address, which has no password and cannot sign in.

MailDesk verifies the connection before saving anything: it asks Microsoft for the shared mailbox and only stores the credentials if the answer comes back. If it does not, the error names the cause — missing admin consent for the .Shared permission, missing Full Access in Exchange, or a sign-in with the wrong account.

After connecting, the account form shows Connected Microsoft Identity — the person whose login currently carries the connection. It is worth a glance whenever something stops working: if that colleague leaves the company or loses Full Access, the connection stops with them.

Giving your team access inside MailDesk

Exchange decides who may reach the mailbox; MailDesk decides who sees it in the app. On the account form, tick Shared Mailbox and list the colleagues under Users with Access. Only those users see the mailbox in their MailDesk sidebar — Security & access rights explains the model in full.

The two settings answer different questions and are both needed:

• M365 Shared Mailbox — how MailDesk talks to Microsoft (address the mailbox explicitly, request the .Shared permission).
• Shared Mailbox + Users with Access — who in your Odoo sees the mailbox.

Sending from a shared mailbox

Reading and sending travel different roads. Incoming mail arrives over the Graph connection described above; outgoing mail leaves through the account's Outgoing SMTP Server and is independent of it. So a shared mailbox needs both: a working Graph connection to read, and valid Microsoft 365 SMTP credentials to send.

The outgoing server must sign in as the person, not as the shared mailbox. This is the single most common mistake, and its symptom is unmistakable: "5.7.57 Client not authenticated to send mail". A shared mailbox has no password, so it cannot authenticate — put the delegate's own address in the outgoing server's user field. The shared address belongs in the account's Email Address, which is what MailDesk puts in the From header.

One outgoing server can serve several mailboxes. A delegate who looks after ten shared mailboxes needs one server record, not ten — and therefore one Microsoft sign-in instead of ten, because the OAuth token is stored per server. Point all of those mailbox accounts at the same server. Incoming servers are the opposite: each mailbox needs its own, because an incoming server is the mailbox connection.

FROM Filtering is what makes sharing safe. It lists the sender addresses this server is allowed to use, comma-separated, so a shared server names every mailbox it serves — [email protected], [email protected]. A bare domain (example.com) covers all of them at once, and an empty field means "no restriction".

The one value that must not stay there is the delegate's own address. Odoo does not refuse a message whose sender falls outside the filter — it quietly rewrites the From header to the server's own login, and the mail goes out under the wrong name. MailDesk therefore refuses to save a mailbox account whose address its outgoing server may not send as, and names both the address and the two ways to fix it.

Microsoft treats reading and sending as separate permissions — Full Access to read, Send As to send under the shared address. In practice you usually have both already: adding someone under Members in the Microsoft 365 admin center grants Full Access and Send As in one step. You only need the Exchange admin center's Delegation page when the permissions were granted separately, or when you want Send on Behalf instead.

New mail arrives on a schedule, not instantly

Personal Microsoft mailboxes can be pushed: Microsoft notifies MailDesk the moment mail lands. A shared mailbox cannot. Microsoft does not offer change notifications for a mailbox reached through someone else's delegated permission, so MailDesk deliberately skips the subscription for these accounts and keeps them on scheduled synchronisation instead — registering one would only create a subscription that never fires.

In practice new mail appears within the sync interval rather than in seconds. Everything else — reading, replying, moving, deleting — behaves exactly as it does for a personal mailbox. Instant delivery for shared mailboxes would require the tenant-wide application permission model, which MailDesk does not use.

When something does not work

Outlook setup covers the Azure application itself, and Troubleshooting — setup & sync covers connection problems that are not specific to shared mailboxes.