Send-on-behalf from a shared mailbox: the setup that works

Every organisation wants its correspondence going out from one official address: reservations, sales, support. Not from staff personal addresses.

The confusion everyone hits

Two very different permissions exist here, and they get mixed up constantly.

Send As makes the message appear as though the shared mailbox itself sent it. The staff member's name never shows up anywhere.

Send on Behalf marks the message as "employee on behalf of the mailbox". The recipient sees who actually wrote it, which gives you more transparency and clearer accountability.

Both are defensible. Send As looks cleaner to the client; Send on Behalf holds up better in an internal audit, and that is what I pick wherever accountability matters.

What is required technically

Start with a shared mailbox, then grant the send permission to a group. Granting it to individuals turns every new hire into an administrative task, while group membership means one step and you are done.

Automated senders follow a different path. A system needs an app registration with a specific send permission, and its secret lives in the system rather than on anyone's machine.

The traps

Replies come first. Once sending works, check where replies land: the default can route them to the employee's own mailbox instead of the shared one, and there they get lost.

Sent Items is the second surprise. A message sent on behalf may not show up in the shared mailbox's Sent Items by default, which leaves holes in the audit trail.

The last one is authentication. Whenever the sending path changes, verify your email authentication records; a sender those records do not yet cover ends up in junk.

What remains

Keep the permission on a group and the secret inside the system, and most of this looks after itself. Before you declare the job done, confirm once more where the replies land.

Related reading

• Approvals inside Teams with item-level permissions