Why not only add more domains instead of more mailboxes?

You need both, and domains are the slower of the two. Each new domain starts with no sending history, so it has to be warmed before it carries volume, and each one needs its own SPF, DKIM and DMARC records set up correctly. Adding domains raises your ceiling; it does not raise it today.

Does a bigger pool make deliverability better?

It spreads volume, which helps if the alternative was overloading a few mailboxes. It does nothing about the reasons mail gets filtered, which are content, list quality and complaint rate. A large pool sending to a bad list just distributes the damage across more sending identities.

What is the first thing to fix when reply rates fall across a large pool?

Check list quality and bounce handling before you touch copy. A rising bounce rate points at the data rather than the message, and bounces damage the sending reputation that everything else depends on. Copy is worth testing after you have ruled out the input.

What breaks past 100 mailboxes

Adding mailboxes multiplies how much you can send. It also multiplies everything that has to be configured correctly, and those do not scale by themselves.

app.salescrew.io/today

The short answer

Sending capacity grows linearly with mailbox count, but the work of keeping each mailbox authenticated, warmed and within its daily cap grows with it.
Every sending domain needs its own SPF, DKIM and DMARC records, which are public email authentication standards, and one misconfigured domain quietly degrades every mailbox on it.
At a large pool size, tracking which mailbox sent to which contact and when stops being something a person can hold in their head, so cooldown and cap enforcement has to be part of the system.
SalesCrew's sender pool applies per-account and per-domain daily caps, cooldown stamps between touches, and a business-hours send window, and routes bounces and complaints straight to suppression.

The first hundred hides the problem

A small pool is forgiving. With five or ten mailboxes, one person set them all up, probably in an afternoon, and remembers what is on each one. If a mailbox starts landing in spam, it is noticeable, because it is a fifth of the operation. The daily caps are low enough that nothing gets close to a provider limit. Warmup happened once, at the start.

Scaling that arrangement does not fail dramatically. It degrades. Each new batch of mailboxes gets set up slightly differently from the last, by a different person, on a domain registered at a different time. Nobody re-checks the ones set up six months ago. The pool grows, the send volume grows with it, and the accumulated small inconsistencies grow too, just below the level where anyone would investigate.

What actually changes at scale is that the feedback loop breaks. With ten mailboxes, a deliverability problem shows up as an obvious drop. With a hundred and twenty, the same problem on eight of them is a small dip in an aggregate number, indistinguishable from a slow week.

The four things that stop scaling on their own

Authentication. SPF, DKIM and DMARC are per-domain DNS configuration. SPF publishes which servers may send for the domain, DKIM signs messages so the receiver can verify they were not altered and came from an authorised sender, and DMARC tells receiving servers what to do when those checks fail. All three are public standards, all three are per-domain, and every new sending domain needs its own set. A domain with a broken DKIM record does not fail loudly; its mail just performs worse than the rest of the pool, and in a large pool that difference is invisible in the aggregate.

Warmup. A brand new mailbox has no sending history, so receiving providers have nothing to judge it by, and volume from an unknown sender is the pattern spam looks like. Ramping takes time that cannot be compressed by adding more mailboxes, which is the trap: the response to needing more capacity is to add mailboxes, and new mailboxes cannot carry capacity yet. The pool you need next quarter has to be started this quarter.

Caps and cooldowns. Two constraints exist at once, and they pull in different directions. Each mailbox has a daily send limit it should stay under. Each contact should not be touched more often than your own rules allow, regardless of which mailbox reaches them. At ten mailboxes a person can reason about both. At a hundred and twenty, the question "has anyone in this pool emailed this contact in the last three days" is a database query, and if the system cannot answer it, the answer is no by default and wrong some of the time.

Bounce and complaint handling. Bounces are proportional to volume, so a pool that sends ten times more generates ten times the bounces, and every one of them damages the reputation of the mailbox and domain it came from. Handling them by hand is possible at small volume and not at large. This is where scaling turns a manual habit into a required piece of infrastructure.

What to put in place before the pool grows

Make the guardrails part of the system rather than part of the process. SalesCrew's sender pool enforces per-account and per-domain daily caps, writes cooldown stamps so a minimum gap between touches per contact is respected across the whole pool, and restricts sending to a business-hours window. Bounces and complaints write to suppression automatically. None of these are clever; they are the things a careful operator does by hand at small scale and cannot do by hand at large scale.

Keep a registry of what you are sending from. Every mailbox and every domain, with when it was added, which pool it belongs to, and whether its authentication records are in place. SalesCrew keeps a sender and domain registry for this, and mirrors it with Instantly for teams already running one there. The point is that "which mailboxes do we own" should be a list you can read, not something reconstructed from whoever set them up.

Watch per-mailbox numbers, not only pool aggregates. The aggregate hides exactly the problem you are looking for. If you only ever see the average, a handful of badly performing mailboxes will sit there indefinitely, dragging the number down by an amount too small to trigger anyone's attention.

And fix the list before you add capacity. More mailboxes sending to bad data produces more bounces, which produces worse reputation across more sending identities. Verification services report a point-in-time check rather than a guarantee, so bounce handling matters more than the confidence of the flag on the row. Scaling the pool amplifies whatever your list quality already is, in both directions.

Questions

Why not only add more domains instead of more mailboxes?: You need both, and domains are the slower of the two. Each new domain starts with no sending history, so it has to be warmed before it carries volume, and each one needs its own SPF, DKIM and DMARC records set up correctly. Adding domains raises your ceiling; it does not raise it today.
Does a bigger pool make deliverability better?: It spreads volume, which helps if the alternative was overloading a few mailboxes. It does nothing about the reasons mail gets filtered, which are content, list quality and complaint rate. A large pool sending to a bad list just distributes the damage across more sending identities.
What is the first thing to fix when reply rates fall across a large pool?: Check list quality and bounce handling before you touch copy. A rising bounce rate points at the data rather than the message, and bounces damage the sending reputation that everything else depends on. Copy is worth testing after you have ruled out the input.