Delegate Access vs Shared Mailbox vs Send As in Outlook

Outlook delegate access, a shared mailbox, and Send As permission all solve "let someone else handle this mail" — which is exactly why people use the wrong one. Each has a different owner, a different setup path, and a different default for where sent mail actually lands, and getting that wrong is the single most common cause of the classic complaint: I sent it, and now I can't find it anywhere.

The short version. Delegate access is an Outlook-level permission the mailbox owner grants, folder by folder, for their own calendar and inbox — no admin ticket needed. A shared mailbox is a separate mailbox object with its own address and its own Sent Items folder, provisioned by an admin for a team. Send As, and its quieter cousin Send on Behalf, is the permission layered on top of either one that decides what the recipient actually sees in the From line.

If you're one executive with one assistant managing your own inbox and calendar, you want delegate access. If you're running a team address like support@ or sales@, you want a shared mailbox with Send As. Reverse them and the failure mode is almost always the same one: sent mail saved to the wrong Sent Items folder, or to no folder anyone thinks to check.

Delegate access, shared mailbox and Send As at a glance#

Two of these are permissions you're granted. One is a mailbox object you're granted access to. Here's the three side by side before the detail.

Two defaults explain most of the support tickets that follow from these three. Delegate access defaults to Send on Behalf, which is transparent but changes the From line in a way people don't expect the first time they see it. A shared mailbox defaults to filing sent mail with whoever pressed send, not with the shared identity — which is the missing-sent-items complaint covered below. Neither default is a bug. Both are just easy to miss until the day a sent message goes looking for a Sent Items folder that doesn't have it.

Where delegate access wins#

Delegate access is built for exactly one shape: a single owner and one or two people who manage that owner's own mailbox, not a shared identity. It's set from File > Account Settings > Delegate Access in classic Outlook, and the owner assigns a separate role — Editor, Author, Reviewer or none — to each folder: Calendar, Tasks, Inbox, Contacts, Notes. An owner can hand over the whole calendar while keeping the inbox untouched, or open both.

New Outlook moved the setup screen — it now lives under the owner's own account permissions rather than the classic File menu — but the model underneath hasn't changed. It's still an owner-granted, folder-level permission that never touches the Exchange admin center at all.

That granularity is the point. An executive assistant who only ever needs to book meetings doesn't need to see the inbox at all, and delegate access is the only one of the three mechanisms that lets the owner draw that line themselves, without waiting on IT.

Calendar delegation specifically carries its own permission for free/busy detail and for proposing new times on the owner's behalf, separate from whatever's granted on the inbox. That's why an assistant can often manage a calendar fully while having no inbox access at all — the two are deliberately independent settings, not one combined switch.

In practice this is an assistant booking travel and meetings from the owner's calendar, triaging the inbox before the owner reads it, or answering routine scheduling mail entirely on the owner's behalf. None of that needs the mailbox to have its own identity — it stays, unambiguously, the owner's own mailbox.

The other advantage is transparency by default. When a delegate sends from the owner's account, Outlook shows "Assistant on behalf of Owner" in the From line unless someone has separately granted Send As. Recipients always know a real person other than the owner is handling the reply — useful anywhere the appearance of who's typing actually matters, from board correspondence to client relationships.

One real limit: delegate access doesn't scale past a couple of people well. Every additional delegate is another manual grant, another set of folder permissions to remember, and none of it is visible to an admin auditing who can act as whom across the tenant. Past two or three people, that opacity is itself the argument for a shared mailbox instead.

Where a shared mailbox wins#

A shared mailbox exists because a team address needs to outlive any one employee. support@, sales@, careers@ — these need a consistent history, a consistent Sent Items folder, and access that an admin can grant or revoke in one place when someone joins or leaves, rather than one owner manually re-delegating to a new hire.

It also doesn't cost a license on its own, under the standard storage limit Microsoft sets for shared mailboxes — everyone who accesses it already has their own paid seat, and the mailbox itself rides for free. That changes only if the mailbox needs its own sign-in credential, which some OAuth-only third-party tools require and which does need a license.

A shared mailbox also keeps a clean paper trail independent of any single person. Full Access permission lets every team member open it, read the same threads, and see the same history — which matters for offboarding: revoke one person's Full Access and the mailbox, its history, and everyone else's access are completely unaffected.

It also supports rule-based routing an individual inbox rarely needs — forwarding by keyword to whoever's on shift, applying categories per team member, assigning threads. Delegate access assumes one owner reading their own mail; a shared mailbox assumes nobody in particular is the permanent reader.

Worth stating plainly, because it trips people up: Full Access to a shared mailbox lets someone read and manage it, but not send from it. Sending needs Send As or Send on Behalf granted separately — an admin has to add both if the team is expected to both work the mailbox and reply as it.

