Full Access vs Send As vs Send on Behalf: Outlook Permissions

Full Access, Send As and Send on Behalf get used interchangeably in IT tickets, and they are not the same permission. Full Access lets someone open a mailbox and read, file and delete what's inside — it does not, by itself, let them send anything. Send As and Send on Behalf both add sending rights, but they change what the recipient sees in the From line, which is the detail that actually decides which one you want.

This matters most on shared mailboxes — sales@, support@, info@ — where multiple people send mail that all needs to look consistent, and on executive assistants sending for a manager, where the opposite is true: the recipient should know an assistant handled it. Get the wrong one and either every message looks anonymous, or every message outs the assistant when the manager wanted it to read as their own words.

The question comes up constantly for a reason: Microsoft names two of the three almost identically, and only one of them tells the recipient who really sent the message. This post covers what each permission actually grants, what shows up in the recipient's inbox, and where you go to grant it — plus how to tell which one you already have.

Microsoft's own naming doesn't help either. "Send As" and "Send on Behalf" differ by two words, and that difference is entirely the decision of whether a customer knows a human handled their email or not.

The short answer#

Full Access opens the mailbox — inbox, calendar, contacts, folders — with full read and write control, but it grants zero sending rights on its own. It's the permission an admin hands out for shared mailbox access, and it needs one of the other two stacked on top before anyone can hit send.

Send As sends as the mailbox with no trace of the real sender in the header — the recipient sees [email protected], identical to a message the mailbox owner wrote themselves. Send on Behalf sends visibly as a delegate: the From line reads Priya Shah on behalf of Sales Team, so the recipient sees both identities every time.

If the brand voice matters more than who specifically typed it — a shared support or sales alias — grant Send As. If the reader needs to know a delegate acted for someone specific — an EA booking a CEO's calendar — grant Send on Behalf. Full Access is the baseline in both cases.

Grant more than one when the situation calls for it. Plenty of shared mailboxes run with Full Access and Send As stacked together, since neither permission includes the other, and stacking them is normal, not a misconfiguration.

Full Access vs Send As vs Send on Behalf at a glance#

The three permissions solve different problems, and none of them substitutes for another — granting one doesn't imply the others, and Exchange treats each as an independent setting. Here's what each one actually grants, what the recipient sees, and where you go to turn it on.

Read the "where it's granted" column carefully. Two of these permissions live in the same Exchange admin center panel; the third doesn't show up there at all, which is the detail behind most of the confused support tickets.

The same reply, sent three ways#

A support agent replies to the same customer ticket. What the recipient's From line shows depends entirely on which permission sent it — not on anything the agent typed.

Where Full Access wins#

Full Access is the right call whenever the job is reading and organizing mail, not writing it. Give a new sales rep Full Access to the sales@ mailbox and they can triage, file and reply to internal threads inside their own Outlook client — the shared mailbox mounts as a second set of folders automatically once access is granted.

It's also the safer default when you're not sure what someone needs yet. Full Access alone can't send a message that damages the mailbox's reputation, forge a reply, or trigger an angry customer response — the worst it enables is someone reading or misfiling something they shouldn't have. That makes it the permission to grant first, adding Send As or Send on Behalf only once a real sending need shows up.

The tradeoff is breadth inside the mailbox, not breadth of what it can do outside it. Someone with Full Access can read every message in that shared inbox, including ones a teammate expected to handle privately, and open every attachment — Exchange doesn't offer folder-level restriction inside a shared mailbox the way it does for a personal mailbox's delegated folders.

A common pattern: grant Full Access to everyone who touches the shared inbox, and layer Send As or Send on Behalf only onto the smaller group who actually needs to compose outbound mail from it. Fewer people with sending rights means fewer places a mis-sent message can come from.

Where Send As wins#

Send As is the right permission when the reader should never be thinking about who's behind the desk. A support ticket confirmation, a sales follow-up, a billing notice — these need to read as coming from the team, consistently, regardless of which agent is on shift.

Send As delivers exactly that: the recipient's inbox shows [email protected], and nothing distinguishes today's reply from one sent by a different agent last week. It's also what keeps a shared inbox's voice unified across a rotating team, which is the actual reason most companies run a shared mailbox instead of everyone CC'ing a personal address.

The cost is traceability at the message-header level. If a customer later disputes what was said, the From line alone won't tell you which agent sent it — you're relying on your helpdesk platform's internal logging, or the mailbox's own Sent Items, to reconstruct who actually wrote it.

Grant Send As deliberately, and to as few accounts as the workflow needs. It's the permission most likely to get requested "just in case" and then never revisited.

Where Send on Behalf wins#

Send on Behalf is the right permission whenever the recipient has a legitimate reason to know a delegate was involved. An executive assistant scheduling on a CEO's behalf, a chief of staff covering a manager's inbox during travel, a nurse triaging a doctor's messages — in each case, hiding the delegate would be the wrong call, not just a missed nicety.

The From line does the disclosure automatically: Jordan Lee on behalf of Alex Chen. The recipient knows exactly who typed the message and whose authority it carries, in one line, without anyone having to explain it in the body text.

