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

The symptom: one password, five people, no idea who sent what

Walk into almost any small or mid-sized company and ask who has access to info@ or sales@. The honest answer is usually: everyone who has ever needed it, going back years. The password lives in a spreadsheet, a sticky note, or a shared document called 'passwords - do not share' that gets shared anyway. Former employees can often still log in. Nobody can say with certainty who answered a particular customer email, because the sent folder shows one identity: the mailbox itself.

This is not a dramatic failure. It is a quiet, ordinary habit that most office managers inherited rather than designed. But it creates real gaps: no audit trail, no easy way to remove one person's access without resetting it for everyone, and a password that is, in practice, permanent.

Why this happens: the shared mailbox was never built for shared use

The root cause is simple. A shared mailbox like info@yourcompany.com is still, technically, one mailbox with one login. When a company sets it up the easy way, usually the first way that worked, it creates a single account and hands the credentials to whoever needs to reply. That is quick to set up and painful to maintain.

The alternative, which both Microsoft 365 and Google Workspace actually support, is to give each person their own named account and grant that account delegated access to the shared mailbox. The shared mailbox itself does not need its own separate password at all. Each colleague logs in with their own identity, sees the shared inbox as a folder or a separate view, and sends mail "on behalf of" or "as" the shared address. Every message carries a trace of who actually handled it.

Most companies never do this because nobody walks them through it at setup time. A new starter needs access to sales@ today, so somebody just gives them the shared password. It is the path of least resistance, and it compounds every year a new person joins.

The fix: permissions per person, not one password for everyone

The fix does not require new software. It requires setting the shared mailbox up correctly, once, and documenting who has access. Concretely, ask for (or ask your IT provider for) the following setup:

• A shared mailbox that is not a personal login. It exists as a resource, not as an account someone signs into directly.
• Named individual access. Each colleague who needs info@ or sales@ gets that mailbox added to their own account, using their own password and their own two-step verification.
• Role-based permissions. Some people only need to read and reply (support staff), others need to send as the address (account managers), and some need full control to manage folders and rules (the team lead). These are three different permission levels, and good shared mailbox setups treat them as such.
• A visible sent trail. When someone replies from a shared mailbox, the system should show which person sent it, either in the message header or in an internal log the administrator can check.
• Instant revocation. When someone leaves the company, removing their access to the shared mailbox should take one click, with zero impact on anyone else using it. Nobody resets a password and re-shares it with four remaining colleagues.

If you are setting this up in Microsoft 365, this means creating a shared mailbox object (not a licensed user mailbox) and granting "Full Access" and "Send As" permissions per person through the admin centre. In Google Workspace, it typically means a Google Group configured as a collaborative inbox, with delegation handled per member. Both work, but both require someone to configure it properly rather than falling back on a shared login.

In Binadit Workspace, shared mailboxes work the same way by design: info@ or sales@ is set up once, and every colleague is granted access with their own account and their own permission level, from read-only to full send-as rights. There is no separate password for the shared address to leak, forget, or pass around on a sticky note.

How to validate the fix actually worked

Once a shared mailbox is reconfigured this way, check a few concrete things rather than assuming it is done:

• Log in as each team member and confirm they can see and use the shared mailbox without entering a separate password.
• Send a test reply from the shared address from two different personal accounts, and check that the message headers or admin log show which person actually sent each one.
• Ask IT to remove one person's access as a test, and confirm the mailbox keeps working normally for everyone else, with no reset and no new password distributed.
• Check two-step verification is enforced on every individual account that has access, not just on an old shared login that may not even support it properly.
• Review the permission list once a quarter. The real test of whether this was done right is whether, six months later, you can still list exactly who has access to info@ and why.

None of this requires special monitoring tools. It requires an admin panel you can actually read, and five minutes once a quarter to look at it.

How to prevent this from creeping back

The fix tends to hold if two habits are in place. First, make shared mailbox access part of the standard onboarding and offboarding checklist, the same list that covers laptop return and building access. Second, make sure nobody can quietly revert to a shared password out of convenience, for example because a new hire needs access urgently on a Friday afternoon and someone just hands over the login "for now." That "for now" is how the old habit comes back.

It also helps to pick a mail platform where shared mailboxes with individual permissions are the default, not an advanced feature buried three menus deep. This is one of the smaller but telling differences between office software built around convenience and office software built around actually knowing who did what.

There is a second, larger reason this matters for European companies, beyond tidiness: where that mailbox data lives and which law governs it. Microsoft 365 and Google Workspace are products of US companies, Microsoft Corporation and Google LLC. Under the US CLOUD Act, enacted in March 2018, a provider under US jurisdiction can be required to disclose data in its possession, custody or control "regardless of whether such communication, record, or other information is located within or outside of the United States." A European data region setting decides where the bytes sit, not which country's courts can reach them. We go into this in more detail in our background article on keeping email GDPR compliant over time, and in our piece on weighing staying versus moving for regulated firms.

None of this means Microsoft or Google build bad products. They do not. The issue is jurisdiction, not quality. GDPR's Chapter V requires a valid legal basis, such as an adequacy decision or standard contractual clauses, before personal data moves outside the European Economic Area, and Article 48 is explicit that a foreign court order does not by itself make that transfer lawful. The legal mechanisms meant to bridge this gap have had a rocky history: Safe Harbor was struck down in 2015, Privacy Shield was struck down in 2020 after the Court of Justice found that US surveillance law gave EU citizens no effective remedy, and the current EU-US Data Privacy Framework, adopted in July 2023, is itself under challenge at the Court of Justice at the time of writing, following an appeal filed at the end of October 2025. Asked under oath in June 2025 whether Microsoft France could guarantee that French citizens' data would never be handed to the US government without explicit French authorisation, Microsoft's own director of public and legal affairs answered "non, je ne peux pas le garantir", while noting it had not happened so far. Both halves of that answer are worth sitting with.

Getting the shared mailbox right, and the rest of your office with it

Fixing info@ and sales@ properly is a half-day job on most mail platforms, and it is worth doing regardless of which provider you use. But if you are already reviewing how your company handles shared mailboxes, it is a natural moment to ask the bigger question: where does the rest of your daily work, mail, calendar, files, documents, meetings, actually sit, and under whose law.

Binadit Workspace is built by Binadit B.V. in Rotterdam, a wholly Dutch-owned company with no foreign parent, running every server itself in data centres in the Netherlands. It covers mail with properly configured shared mailboxes, calendar, contacts, Drive, Office documents, Meet video calls and Book scheduling, all under your own domain with a single login. Because Binadit is Dutch and operates its own infrastructure, the US CLOUD Act does not apply to it. If you are weighing a European alternative to Google Workspace or a Microsoft 365 alternative for your team, you can compare the specifics at our Microsoft 365 comparison or our Google Workspace comparison, or simply ask for a demo and a quote. One fixed contact, who knows your setup, answers.