Raising the concurrent connection limit on your MTA does not scale email. Mailbox providers apply per-IP and per-domain rate limits. If you outrun them you collect deferrals, then blocks. Throughput is a queueing problem, a reputation problem, and a list problem at the same time.
What actually constrains throughput
Your server can open hundreds of sockets. Gmail and Microsoft will not take hundreds of messages per second from a new or noisy IP. They look at the domain, the IP history, the complaint rate, and whether the recipients look like a real audience. A queue that drains faster than they will accept simply retries the same burst until you look like an attack.
Watch the 4xx class closely. A 421 or 450 with a try-again message is a brake pedal. Treating it like packet loss and retrying immediately is how you turn a slowdown into a 550 policy block.
Separate the queues
Transactional mail should not wait behind a newsletter. Use different queues, and often different IPs or subdomains, so a slow campaign cannot delay password resets. Retry 4xx with exponential backoff and jitter. Cap retries. Do not hammer a 421 with the same burst every second.
If one product team can dump a promotional send into the same daemon that handles receipts, they will, usually on a Friday. Make the split boring and obvious: different smarthosts, different credentials, different From domains.
Add IPs the slow way
New IPs need warmup. Spreading volume across ten cold addresses is worse than one warm IP. Each new address has to earn its own acceptance curve. Microsoft and Gmail will not ramp on the same schedule. If you add IPs because the current one is already listed, you are multiplying the problem instead of cleaning the list.
Keep a written map of which IP sends which stream. When a block appears, you need to know whether it is the newsletter pool or the password-reset pool before you start moving traffic around.
Application-level brakes
The MTA should not be the only place you can stop mail. Cap welcome sequences for new signups. Throttle or pause when bounce webhooks spike. Kill a campaign if complaint feedback loops fire above your threshold. Put those controls in the app that owns the audience, not only in Postfix knobs.
Dashboards that only show “messages sent” hide the failure. You want accepted, deferred, bounced, complained, and a timeline of deploys. Scaling SMTP is an operations problem: on-call, a stop button, and the willingness to use it.
A working order of operations
- Authenticate every sending domain and keep DMARC at enforcement on streams you care about.
- Split transactional and bulk before you add hardware.
- Warm each new IP against engaged recipients only.
- Raise volume in steps you can roll back in an hour.
- When deferrals cluster on one provider, slow that provider, not the whole world.
If you remember one thing: providers reward predictability. Sudden volume, mixed content on one identity, and retries without backoff are the three fastest ways to spend a dedicated IP.
Provider-specific ramps
Gmail cares about user engagement and spam-folder behavior in Postmaster Tools. Microsoft is often stricter on sudden volume from a cold IP and will 421 you with little warning. Yahoo still watches complaint rates closely. If you treat “the internet” as one pipe, you will overfill the pickiest hop and think the whole MTA is broken.
Keep per-domain concurrency caps. When Gmail defers, slow Gmail. Leave transactional Microsoft mail alone if that stream is healthy. A global panic button is useful. A global panic as the first reaction is how you create a second incident.
What to log
Store the enhanced status code, the provider, the sending IP, the campaign or message class, and whether the recipient was engaged in the last 30 days. Without that join you cannot tell a list problem from an IP problem. The weekly review is: where did acceptance drop, what changed, and did we stop in time.
