Shared mailbox done right: info@ and sales@ without sharing a password

One password, five people, zero accountability

Quick audit: who has the password to info@ or sales@ at your company? If you're honest, the answer is probably "everyone who's ever needed it since 2019." It's sitting in a spreadsheet, a sticky note, or a doc literally named passwords-do-not-share.xlsx that gets shared constantly. Ex-employees can likely still log in. And when a customer complains about a reply, the sent folder tells you nothing, because every message is signed by the mailbox itself, not a person.

This isn't negligence. It's a default nobody questioned. But it means no audit trail, no clean way to revoke one person's access, and a password that is functionally permanent.

Root cause: shared mailboxes were never meant to be shared logins

A shared mailbox like [e-mail] is, under the hood, just one mailbox with one set of credentials. The fast way to set it up is to create a single account and hand out the login to whoever needs it. Quick to deploy, miserable to maintain.

Both Microsoft 365 and Google Workspace support a better model: give each person their own named account, then grant that account delegated access to the shared mailbox. No separate password for the mailbox at all. Each person authenticates as themselves, sees the shared inbox as a folder or view, and sends "on behalf of" or "as" the shared address. Every outgoing message carries a trace of who actually sent it.

Nobody sets this up correctly by default because nobody walks teams through it. New hire needs sales@ access today, someone hands over the shared password, and the debt compounds every year.

The actual fix

No new tooling required. Configure the mailbox properly, once:

• The shared mailbox is a resource, not a login. It shouldn't be an account anyone signs into directly.
• Named individual access. Each person gets the mailbox added to their own account, their own password, their own MFA.
• Role-based permissions, not one tier for everyone:
  • Read/reply only (support staff)
  • Send-as (account managers)
  • Full control: folders, rules (team lead)
• A visible sent trail. Headers or an admin log should show who actually sent each message.
• Instant revocation. Someone leaves, you remove their access, done. Zero impact on everyone else. No password reset and re-share ritual.

Microsoft 365

Create a shared mailbox object, not a licensed user mailbox. Grant permissions per person via admin center:

Add-MailboxPermission -Identity "[e-mail]" -User "[e-mail]" -AccessRights FullAccess -InheritanceType All

Add-RecipientPermission -Identity "[e-mail]" -Trustee "[e-mail]" -AccessRights SendAs

Full Access and Send As are separate permission grants, assign them deliberately per role.

Google Workspace

Typically a Google Group configured as a collaborative inbox, with delegation handled per member rather than a shared account.

Both platforms support this natively. The gap is almost always configuration discipline, not capability.

Validate it actually worked

Don't assume, check:

1. Log in as each team member, confirm they see the shared mailbox without a separate password prompt.
2. Send a test reply from two different personal accounts, confirm headers or admin logs show who sent what.
3. Remove one person's access as a test. Confirm the mailbox keeps working for everyone else, no reset, no redistribution.
4. Confirm MFA is enforced on every individual account with access, not just assumed on some legacy shared login.
5. Review the permission list quarterly. If you can't list exactly who has access and why, six months from now, it wasn't actually fixed.

No special monitoring stack needed. Just an admin panel you can read and five minutes a quarter.

Keep it from creeping back

Two habits matter:

• Put shared mailbox access on the onboarding/offboarding checklist, same list as laptop return and badge deactivation.
• Kill the "just give them the password for now, it's Friday" exception. That's exactly how the old habit returns.

Pick a platform where per-person permissions on shared mailboxes are the default, not buried three menus deep behind the advanced settings.

There's also a jurisdiction angle

Beyond the access-control story, there's a question of where mailbox data lives and which law governs it. Microsoft 365 and Google Workspace are run by US companies. Under the US CLOUD Act (2018), a provider under US jurisdiction can be compelled to disclose data in its possession regardless of where that data is physically stored. A European data region setting controls where the bytes sit, not which court can compel disclosure.

GDPR Chapter V requires a valid legal basis before personal data moves outside the EEA, and Article 48 states a foreign court order alone doesn't make that transfer lawful. The legal frameworks meant to bridge this have a rocky track record: Safe Harbor struck down in 2015, Privacy Shield struck down in 2020, and the current EU-US Data Privacy Framework (adopted July 2023) is under challenge at the Court of Justice following an appeal filed at the end of October 2025.

That's a separate conversation from access control, but it's worth knowing both exist.

Full writeup with more context: Shared mailbox done right

Originally published on binadit.com