Why not just share the password
The quickest way to let a colleague work in a mailbox seems to be passing on the password. That's exactly what you don't want. The colleague then also gets into all of that user's other services, such as OneDrive and Teams, multifactor authentication has to be shared and afterwards there's no way to tell who did what. With mailbox permissions everyone works with their own account and it stays on record who has access. Permissions can only be set within your own organization, not for users at another company.
The three permissions at a glance
- Read and manage (Full Access). The colleague can open the mailbox and read, move and delete email. This permission explicitly does not include the right to send email from that mailbox.
- Send as. The colleague can send email that looks as if the mailbox owner sent it personally. The recipient only sees the name and address of the mailbox.
- Send on behalf. The colleague can send email on behalf of the owner. The recipient then sees, for example, "Anne on behalf of Peter". That way it's visible who actually wrote the email.
The permissions are separate. Someone who needs to read and answer email therefore needs both Read and manage and either Send as or Send on behalf.
Send as or Send on behalf: which do you choose?
The choice depends on what the recipient should see. Choose Send on behalf when it should be clear that someone else is writing, such as an assistant confirming appointments for a director. That's honest towards the recipient and avoids confusion when that person later replies themselves. Choose Send as when it doesn't matter who types the email, for example for a general mailbox such as info@ or invoices@. For a general address like that, a shared mailbox is usually a better solution than a person's mailbox.
Is it only about calendars, for example an assistant who schedules meetings? Then delegate access to the calendar is often enough.
How to set it up
In the Microsoft 365 admin center go to Users > Active users and select the user who owns the mailbox. On the Mail tab you'll find Read and manage permissions, Send as permissions and Send on behalf of permissions. Via Add permissions you choose the colleague who gets the permission. Keep two things in mind:
- It doesn't work immediately. It can take up to 60 minutes for a new permission to take effect everywhere. So don't let the colleague conclude straight away that it isn't working.
- Hidden mailboxes. If the mailbox is hidden from the address book, Send as and Send on behalf don't work in the Outlook desktop app. Those permissions require the mailbox to be visible in the Global Address List.
Permissions should also go away again
In practice, temporary access often becomes permanent. The summer stand-in can still read the director's mailbox in December. So put an end date in your calendar or ticket for every permission you grant, and check who has which permissions at every joiner and leaver. Mailbox permissions are also a place where attackers can dig in after a compromised account. The audit log shows when permissions were granted and by whom.
How Floor ICT handles it
Floor ICT sets up mailbox permissions based on a concrete question: who needs to read, who needs to send and what should the recipient see. Where possible we choose Send on behalf or a shared mailbox instead of access to a personal mailbox, record per mailbox who has which permission and why, and remove temporary permissions on the agreed date. When someone leaves or is away, we arrange the handover without a password ever having to be shared.