The usual way to give somebody a mailbox is to create it, choose a password, and send them both. Everyone knows that's wrong and nearly everyone does it, because the alternative has historically been more work. Setup invites remove the excuse: the administrator never chooses a password, and nobody ever has to share passwords over email or chat.
This page covers how invites work, why the decision to never share passwords matters more than it appears, and what it means for two-factor and for offboarding.
Why You Should Never Share Passwords, Even When Nothing Goes Wrong
The reason to never share passwords starts with the obvious risk, interception. A password in an email or a chat message sits in at least two mailboxes indefinitely, is searchable, and survives every backup. Anyone who later gains access to either account finds it — NIST's guidance has recommended against transmitting secrets this way for years.
The subtler problem is that it never gets changed. The theory is that the user sets their own password on first login; the practice is that they keep the one you sent, because it works and nothing forces the change. Months later the administrator still knows a working credential for somebody else's mailbox, which quietly breaks any claim that actions in that mailbox were the user's.
That last point is the one that matters for anything contested. If two people know a password, nothing done through that account can be attributed to either of them with confidence. Arrangements where nobody has to share passwords aren't only safer — they're the precondition for the audit trail meaning anything.
How Invites Let You Never Share Passwords
The administrator creates the mailbox without a password at all. The system emails the intended user a link, they follow it, and they choose their own. At no point does a credential pass through anyone else's hands.
The credential therefore never exists in a form anyone else has seen. There's nothing in a sent-items folder, nothing in a chat history, and nothing for the administrator to forget they know.
Invites can be issued individually or in bulk, which is the difference between this being a nice idea and a usable one. Provisioning forty mailboxes for a new client means forty invites in one operation rather than forty passwords to generate, record and transmit — the bulk side is covered in creating mailboxes in bulk.
Two-Factor Is the Second Half
Choosing to never share passwords closes one gap and leaves another: a password only the user knows is still a password that might be weak or reused.
Two-factor closes that second gap. It's enrolled by the user in webmail settings rather than during the invite, so it's a separate prompt and a separate habit — which means adoption depends on you asking for it rather than on the flow forcing it.
So ask at the point you send the invite, and ask again a week later. The mailbox security page in the dashboard shows you which mailboxes have two-factor active and when it was confirmed, so chasing the gaps is a list rather than a guess.
Insist on recovery codes at the same time. Because an account owner cannot clear a mailbox's second factor from the dashboard, a user who loses both their device and their codes needs a support ticket — the whole picture is in resolving a 2FA lockout.
How the Administrator's Job Changes
Choosing to never share passwords mostly makes the administrator's job smaller, with one adjustment.
You stop being the keeper of credentials, which removes an entire category of request. "Can you remind me of my password?" becomes a reset the user performs themselves. You also stop being the person who must be trusted, which is a genuine relief when handling mailboxes for clients rather than colleagues.
The adjustment is that you can no longer log into somebody's mailbox to check something. That's uncomfortable the first time and correct every time — if the business needs access to correspondence, the answer is a shared mailbox with membership, not an administrator knowing a user's password. Those are different arrangements with different accountability, and conflating them is exactly what the practice of not sharing passwords is meant to prevent.
The Cases That Still Need Care
Two situations need a little thought rather than being switched on and forgotten, and both are worth checking on a schedule rather than trusting to memory.
Users who never complete the invite. A mailbox sitting unclaimed is a mailbox nobody is reading, and mail may be arriving at it. Invites expire, which is correct, but somebody should be checking that the intended person actually completed setup rather than assuming.
Addresses that belong to a thing rather than a person. A mailbox for a property or a job number has no user to invite. Those want a shared mailbox with membership from the start, so access is a list rather than a credential — otherwise you'll end up back at a shared password by a different route.
Invites Expire, Which Is How You Never Share Passwords by Accident
A setup link that stayed valid indefinitely would be a password with extra steps, so invites have a lifetime and stop working after it.
The practical consequence is that provisioning far in advance of the person actually starting produces expired links and a round of confused emails on their first morning. Send invites when people are ready to use them, and reissue rather than chase an expired one, since reissuing takes seconds.
Never Share Passwords Anywhere Else Either
Once mailbox credentials stop being passed around, the same question surfaces elsewhere, and it's worth following.
Shared logins for the storage, shared app passwords across devices, one API token used by three scripts — each has the same weakness, which is that revoking access for one party means disrupting all of them. Per-device credentials for storage solve the equivalent problem, described in syncing files across devices.
The rule generalizes: any credential known by more than one party can't be revoked for one of them, and can't attribute an action to either. Arranging things so you never share passwords isn't primarily about secrecy. It's about being able to change your mind about one person without disturbing everybody else.
