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, not the message. And bounces hurt 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 in step with mailbox count. So does the work of keeping each mailbox authenticated, warmed and within its daily cap.
Every sending domain needs its own SPF, DKIM and DMARC records, the public email authentication standards. One misconfigured domain quietly drags down 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 daily caps per account and per domain, cooldown stamps between touches, and a business-hours send window. Bounces and complaints go 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 a little differently from the last. A different person does it, on a domain registered at a different time. Nobody re-checks the ones set up six months ago. As the pool grows, send volume grows with it. So do the small inconsistencies, each one just below the level where anyone would look.

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 check they weren't changed and came from an approved sender. 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, and adding more mailboxes can't shorten it. That's the trap. When you need more capacity, you add mailboxes, but new mailboxes can't carry volume 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, "has anyone in this pool emailed this contact in the last three days?" is a database query. If the system can't answer it, the answer is no by default, and sometimes wrong.

Bounce and complaint handling. Bounces grow with volume. A pool that sends ten times more gets ten times the bounces, and each one hurts 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 daily caps per account and per domain. It writes cooldown stamps, so each contact gets a minimum gap between touches across the whole pool. It also keeps sending inside 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 weak mailboxes will sit there for good. They drag the number down by too little for anyone to notice.

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, not the message. And bounces hurt the sending reputation that everything else depends on. Copy is worth testing after you have ruled out the input.