Fastmail Shared Folders vs a Shared Inbox: What Folders Don't Do
By ThinkCloud
Every team with a shared address — info@, sales@, support@ — hits the same wall. More than one person needs to work from it, and email was designed for one person.
If you’re on Fastmail, you have an answer for this: shared folders. It’s a real feature, it’s documented properly, and it’s meaningfully better than the two options most teams fall back on. So let’s start there rather than pretend otherwise.
One thing to get straight first, because it changes how you read this page: we don’t sell email. Fastmail is an email provider — that’s where your mail lives, and shared folders are one feature of it. What we make is a layer that runs on top of a provider you already have, in our case Google Workspace. So this isn’t two competing services. It’s one provider’s built-in sharing, compared with what a separate layer adds when it sits on a different provider.
What Fastmail’s sharing actually gives you
From Fastmail’s own documentation: anyone in the account can create a folder and share it with specific users, with three permission levels.
| Permission | What they can do |
|---|---|
| Can only view | Read, forward, copy, and reply to messages in the folder |
| Can make changes | Also delete mail and add messages to it |
| Can make changes and share | Also create subfolders and re-share |
And one detail that’s genuinely thoughtful — the folder owner chooses how read state works:
“If anyone reads a message, it’s marked read for everyone, or messages are seen as unread to each person until they read it.”
That last option matters, and it’s the thing most team-inbox products don’t do. On a shared password, the moment one person opens an email it looks answered to everyone else. Fastmail at least lets you turn that off.
So: shared visibility, with per-person permissions and readable state. That’s a real improvement over a shared login.
Where folders stop
Here’s the distinction that decides whether Fastmail is enough for your team.
A shared folder answers “can more than one person see this?” — the access problem.
A team inbox also has to answer “who is handling this, and by when?” — the accountability problem.
Folders don’t address the second one, and it’s worth being specific about what that costs you in practice:
- No ownership. You can give five people access to the folder. You cannot say “this one is Sam’s.” Everyone sees everything; nobody is responsible for anything.
- No state beyond read. There’s no waiting on customer, no in progress, no escalated, no closed. A conversation someone is halfway through looks identical to one nobody has touched.
- No deadlines. Nothing tracks how long a customer has been waiting, and nothing escalates when a reply is overdue.
- No reporting. You can’t answer “how fast do we reply?” or “how many are still open?” without exporting mail somewhere else and counting.
- No idea who’s replying right now. Shared read state tells you someone has read it. It doesn’t tell you Sam is typing a reply as you start yours — so two people can still answer the same email, differently.
One more practical detail from their docs: every message in a shared folder counts against the folder owner’s storage quota. Not a flaw, but worth knowing before you point five people at one inbox.
Side by side
| Fastmail’s sharing — built into your mailbox | A shared inbox — a layer on Google Workspace | |
|---|---|---|
| More than one person sees the mail | Yes | Yes |
| Per-user permissions | Yes — three levels | Yes — per mailbox |
| Per-person read state | Yes, optional | Yes |
| Who owns a conversation | Nobody | Assigned to an agent |
| Status of a conversation | Read or unread | New · In progress · Waiting · Escalated · Closed |
| Reply deadlines | None | SLA timer, auto-escalation |
| Who’s replying right now | Unknown | Live presence + composer lock |
| Internal notes on a thread | Not on the message | On the thread, invisible to the customer |
| Reporting | None | First response, resolution, per agent |
| Customer surveys | None | Optional, on close |
The left column isn’t a criticism of Fastmail — it’s what a folder is. Folders were built for organising your own mail and sharing it with a small group. They were never built to be a work queue.
And the right column isn’t a mail provider either. It’s a layer: you still need a provider underneath it, and ours happens to be Google Workspace. That distinction is the whole reason the next section exists.
Why we build on Google Workspace
One practical reason we’re Workspace-only: Google Workspace is the more mature platform for this, and it gives API access to every service we need — mail, calendar and identity — through one consistent interface.
That’s what lets a single product cover the whole conversation: who’s replying, what state a ticket is in, and booking a meeting without leaving the thread.
Fastmail supports open standards thoroughly, but its services are reached through a mix of different interfaces rather than one consistent API. Building on top of that is possible; it’s simply less direct, and there is noticeably less tooling around it.
We’d rather do one platform properly than two of them half-well.
Where this leaves a Fastmail team
This is the part most comparisons skip, so here it is plainly: our product runs on Google Workspace. You cannot add it to a Fastmail account.
That’s not a marketing choice, it’s an architectural one. A shared inbox isn’t a plugin that talks to your mail server — it’s built on the platform underneath: the identity, the mail API, the threading model. Ours uses Google’s domain-wide delegation and Gmail’s thread IDs, because those are what make ownership and status possible on a per-conversation basis.
So for a Fastmail team, the honest question isn’t “which shared inbox should we add?” It’s “do we want to move our email?”
Moving the mail is the part we handle
Migrating is what teams are most nervous about, and it’s the part we do most often — from Gmail, Exchange, Fastmail, on-premise, Dropbox, OneDrive. We bring it in programmatically, at scale.
It arrives as a validated copy: everything is copied across and checked, your originals stay exactly where they are until you’ve confirmed it landed, and nothing is deleted to “prove” the migration happened. If something looks wrong, the original is still there.
That covers the parts people forget — calendar, contacts, and the shared addresses themselves.
Then the shared inbox goes on top
Once you’re on Workspace, it’s the next layer: the same addresses you have today, now with an owner and a status on every conversation, reporting, and no shared password.
We migrate teams onto Google Workspace so they can use the shared mailbox.
Data migration to Google Workspace — or book a 30-minute demo and we’ll show it running on a live inbox.