Operating Since 2015
Pool architecture is what separates a small sender's flat IP list from a production-grade deployment. The right design isolates traffic types so that one stream's reputation problems do not contaminate the others. The principle is simple: transactional email cannot afford to share placement risk with marketing email, and cold outreach cannot afford to share IPs with either.
Most senders implement this poorly on first deployment. The common mistake is to allocate all available IPs into one pool and route everything through it because PowerMTA's default behaviour is round-robin. That works at low volume; it produces compounding reputation damage above 500K/month, because the highest-complaint stream (usually marketing or cold) drags down placement for the lowest-complaint stream (transactional).
Pool Architecture by Traffic Type
The pool layout below reflects what production senders run after the first reputation incident teaches them why isolation matters. Two transactional IPs is the floor — one is not enough because IP-level deferral or maintenance leaves no fallback for business-critical mail.
| Pool | Traffic | IPs | Max Volume/Day | Why Separate? |
|---|---|---|---|---|
| Transactional | OTP, password reset, order confirm | 2–3 | <100K | Business-critical; must not be affected by marketing events |
| Marketing | Newsletters, campaigns, promotions | 5–10+ | 200K–2M | Main volume; separate reputation from transactional |
| Cold/Outreach | B2B prospecting | 2–4 | <100K | Higher complaint risk; must not contaminate warm IPs |
| Reactivation | Win-back campaigns to inactive users | 1–2 | <50K | Higher complaint risk from inactive segments |
PowerMTA Pool Configuration
The configuration syntax below is the production minimum. The per-IP virtual-mta block names the source IP and its HELO/EHLO identity (which must match PTR for authentication consistency). The pool groups the IPs that share routing. The per-domain block applies provider-specific tuning — max-smtp-out=8 for Gmail HIGH reputation is the relevant 2026 figure documented elsewhere in the operational notes.
Pool Monitoring
Pool-level monitoring covers the aggregate but misses single-IP issues. Per-IP monitoring catches individual problems before they spread. Both views matter; reporting tools that only show pool averages produce dangerous blind spots.
- Monitor each pool's aggregate deferral rate separately (not combined)
- Monitor each IP individually — average can hide single-IP problems
- If one IP shows elevated deferral: remove from pool with pmta reload; investigate separately
- SNDS status per IP checked daily — Yellow/Red on one IP triggers immediate investigation
- When IP recovers (Green SNDS + <5% deferral for 5 days): return to pool
Pool Sizing Rules
The rules below come from production experience across the CSE fleet in 2025-2026. The 300K-500K per IP figure assumes warmed IPs at HIGH reputation; new or recovering IPs handle substantially less, often as little as 5-10% of that capacity during early warming.
- 1 IP per 300,000–500,000 daily emails (at HIGH reputation, warmed)
- During warming: 1 IP handles much less — see IP Warming Calculator
- Transactional pool: 2 IPs minimum (failover if one is degraded)
- Never add new IPs to existing pool without warming them separately first