Shared mailboxes and delegation

Sharing a password is not sharing a mailbox. One of those is auditable and the other is the reason you cannot tell who sent the email.

A shared mailbox

A real mailbox — support@, office@ — that several people open from their own accounts. Nobody needs its password, everyone signs in as themselves, and replies go out from the shared address.

Opening it in one click

From Mailboxes, an administrator can open a mailbox belonging to the organisation without being given its password. That is a real capability and it needs a real boundary, so:

An owner reading an employee's mailbox during an offboarding is legitimate. Doing it unseen is not. The log is not there to stop you; it is there so that it is never a secret.

Credentials are never stored

When you open a mailbox, the credential lives in your browser for that session. We transport it, we do not keep it. This is why some conveniences that would need a permanent stored credential — a server-side archive policy, for instance — do not exist here: building them would mean keeping a password we have promised not to keep.

Aliases are not mailboxes

An alias has nothing to open; it lands somewhere else. If several people need to work the same address, make it a mailbox and share it, rather than a group that scatters copies into separate inboxes where two people answer the same message.

Questions people actually ask

Can an administrator read an employee’s email?

Yes, for mailboxes in their own organisation — and it is recorded in the audit log with their name, the mailbox and the time. It is not possible silently.

Do you store my mailbox password?

No. It lives in your browser for the session. We pass it to the mail server and keep nothing.

Should support@ be an alias or a mailbox?

A mailbox, if several people work it. An alias drops copies into personal inboxes, which is how two people answer the same customer.

Next

← All guides