It also scales the way a growing team actually grows: adding a fourth or fifth person is one more Full Access grant, not a renegotiation of anyone's existing setup, and every one of them reads and sends from the same consolidated Sent Items once the shared-copy setting is turned on — so no one's individual mailbox becomes the accidental record of what the team sent.

What each one costs#

None of these three is a separately priced product, so there's no vendor page to quote a number from — but the packaging shape is still worth knowing before you provision anything.

Delegate access and Send As / Send on Behalf cost nothing beyond whatever license the mailbox owner already holds. They're permissions, not seats, and granting one doesn't consume another license anywhere in the tenant.

A shared mailbox is included at no extra cost with most Microsoft 365 business and Exchange Online plans, up to a per-mailbox storage limit Microsoft sets and has revised before. Check the current limit in the Microsoft 365 admin center or on Microsoft's own shared-mailbox documentation rather than trusting a number printed on any third-party page, this one included — it's exactly the kind of figure that goes stale between when it's written and when you read it.

The one place cost sneaks back in: if the shared mailbox needs its own sign-in (some third-party integrations require this to authenticate as the mailbox directly rather than through a delegated user), Microsoft requires assigning it a standard paid license like any other mailbox.

None of the specific numbers here — the storage limit, the license price, or whether a sign-in credential is required — is worth memorizing, because Microsoft has changed at least one of them within the last two years. Treat the admin center as the source of truth, not this paragraph or any other page that quotes a figure without a date attached.

One baseline is easy to miss: none of this works without at least one paid Exchange Online-enabled license already active somewhere in the tenant. Delegate access, a shared mailbox and Send As are all things you configure once a mailbox exists — they don't create the mailbox hosting capacity in the first place.

Who each one is genuinely for#

The fastest way to pick is to ask who owns the address the mail goes out from, and whether that ownership should ever change without a manual re-grant.

None of this has to be a permanent choice, either. It's common to start with delegate access for a fast-growing role, then graduate to a shared mailbox once a second or third person needs the same access and an admin wants a central place to see who has it. The signal to switch is almost always the same one: needing to answer "who can currently send as this address" faster than checking each person's Outlook individually.

• One executive, one or two assistants, managing the exec's own calendar and inbox: delegate access. Self-service, granular by folder, done in minutes.
• A small team sharing one department address — support@, careers@, sales@ — that outlives any individual on it: a shared mailbox with Full Access and Send As granted to the team.
• A team that wants clarity, not concealment, about who's actually replying: layer Send on Behalf onto delegate access instead of Send As, so recipients see both names.
• A compliance-heavy org that needs retention holds, DLP policies or journaling on the team address: still a shared mailbox — those controls live in the Exchange admin center regardless of which client anyone reads the mail in.
• Anyone managing dozens of delegate relationships by hand and losing track of who can act as whom: that's the sign delegate access has been stretched past its shape, and it's time for a shared mailbox instead.
• A person who inherited an old delegate relationship from someone who's since left the company: audit it. Delegate access doesn't expire on its own, and a stale assistant relationship from a former employee is exactly the kind of permission a security review finds a year too late.
• Someone covering for one person temporarily — parental leave, a medical absence, a sabbatical: delegate access again, and revoke it the day they're back, rather than leaving an open-ended grant nobody remembers to close.
• A new hire who needs to be productive on a team address from day one, with no dependency on any one existing employee's schedule: shared mailbox, granted as part of onboarding rather than delegated from a colleague who'll eventually be one more person to untangle from the setup.

A third option, honestly#

None of the above is something AI Emaily replaces. Delegate access, a shared mailbox and Send As are Exchange Online permissions, and they still have to be granted — by the owner or an admin — before any email client, ours included, can do anything with the mailbox. We don't touch admin-side permissioning, and we don't touch retention holds, DLP policies or journaling on a shared mailbox; those stay exactly where they are, in the Microsoft 365 admin center, regardless of which client reads the mail.

What we add sits on top, once the permission already exists: a unified inbox that shows the owner's personal mail and any delegated or shared mailbox they already have access to, side by side, with AI drafting and triage running against each identity the same way. It's a client layer, not a permissions system — it inherits whatever Microsoft already granted rather than replacing it.

Concretely: if you already have delegate access to a manager's inbox, or Full Access and Send As to a shared mailbox, connecting both to AI Emaily surfaces them as separate views with the same triage and drafting the rest of your mail gets — not a merged stream that hides which identity a message actually belongs to. We keep the identities visibly separate on purpose, because collapsing "sent as me" and "sent as the team" into one undifferentiated inbox is exactly the confusion this whole comparison exists to prevent.

To be direct about disclosure: we build AI Emaily, so take that as advocacy, not neutral advice. And to be direct about scope: if your whole need is a five-person team sharing a support@ address with an accurate Sent Items folder, Outlook's own shared mailbox plus Send As is the complete answer. You don't need a different client for that — ours included.