Sending one million or more messages per day in PowerMTA requires a different configuration philosophy than lower-volume deployments. System-level parameters that are irrelevant at 100,000 messages per day become critical bottlenecks at 1 million. This guide covers the specific configuration changes required for high-volume environments.
Contents
System-Level Configuration for High Volume
# /etc/sysctl.conf — network tuning for high-volume SMTP net.core.somaxconn = 65535 net.core.netdev_max_backlog = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_fin_timeout = 15 net.ipv4.tcp_tw_reuse = 1 fs.file-max = 2097152 # Apply: sysctl -p # /etc/security/limits.conf — high file descriptor limits pmta soft nofile 131072 pmta hard nofile 131072 root soft nofile 131072 root hard nofile 131072 # PowerMTA global config — workers for high volume workers 8 # Set to number of available CPU coresPool Architecture
IP Pool Architecture for 1M+ Daily Volume
# To send 1M messages/day to Gmail with reasonable ISP limits: # Gmail with HIGH reputation: ~800 msg/hour per IP (conservative) # 1M per day = ~42,000/hour needed # Required IPs: 42,000 / 800 = ~53 IPs for Gmail alone # Practical architecture for 1M+ daily: # Gmail pool: 8-12 IPs (supports 200K-350K Gmail messages/day) # Microsoft pool: 6-8 IPs (supports 150K-200K Microsoft messages/day) # Yahoo pool: 4-6 IPs (supports 100K-150K Yahoo messages/day) # EU ISP pool: 4-6 IPs (supports 100K-150K EU ISP messages/day) # Transactional pool: 2 IPs (dedicated, low volume, high priority) # Total: 24-34 IPs for 600K-1M daily across major ISPs # High-volume domain block configurationScale Monitoringvirtual-mta-pool gmail-pool # 10 IPs max-smtp-out tuning 10 # HIGH reputation only max-conn-rate 2/s # 2 connections per second per IP max-msg-rate 800/h # Conservative for stability max-msg-per-conn 1000 # Maximize session efficiency retry-after 15m mx-rollup gmail.com
Monitoring at Scale — Key Metrics
# High-volume monitoring requires automated alerting, not manual dashboard review # Key metrics to monitor every 5 minutes: # 1. Per-ISP high deferral rate diagnosis (accounting log format) # 2. Total queue depth monitoring (pmta show queue) # 3. Messages delivered per hour (pmta show counters) # 4. Spool disk utilization (df -h /var/spool/pmta) # 5. File descriptor usage (cat /proc/$(pgrep pmta)/limits) # Daily metrics: # 1. Google Google Postmaster Tools integration spam rate and reputation tier # 2. Microsoft Microsoft SNDS filter status per IP # 3. Hard bounce rate (bad-mailbox bounces / total sends) # 4. FBL configuration complaint count # Alerting thresholds at 1M+ daily: # Queue depth > 500K: production delivery problem # Gmail deferral > 3%: reputation issue developing # Hard bounce > 1%: list quality action required # Any IP RED in SNDS: stop that IP immediately # Capacity planning monitoring pmta show counters | grep "messages.*hour" > /var/log/pmta/throughput-$(date +%H).logSpool Tuning
Spool Directory Tuning for High I/O
# High-volume spool directory requirements: # At 1M msg/day: ~11,600 messages/hour = ~3 messages/second through spool # Each message: 1 write (queue) + 1 read (deliver) + 1 delete = 3 IOPS per message # Total IOPS: ~9/second at 1M/day (manageable on any SSD) # At 10M/day: ~90 IOPS (NVMe SSD recommended) # Spool directory configuration spool-dir /var/spool/pmta # Mount spool on dedicated NVMe SSD # /etc/fstab entry: # /dev/nvme0n1p1 /var/spool/pmta ext4 defaults,noatime,nodiratime 0 0 # noatime: don't update access time on reads — significant I/O reduction # nodiratime: don't update directory access time # Monitor spool I/O iostat -x 1 5 /dev/nvme0n1 # Spool cleanup: PowerMTA manages spool automatically # Verify auto-cleanup is working: spool should not grow indefinitely watch -n 60 'du -sh /var/spool/pmta'FAQ
Frequently Asked Questions
Million-Message-Per-Day Infrastructure Requirements
Sending 1M+ messages per day to Gmail requires approximately 4-6 fully warmed dedicated IPs (assuming ~200,000-250,000 msgs/IP/day). Each IP needs valid PTR, DKIM signing configuration, SPF coverage, and independent reputation monitoring. The infrastructure supporting this volume needs: NVMe SSD spool (minimum 200GB), 16GB+ RAM, 8+ CPU cores, and at least 1Gbps network connectivity. Queue processing threads should be set to match CPU count; smtp-service-threads to 3-4× total max connections.
Operating PowerMTA at production scale?
We manage PowerMTA environments for high-volume senders — configuration, IP warming schedule, daily reputation monitoring, and incident response. Fully managed, no self-service.
