Send As vs Send on Behalf in Microsoft 365: What the Recipient Actually Sees

A director’s PA answers a client from the director’s mailbox. At the client’s end, the email either appears to come from the director, or it reads Sarah Lewis on behalf of Tom Grant. Which one they see comes down to the permission the PA holds. Send As makes the message look exactly as if the mailbox owner wrote it, with no sign of who did. Send on Behalf shows both names. Full Access, the permission most often granted first, lets someone open and work in the mailbox but sends nothing on its own.

The choice matters more than it looks, because it decides what the outside world is told about who is speaking.

Three permissions, three separate jobs

Permission	What the holder can do	What the recipient sees
Full Access (called “Read and manage” in the Microsoft 365 admin centre)	Open the mailbox; read, file and delete mail; work the calendar	Nothing, because it grants no right to send
Send As	Send from the mailbox’s address	The mailbox’s name only
Send on Behalf	Send from the mailbox’s address	”Delegate on behalf of Mailbox”

Neither send permission lets anyone read the mailbox, and Full Access lets nobody send. That is why the usual pattern pairs Full Access with one of the other two.

With Send on Behalf, replies go back to the mailbox, not to the person who wrote the email. A client answering the PA’s message lands in the director’s inbox, which is usually what everyone wants.

One trap is worth knowing. If someone holds both Send As and Send on Behalf on the same mailbox, Microsoft uses Send As every time. A PA deliberately set up to show “on behalf of”, who later gets Send As added while someone was fixing something else, will start sending as the director without anybody noticing the change.

For a PA or executive assistant: usually Send on Behalf

Send on Behalf is the honest default for a person’s mailbox. The client can see who they are dealing with, the PA can write in their own voice, and nobody is misled about who agreed to what. It is also what Outlook hands out when directors add a delegate themselves, because the basic delegate setup includes the ability to send on their behalf. Send As works differently: only an administrator can grant it.

There are fair cases for Send As on a person’s mailbox, such as a chair who wants board papers circulated in their own name. It should be a decision the mailbox owner makes knowingly. Every message sent that way is indistinguishable from one they wrote themselves.

For a shared mailbox: Send As

A shared mailbox exists to speak as the business. When someone replies from accounts@, the customer should see Accounts, not a name that might have left by March. Microsoft’s own guidance for shared mailboxes treats Full Access and Send As together as what the mailbox needs to work normally.

Send on Behalf is possible on a shared mailbox, and some teams like the personal touch of “Jo on behalf of Support”. Microsoft’s Exchange documentation lists it as a PowerShell-only setting for shared mailboxes, so it tends to be configured by someone who knew they wanted it rather than by accident.

If you are still deciding whether the address needs a mailbox at all, or could be an alias on an existing one, start with aliases vs shared mailboxes vs extra licences.

Where the sent copy goes

By default, a message sent as or on behalf of another mailbox is saved in the sender’s Sent Items. For a shared mailbox, that means colleagues can’t see what has been answered. We covered that version in shared mailboxes vs distribution lists vs Microsoft 365 groups, and it sat at the centre of a shared-mailbox clean-up our team did for a care charity.

The same default catches the director out. Everything the PA sends in their name is filed in the PA’s mailbox, so the director’s Sent Items has gaps. When the PA eventually leaves, the record of what was said on the director’s behalf sits in a mailbox that is about to be handled as a leaver’s.

Exchange Online has a setting for each permission. One saves a copy of messages sent as the mailbox into that mailbox’s own Sent Items. The other does the same for messages sent on behalf of it. Both are off by default, and both work on ordinary user mailboxes as well as shared ones. An administrator switches them on per mailbox, and for anyone using the new Outlook, this server-side setting is the method that works. Turn on the one matching the permission you granted.

Accountability: who actually sent it

Send As hides the author from the recipient, but not from you. Mailbox auditing is on by default in Microsoft 365. On user and shared mailboxes it records delegates’ Send As and Send on Behalf activity without anyone configuring it, so if a disputed email left the director’s mailbox, an administrator can find which account sent it.

That record depends entirely on the sign-ins behind it. The audit log names the account that acted. If the PA works by signing in to the director’s account with the director’s password, every message, deletion and rule change is logged as the director, and so is anything an intruder does with that same password. Permissions exist so that everyone works under their own name, with their own multi-factor sign-in, and the log can tell them apart.

Choosing, in one line each

• PA running an executive’s inbox and diary: Full Access and Send on Behalf, plus the on-behalf sent-copy setting on the executive’s mailbox.
• Team answering info@ or accounts@: Full Access and Send As, plus the send-as sent-copy setting on the shared mailbox.
• Someone who only needs to read or monitor: Full Access alone.

Permissions like these are quick to grant and easy to forget, so review who holds them on director and finance mailboxes once or twice a year. It is also something we set deliberately as part of a Microsoft 365 setup, instead of granting whatever makes today’s complaint go away.