KoltrixDesigning per-mailbox permissions for a growing team
Map roles to shared mailboxes with a permission matrix, apply least access, keep billing and legal mail narrow, and set a review cadence as your team grows.
On this page(9 sections)
- Start from a principle: least access by default
- Step 1: List your mailboxes and their sensitivity
- Step 2: List roles, not people
- Step 3: Build the permission matrix
- Step 4: Handle the hard cases
- Step 5: Apply it and document it
- Step 6: Review on a schedule
- Signs your permissions need redesigning
- Bottom line
When a team is four people, everyone having access to every mailbox feels efficient. At fifteen people, it means a new sales hire can read refund disputes, a contractor can see vulnerability reports, and offboarding requires remembering every mailbox someone could touch.
Per-mailbox permissions solve this, but only if you design them deliberately. Here's a practical way to do it.
Start from a principle: least access by default
The idea is old and simple: give each person access to what they need to do their job, and no more. For email, that translates to:
- People get access to mailboxes they reply from or need to read regularly, not ones they might occasionally be curious about.
- Sensitive mailboxes have a short, named list of people.
- Access is added on request, with a reason, rather than granted by default.
- Access expires or is reviewed, especially for contractors and temporary roles.
The goal isn't secrecy for its own sake. It's limiting the blast radius when an account is compromised, reducing mistakes, and making offboarding manageable.
Step 1: List your mailboxes and their sensitivity
Write down every shared mailbox and rate how sensitive its contents are.
| Mailbox | Typical contents | Sensitivity |
|---|---|---|
| hello@ | General inquiries, partnerships, pitches | Low |
| support@ | Customer questions, bug reports, account details | Medium |
| sales@ | Prospect conversations, pricing discussions | Medium |
| billing@ | Invoices, payment failures, refund disputes, bank details | High |
| security@ | Vulnerability reports, incident details | High |
| legal@ / privacy@ | Contracts, data requests, legal notices | High |
| careers@ | Job applications, CVs, personal information | High |
High-sensitivity mailboxes contain financial details, personal information about candidates or customers, or information that could help an attacker. Those get the narrowest access.
Step 2: List roles, not people
Permissions designed around individuals become a mess as people change roles. Design around roles, then assign people to roles. A typical growing SaaS team:
- Founder / leadership
- Support
- Sales
- Finance / operations
- Engineering
- Recruiting / people
- Contractor (support or other)
Step 3: Build the permission matrix
Combine the two lists. For each role and mailbox, decide: Full (read and reply), Read (visibility without replying), or None.
| Role | hello@ | support@ | sales@ | billing@ | security@ | legal@ | careers@ |
|---|---|---|---|---|---|---|---|
| Founder | Full | Read | Read | Full | Full | Full | Read |
| Support | Full | Full | None | None | None | None | None |
| Sales | Full | Read | Full | None | None | None | None |
| Finance / ops | None | None | None | Full | None | Read | None |
| Engineering lead | None | Read | None | None | Full | None | None |
| Recruiting | None | None | None | None | None | None | Full |
| Support contractor | None | Full | None | None | None | None | None |
This is an example; your matrix will differ. A few patterns are worth keeping:
- Support doesn't need billing@. If a customer's support question involves a payment, support can ask finance or pull them into the thread. Keeping billing narrow protects bank details and refund decisions.
- Engineering leads see security@. Vulnerability reports need technical eyes quickly, but not the whole engineering team.
- Read access is useful. Sales seeing support@ helps them understand customer pain without replying in support threads. Founders often want read access to everything customer-facing.
- Contractors get the minimum. A support contractor needs support@, nothing else.
If your tool doesn't distinguish read from full access, treat "Read" as "None" and use forwarding or links for occasional visibility.
Step 4: Handle the hard cases
Some situations need a rule written down:
- Founder access to everything. Common, and often reasonable early on. Revisit it as the team grows; a founder's account is a high-value target, and two-factor authentication becomes non-negotiable.
- Cover during absences. When the only finance person goes on leave, who gets temporary billing@ access? Decide in advance, grant it for the period, and remove it after.
- Cross-functional threads. A billing dispute that becomes a support issue. Rather than widening access, pull the right person into the specific thread.
- AI assistants and connected apps. If someone connects an AI assistant to their email, it should see only the mailboxes that person can see. Check that any tool you use respects this.
Step 5: Apply it and document it
- Set up permissions to match the matrix.
- Keep the matrix in your team handbook so anyone can see who has access to what and why.
- Record exceptions with a reason and an end date.
With Koltrix, shared mailboxes have per-mailbox permissions, so you can apply a matrix like this directly: support sees support@, finance sees billing@, and adding a new teammate means picking their mailboxes rather than inheriting everything.
Step 6: Review on a schedule
Permissions drift. People change roles and keep old access; temporary access becomes permanent. A review cadence keeps it honest:
- On every role change: remove access the new role doesn't need, add what it does.
- On every departure: remove all mailbox access the same day, along with connected apps and devices.
- Quarterly: compare actual access against the matrix. Remove anything unexplained.
- When adding a mailbox: decide its sensitivity and add a column to the matrix before anyone gets access.
- When a contractor's engagement ends: remove access on the last day, not "when we get around to it."
Fifteen minutes a quarter is usually enough for a small team.
Signs your permissions need redesigning
- People ask "can you forward me that?" constantly, which suggests access is too narrow for real work.
- Nobody can say who has access to billing@ without checking.
- Offboarding requires a long checklist of mailboxes, or someone discovers months later that a former contractor still had access.
- Sensitive mail occasionally gets answered by the wrong person.
Bottom line
- Default to least access: people get mailboxes they reply from or read regularly.
- Rate mailboxes by sensitivity; billing, security, legal and recruiting should be narrow.
- Design permissions around roles in a simple matrix, then assign people to roles.
- Pull people into specific threads instead of widening access for occasional needs.
- Review on role changes, departures and every quarter.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
