Hundreds of mailboxes sounds like a large company, and usually it isn't. It's a letting agency with an address per property, a manufacturer with one per production line, a membership body giving every member an address, or a consultancy that decided correspondence should attach to the work rather than the worker. None of those has hundreds of employees.
Per-seat pricing makes all of it impossible, because it assumes mailboxes and people are the same thing. This page works through what hundreds of mailboxes actually costs when they aren't, what constraint replaces the bill, and where the approach stops making sense.
The Arithmetic, Plainly
At $7 per seat — Google Workspace Business Starter — five hundred mailboxes costs $42,000 a year. That number ends the conversation before it starts, which is why most businesses with this shape of need never seriously consider it.
Our plans cap counts by tier instead:
| Pro | Agency | |
|---|---|---|
| Price | $10/month | $29/month or $279/year |
| Domains | 100 | 1,000 |
| Mailboxes per domain | 300 | 1,000 |
| Ceiling | 30,000 | 1,000,000 |
| Pooled storage | 50 GB | 200 GB |
So five hundred mailboxes on Agency is $279 a year rather than $42,000. The difference isn't a discount, it's a different pricing model — you're buying capacity rather than renting seats, and the number of addresses stops being a financial decision entirely.
The Constraint That Replaces the Bill
Running hundreds of mailboxes without a per-seat bill doesn't remove all limits; it moves the binding one to storage, and that catches people out because they've stopped expecting a constraint at all.
Agency's 200 GB divided across five hundred mailboxes is roughly 410 MB each. For addresses receiving ordinary correspondence that's years of headroom. For addresses receiving photographs, drawings or scanned documents it's a few months, and the pool is shared, so one heavy mailbox consumes what the others were relying on.
Two things address that. Per-mailbox quotas stop any single address consuming the pool, which is the setting to configure before you provision hundreds of mailboxes rather than after somebody fills it. And the Drive add-on lifts the ceiling from $3.20 a month, which is cheaper than moving up a plan tier when storage is the only thing you need more of.
The arithmetic worth doing before you start: estimate the annual mail volume per address, multiply by the number of addresses, and compare against the pool. If the answer is uncomfortable, decide whether you need quotas, more storage, or a retention policy — all three are easier to set up first.
Provisioning Them Without Losing a Week
Creating five hundred mailboxes by hand is not a plan, and the method you choose determines whether this stays manageable.
Bulk creation takes a list and provisions the lot in one operation, which turns an afternoon into a minute. Where the mailboxes belong to actual people, setup invites are the piece that matters: each person receives a link and sets their own password, so nobody ever handles anyone else's credentials. That's covered in creating mailboxes in bulk.
Where the mailboxes belong to things rather than people — properties, machines, job numbers — there's no invite to send, and the useful discipline is a naming scheme derived from whatever identifier you already use. If somebody has to look up which address belongs to which unit, hundreds of mailboxes becomes hundreds of small confusions.
For anything ongoing, provisioning through the API means addresses get created by the same system that creates the underlying record, so the two can't drift apart.
Who Actually Reads Them
With hundreds of mailboxes this is the question people answer last and should answer first, because it changes the setup entirely.
If each address has one owner, they're ordinary mailboxes and each person logs into their own. If several people need the same address — which is usual when the address belongs to a project or a property — you want shared mailboxes with membership, so history stays with the address and access is granted rather than handed over. Those are capped per domain: five on Starter, fifteen on Pro, thirty on Agency, and that ceiling is worth checking against your count early.
If nobody reads them routinely and they exist to catch mail, the lightest arrangement is a catch-all with a small number of real mailboxes behind it. Hundreds of mailboxes that nobody opens are hundreds of things to administer for no benefit; hundreds of addresses that resolve is a different and cheaper proposition.
Where This Stops Working
Three situations where the model genuinely doesn't fit, and it's better to know now.
You need per-user software, not per-user email. If the reason you're counting seats is document editing, video calls and a directory, you're buying a productivity suite and email is incidental. Nothing here replaces that, and comparing the two on mailbox price misses what you're actually purchasing.
Every mailbox is genuinely busy. The economics assume most addresses are quiet. Five hundred people each sending and receiving all day is a different workload, and the storage pool will be the first thing to notice.
You need thousands, not hundreds. Past a few thousand active mailboxes, self-hosting starts winning on cost again, and the honest advice is to price both rather than assume hosted stays cheaper indefinitely.
Starting Without Committing
The pattern doesn't need to arrive fully formed. Provision the first fifty, run them for a quarter, and find out what you got wrong about naming, quotas and who reads what — because you will get one of those wrong, and fixing it across fifty is trivial where fixing it across five hundred is not.
What makes this possible is that the fifty cost the same as the five hundred. There's no per-mailbox meter running while you experiment, which means the pilot is free and the rollout is a decision about administration rather than budget. That inversion is the whole point: hundreds of mailboxes stops being something you justify and becomes something you organize.
