Calculate how many messages per hour your PowerMTA infrastructure can handle based on server configuration, IP count, and target ISP mix. Also get server hardware recommendations.
Infrastructure Parameters
Throughput Results
How the throughput math actually works
The formula is straightforward: messages per second per IP equals concurrent connections multiplied by messages-per-session, divided by session duration. The arithmetic is clean; the operational reality is that real PowerMTA throughput sits at 50-70% of this theoretical figure even on warmed, high-reputation IPs. The gap between "theoretical" and "production" comes from soft bounce retries consuming connection capacity, DNS resolution latency on first sends to unfamiliar domains, and per-destination throttling that produces uneven utilisation across the connection pool.
The number is still useful, but for sizing rather than forecasting. If you need to push 5M messages in a 6-hour overnight window during a Black Friday flash send, and the calculator returns 3.2M capacity for that window, you have a sizing problem that operational tuning cannot solve. You need either more IPs, faster session turnover, or a longer window. Throughput capacity is a planning input; throughput delivered is something else, dependent on reputation, recipient mix, and current state of the queue.
PowerMTA tuning parameters that drive the result
Three configuration values dominate the throughput equation, and getting them right is the difference between a server pushing 500K/day per IP and one pushing 2M/day per IP. The defaults in PowerMTA are conservative; senders running on factory defaults are routinely leaving 60-70% of throughput capacity on the table.
| Parameter | Conservative default | Production tuned | Why |
|---|---|---|---|
| max-smtp-out (concurrent connections per IP) | 2-5 | 8-12 to Gmail HIGH; 5-7 to Microsoft; 6-8 to Yahoo | Concurrent connection limit per ISP. Reputation-gated; new IPs cannot use upper end of band |
| max-msg-per-conn (messages per SMTP session) | 1-10 | 50-200 to major ISPs | Connection setup overhead amortises across messages. Going from 5 to 100 messages per connection roughly doubles throughput |
| smtp-service-threads (worker threads) | 4-8 | 4x CPU cores | Thread starvation produces queue backup at high concurrency. Modern multi-core servers benefit from much higher thread counts |
| smtp-source-host (per-virtual-mta) | (not set) | Always explicit per IP + HELO domain | Required for proper IP attribution and SPF alignment. Missing this in virtual-mta config produces deliverability problems even at correct throughput |
| queue-to (per-domain timing) | (default queue) | Per-domain queue with destination-specific tuning | Per-domain queue management lets you push 12 concurrent to Gmail and 6 to Microsoft from the same IP simultaneously |
| max-rcpt-per-msg (envelope recipients) | 1 | 1 (keep at 1) | Multiple recipients per envelope hurts engagement tracking and complicates bounce processing. Stay at 1 even when ISPs allow more |
The interaction between max-smtp-out and max-msg-per-conn deserves specific attention. At max-smtp-out=8 and max-msg-per-conn=10, you are opening a connection, sending 10 messages, closing, and opening a new one — spending 30-50% of the time on connection overhead. At max-smtp-out=8 and max-msg-per-conn=100, you open one connection, send 100 messages, then close. The throughput difference is roughly 3-4x even though concurrent connection count is the same.
Per-ISP connection limits and the published numbers
Major mailbox providers enforce concurrent connection limits per source IP because they need to protect their inbound infrastructure from abuse. The limits are not officially published in most cases, but the operational community has converged on consistent observed numbers from PowerMTA accounting logs and similar instrumentation. The table below captures the 2026 operational consensus.
| Provider | Concurrent connections per IP | Messages per session | Notes |
|---|---|---|---|
| Gmail (HIGH reputation) | 8-12 | 100-200 | HIGH-tier reputation IPs get the upper band; LOW-tier limited to 1-2 concurrent. Earned over weeks of consistent volume |
| Gmail (LOW or new) | 1-3 | 20-50 | New IPs throttled hard during warming. Going above the band causes 421 deferrals and queue backup |
| Microsoft (Outlook, Hotmail, Live) | 5-10 | 30-50 | Strictest of major providers. Microsoft prioritises IP reputation over raw concurrency tolerance |
| Yahoo / AOL | 6-10 | 50-100 | Slightly higher than Microsoft. Unified after Yahoo-AOL merger; rate-limit signals via Sender Hub |
| Apple iCloud | 5-8 | 30-50 | No published guidance. Defers aggressively when limits approached. Treats IP and domain reputation jointly |
| Microsoft 365 corporate tenants | 2-5 per tenant | 10-30 | Per-tenant filtering at customer edge; stricter than the consumer Outlook service |
| Smaller ISPs / corporate domains | 1-5 | 10-50 | Highly variable. Some apply per-IP limits aggressively; others rely on rate-per-second |
Server hardware sizing realities
The calculator's recommended server specs come from translating concurrent connection count and queue depth into hardware requirements. The math is approximate but the operational realities are concrete. Three components dominate hardware sizing for production PowerMTA deployments.
RAM scales with queue depth, not with throughput directly
PowerMTA holds approximately 2KB of metadata per queued message. A server pushing 5M messages per day with 10% in queue at any time has 500K queued messages, which is 1GB of metadata. Add 50KB per concurrent connection (3.5MB at 70 connections) and the OS overhead, and a 4-IP server pushing 5M/day needs roughly 8-16GB RAM minimum. Larger queues (longer retry windows, larger campaign sends queued ahead) push this higher.
Storage IOPS matter more than capacity
Spool I/O is the most common bottleneck for high-volume senders. PowerMTA performs roughly 4 I/O operations per message between spool write, queue management, and delivery. At 1000 messages per second, that is 4000 IOPS on the spool partition. Standard SATA SSDs handle this comfortably (10K+ IOPS sustained). NVMe becomes necessary above 5K IOPS sustained, which corresponds to roughly 1250 messages per second total throughput. Below that threshold, NVMe is overkill; above it, NVMe is mandatory.
CPU cores scale with concurrent connections, not raw volume
Each concurrent connection consumes a thread; threads scale with cores. A general rule of thumb: one CPU core per 50-75 concurrent connections. A server running 5 IPs with 8 connections each (40 concurrent) runs comfortably on 4 cores; a server running 20 IPs with 10 connections each (200 concurrent) needs 8-12 cores. Above 500 concurrent connections, you usually want to split across multiple servers rather than scale up a single one.
Common mistakes that cap throughput below capacity
- Single message per connection. The factory default in many PowerMTA installations is max-msg-per-conn=1 or 5. Production senders need 50-100 minimum to capture available throughput. The throughput improvement from raising this value is approximately 2-4x, and it is the single highest-impact tuning change for senders who have not done capacity work yet.
- No per-domain configuration. Treating Gmail, Microsoft, Yahoo, and corporate domains as the same queue means the slowest destination caps the entire send. PowerMTA's domain-block configuration is mandatory for production senders mailing mixed destinations; without it, you cannot use the available headroom on the more-tolerant destinations.
- Ignored deferral retries. Soft bounces (4xx codes from receivers) get retried by PowerMTA according to its retry schedule, and those retries consume connection capacity. A high-volume sender to a destination with aggressive greylisting can spend 30-40% of connection capacity on retries. Tuning retry intervals to back off more aggressively for repeated deferrals (rather than retrying immediately) frees capacity for new sends.
- Inadequate ulimit on file descriptors. Each connection consumes a file descriptor. The system default ulimit is often 1024, which caps total concurrent connections regardless of PowerMTA settings. Production deployments need ulimit -n set to 65536 or higher in /etc/security/limits.conf, with the corresponding fs.file-max sysctl. Skipping this step caps throughput at 1024 connections silently.
- Mixing transactional and bulk on same IPs. Transactional traffic deserves dedicated IPs because its complaint rate and bounce rate profile is different from marketing. Mixing them on the same pool means a marketing complaint spike damages transactional placement, and transactional IPs cannot be tuned for the higher throughput appropriate for bulk. Stream separation matters at the IP level, not just the domain level.