How many Google inboxes should you put on one domain?

Google Workspace does not cap the number of users you can put on a domain in any way that a cold email sender would ever reach. Add a fourth, a tenth, a fiftieth, and the platform creates them. So the question is not what Google allows. It is how many sending accounts a domain can carry before the domain itself becomes the problem.

We cap it at three per domain. That is our policy, not a Google restriction, and it is worth stating plainly because the distinction changes what you do when you need more volume.

Why the number on a domain matters at all

Reputation is scored at several levels at once, and the levels are not equally durable. Receiving filters keep a profile of the individual sending address, but the more consequential profile is the one attached to the domain, because the domain is what SPF, DKIM and DMARC all authenticate against.

The mailbox is an address. The domain is the identity. Replacing a mailbox changes nothing that a receiver is scoring.

This is why the count on a domain is a real decision rather than an administrative one. Every sending account on a domain is contributing to the same reputation record, and every complaint any of them collects lands on the same record. The accounts are not independent, and treating them as though they were is the mistake.

It is also why deleting a mailbox is not a remedy. If the domain has picked up a complaint history, a fresh mailbox on that domain inherits it on its first send, because the authentication a receiver checks resolves to the domain, not to the account.

What happens when a domain is loaded with sending accounts

Two things, and they compound.

The first is concentration. A domain that has just been registered, has no website traffic, publishes fresh DNS, and suddenly has twelve accounts all sending outbound to strangers does not look like a business. It looks like what it is. The pattern receivers associate with abuse is not "many mailboxes" in general, it is many mailboxes with no other history, all sending cold, all on a domain nobody has ever received legitimate mail from.

The second is blast radius. However many accounts are on a domain, they share one fate. When the domain’s reputation goes, every account on it goes at the same moment, regardless of which one attracted the complaints.

The middle column is why people load a domain: it is more capacity for one registration. The right-hand column is the bill, and it arrives all at once. A domain has a working life, and a sending plan should assume it ends rather than hoping it does not.

The failure also does not usually announce itself. Placement drifts from the inbox to Promotions to spam while the sequencer keeps reporting delivery, so a loaded domain tends to be discovered through a reply rate that has quietly gone to zero across every account at once. The deliverability checklist covers reading that early.

Why volume should come from more domains

If you need 150 campaign sends a day there are two routes, and they produce the same number and nothing else in common.

The second route also fails more gracefully in a way the table does not show. Domains do not burn simultaneously, so a pool of four gives you warning: one starts slipping, you retire it and register a replacement while the other three keep sending. A single loaded domain gives you no warning and no partial state. It works, and then it does not.

There is a testing argument too. Independent domains let you vary copy, list segment or sending pattern and attribute the difference, because the reputations are not pooled. On one domain every experiment is confounded by every other.

This is the structural difference between the two platforms we sell. Microsoft reaches volume by filling one domain: 100 inboxes at 3 sends each is 300 a day on a single registration. Google reaches the same place by adding domains. Neither is a statement about which delivers better, and we have not measured a placement difference between them. It is a statement about where the capacity comes from, and it changes the shape of the plan.

Planning a pool from a target volume

The arithmetic is short. At 15 campaign sends per inbox per day and 3 inboxes per domain, a Google domain carries 45 campaign sends a day.

1. Take your target daily campaign sends.
2. Divide by 15 to get the inbox count.
3. Divide the inbox count by 3 to get the domain count, rounding up.
4. Add a spare domain, because one will be in warm-up or retirement at any given time.

Those are inbox subscription figures at $3 per inbox per month. Note that the domain count rounds up, so 10 inboxes needs 4 domains rather than 3.33, and the fourth domain is only carrying one inbox until you grow into it. Working backwards from conversations rather than from a send target is set out in Gmail sending limits for cold email.

The cost consequence, stated honestly

More domains is more registrations, and that is a real cost rather than an accounting detail. A domain is $12 once if we register it for you, in your name, and it is yours either way.

Registration is not the whole cost. Each domain is its own DNS work, its own SPF, DKIM and DMARC records, its own 24 hours of blocklist quiet after registration, and its own warm-up before campaign volume starts. A ten-domain pool is ten of each of those, which is why the honest lead time from nothing to a first campaign is weeks rather than days.

Against that, one burned domain costs the registration, the warm-up weeks, and whatever the pipeline would have produced while you waited. Spreading the same volume across more domains is cheaper than replacing a domain that was carrying all of it. That is the trade the cap is buying.

It is also the reason Google costs more per email of daily capacity than Microsoft does here: $0.20 against $0.10, because 3 inboxes at $3 on a domain is 45 sends a day where a Microsoft domain is 300 for $30. If lowest cost per daily send is what you are buying, that comparison matters more than anything about the platform.

The cap is ours, not Google’s

Worth repeating because it is the single most misreported thing in this subject. Google does not limit you to three sending accounts on a domain. Google will create a fourth, and a fortieth, without complaint. Any page telling you three is a Google rule is wrong, and it is a useful test of whether the rest of what they say is checked.

Three is where we choose to stop. A small number of sending accounts on a domain is what the deliverability guidance supports, and a fourth buys a little volume at the expense of the domain it sits on. If you need more addresses than three, the answer is another domain rather than a fourth account.

You are free to disagree with the number. What you should not do is disagree with it on the basis that Google permits more, because Google permitting it was never the question. The question is what the receiving side thinks of a domain with twelve cold senders on it and no other history, and that is decided somewhere Google has no say.