The limitation that trips people up is where you go to grant it. For a personal mailbox, the owner sets this up themselves in Outlook, under Account Settings → Delegate Access — no admin ticket required. For a shared mailbox, it's the opposite: Send on Behalf isn't exposed in the Exchange admin center at all, so IT has to run a PowerShell command, Set-Mailbox -GrantSendOnBehalfTo, to turn it on.

Two permissions that sound alike end up granted through two completely different paths depending on the mailbox type, and that mismatch is the single most common reason a help-desk ticket says "I asked for Send on Behalf and nothing happened."

How to tell which permission you actually have#

Outlook doesn't label these permissions anywhere in its interface, so the fastest way to find out what you have is to test it directly.

1. 1

   Check whether the mailbox even appears

   Open Outlook and look for the shared mailbox in your folder list. If it's not there, you don't have access yet — that's a Full Access request, not a sending one.

2. 2

   Try composing from the shared address

   Start a new message and click From. If the shared mailbox isn't selectable, you have Full Access (or nothing) but no sending rights — you can read, not send.

3. 3

   Send yourself a test message

   Send one message from the shared address and check the From line on the copy you receive. [email protected] alone means Send As; Your name on behalf of [email protected] means Send on Behalf.

4. 4

   Ask an admin for the definitive answer

   Have an admin run Get-MailboxPermission and Get-RecipientPermission in Exchange Online PowerShell. Outlook's own display can lag a permission change by a few hours, so a live test can briefly show the wrong result.

5. 5

   Name the exact permission when you request one

   Ask for "Send As on sales@" or "Send on Behalf of alex@," not "access to the shared inbox." The vague version is how people end up with Full Access and still can't send.

6. 6

   If it's still wrong, check for a stale cache

   Outlook and Exchange Online can take a while to reflect a new permission. Close and reopen Outlook, or test from Outlook on the web, before assuming a grant didn't work.

What it costs, and where it's granted#

None of these three permissions carries its own price — they're access controls inside Exchange Online, not features you buy separately. What you do pay for is the mailbox they're attached to.

A shared mailbox is free to create and doesn't need its own license, but it's capped at 50 GB unless you license it. Assigning it an Exchange Online Plan 2 license, or covering it under a Microsoft 365 E3 or E5 subscription, raises the ceiling to 100 GB.

Granting the permissions is a console or PowerShell action, not a purchase — but who's allowed to grant them differs by mailbox type. On a shared mailbox, Full Access and Send As are admin-only through the Exchange admin center's mailbox delegation panel; Send on Behalf is admin-only through PowerShell, as covered above. On a personal mailbox, the owner can hand out Send on Behalf themselves through Outlook's Delegate Access, with no admin involved at all.

To audit what's already granted, an admin runs Get-MailboxPermission -Identity <mailbox> for Full Access and Get-RecipientPermission -Identity <mailbox> for Send As. There's no single report that shows all three permission types across every mailbox in one place.

Verify the current mailbox size limits and license requirements on Microsoft's own shared mailbox documentation before you plan a rollout around them. Microsoft has revised these numbers before, and a figure you read in a blog post six months ago is not a guarantee of what's true in your tenant today.

Who each permission is genuinely for#

Matching the permission to what the recipient needs to know — not just to the sender's job title — is what keeps this simple in practice.

• Full Access — anyone who reads, files or manages a shared mailbox without composing new outbound mail: a new hire still ramping up, an auditor doing a mailbox review, a manager spot-checking a team inbox.
• Send As — support and sales teams where the brand's voice needs to be indistinguishable message to message, and where a helpdesk platform already tracks who handled what, independent of the email header.
• Send on Behalf — assistants, chiefs of staff and covering colleagues where the recipient has a real reason to know a delegate is involved, and hiding that would read as evasive rather than polished.
• Full Access plus Send As together — the common shape for a genuine team mailbox, where multiple people both manage the inbox and send from it under one shared voice.
• Neither, on a personal mailbox — if someone just needs to see your calendar or triage your inbox while you're out, Full Access-equivalent delegate access with sending turned off is usually enough. Skip sending rights entirely until someone genuinely needs to send.

A third option, honestly: what changes once the permission exists#

None of this changes if you switch which mail client you use to send. Full Access, Send As and Send on Behalf are Exchange-level permissions, and any client — including ours — inherits whatever an admin already granted in the tenant. A mail client can't grant itself Send As, and it's worth saying plainly, because it's the wrong place for a product to overreach.

Where a client does matter is what happens once the permission already exists. A shared support mailbox with Send As granted to six agents is exactly the scenario where a draft gets sent in the wrong voice, or where nobody remembers who replied to what — the From header won't tell you, as covered above.

AI Emaily's shared-inbox handling keeps every draft in Copilot mode until a person approves it, and logs who approved and sent each message in an audit trail that survives the fact that a Send As header gives you nothing. Autopilot can take over narrower, repeatable replies once a team trusts the pattern, but sending under a shared address always stays a deliberate, logged action either way. That's a client-side answer to a problem the permission itself creates, not a substitute for the permission — we build AI Emaily, and this is the part of the job that's actually ours to do.

If your team already has Send As or Send on Behalf sorted out at the admin level, and the real pain is coordinating who replies to what inside a shared inbox, that's worth a look. It won't change what Exchange grants; it changes what happens in the minutes after.