Executive Summary: Production-ready PowerMTA configuration guide for high-volume bulk mail: virtual-mta streams, domain-macro definitions, max-smtp-out, rate-limit, and accounting file logging.
PowerMTA’s configuration file controls every aspect of high-volume email delivery: how many concurrent connections each IP makes to each ISP, which IP addresses different message streams use, how DKIM signing is applied, how bounces are classified and acted upon, and how the system behaves when ISPs throttle or block traffic. A misconfigured PowerMTA can bottleneck throughput, damage IP reputation through over-aggressive connection behaviour, or fail to process bounces — making it impossible to maintain list hygiene at scale. This guide covers the core configuration structure, per-ISP delivery tuning, DKIM integration, bounce management, and the monitoring setup required to operate PowerMTA in production.
PowerMTA Delivery Performance — ISP Throughput with Tuned vMTA Config
Configuration File Structure
PowerMTA’s primary configuration file is located at /etc/pmta/config (path may vary by installation). Unlike Postfix’s separate main.cf and master.cf files, PowerMTA uses a single hierarchical configuration with nested block structures:
# /etc/pmta/config — basic structure
# Global settings
host-name mail.yourdomain.com
smtp-listener 0/0:25
# License
license /etc/pmta/license
# Logging paths
log-file /var/log/pmta/pmta.log
log-rotate-size 200M
# Virtual MTA definitions
<virtual-mta vmta-main>
smtp-source-ip 203.0.113.10
ehlo-hostname mail.yourdomain.com
</virtual-mta>
# Per-ISP delivery policies (domain blocks)
<domain gmail.com>
max-smtp-out 10
max-msg-per-connection 100
</domain>
# Accounting (bounce and delivery logging)
<acct-file /var/log/pmta/acct.csv>
records d
record-fields d timeLogged,orig,rcpt,vmta,jobId,dlvStatus,dsnStatus,dsnDiag
</acct-file>Server Identity and Basic Settings
# /etc/pmta/config — global settings section
# Hostname used in EHLO and logging
host-name mail.yourdomain.com
# SMTP listener — 0/0:25 = all interfaces, port 25
# For injection-only (relay): listen on localhost only
smtp-listener 127.0.0.1:25
# For receiving messages from external campaign systems
smtp-listener 0/0:25
# Injection port (where your email platform injects messages)
# Use a non-standard port to separate injection from MTA-to-MTA
smtp-listener 0/0:587
smtp-smarthost-port 587
# Maximum queue size
max-queue-size 500M
# Worker threads
smtp-server-threads 30
smtp-client-threads 200
# Postmaster address (receives FBL reports and admin messages)
postmaster postmaster@yourdomain.com
# Log settings
log-file /var/log/pmta/pmta.log
log-rotate-size 200M
log-rotate-count 10Virtual MTA: Stream Isolation
Virtual MTAs (vMTAs) are the core stream isolation mechanism in PowerMTA. Each vMTA has its own IP address, its own delivery queues, and its own per-ISP connection behaviour. Messages injected with a specific X-Binding or X-VirtualMTA header route to the named vMTA.
<virtual-mta name="client-acme">
<smtp-source-host>203.0.113.10</smtp-source-host>
<domain-key name="acme" domain="acme.com" path="/etc/pmta/keys/acme.pem"/>
<max-smtp-out>10</max-smtp-out>
<max-msg-rate>200/h</max-msg-rate>
</virtual-mta>
<domain name="gmail.com">
<max-smtp-out>10</max-smtp-out>
<smtp-pattern-list name="gmail-deferrals">
<smtp-pattern response="421*" action="defer" period="60s"/>
</smtp-pattern-list>
</domain># Stream isolation: transactional vs marketing on separate IPs
<virtual-mta vmta-transactional>
smtp-source-ip 203.0.113.10
ehlo-hostname tx.yourdomain.com
# Maximum simultaneous outbound connections from this vMTA
max-smtp-out 100
# Per-connection message limit
smtp-retries-after-shutoff 5
</virtual-mta>
<virtual-mta vmta-marketing>
smtp-source-ip 203.0.113.11
smtp-source-ip 203.0.113.12 # multiple IPs rotate across connections
ehlo-hostname mkt.yourdomain.com
max-smtp-out 80
smtp-retries-after-shutoff 3
</virtual-mta>
<virtual-mta vmta-bulk>
smtp-source-ip 203.0.113.20
smtp-source-ip 203.0.113.21
smtp-source-ip 203.0.113.22
ehlo-hostname bulk.yourdomain.com
max-smtp-out 150
</virtual-mta>
# vMTA pools allow automatic load distribution
<virtual-mta-pool pool-marketing>
virtual-mta vmta-marketing
virtual-mta vmta-bulk
</virtual-mta-pool>Your injection application (MailWizz, custom code, or any SMTP client) targets a specific vMTA by setting the X-Binding: vmta-name SMTP header when injecting messages.
Per-ISP Domain Blocks: Delivery Tuning
Domain blocks in PowerMTA configure the delivery behaviour for specific receiving domains or MX patterns. This is where per-ISP throttling is implemented — the most impactful configuration for inbox placement at scale.
# Gmail — engagement-sensitive, allow reasonable concurrency
<domain gmail.com>
max-smtp-out 10 # max concurrent connections to Gmail MXs
max-msg-per-connection 100 # messages per SMTP session
retry-after 421 4.7.0 15m # Gmail "unsolicited" throttle — wait 15min
retry-after 421 4.3.0 5m # Gmail infrastructure throttle — retry after 5min
max-msg-rate 500/m # max messages per minute to Gmail total
</domain>
# Microsoft — conservative; aggressive sends trigger 421 4.7.650
<domain outlook.com hotmail.com live.com msn.com>
max-smtp-out 5
max-msg-per-connection 50
retry-after 421 4.7.650 30m # Microsoft reputation throttle
retry-after 421 4.7.0 20m
max-msg-rate 200/m
</domain>
# Yahoo / AOL — watch for TS codes
<domain yahoo.com ymail.com aol.com>
max-smtp-out 8
max-msg-per-connection 50
retry-after 421 TS01 60m # TS01 = complaint rate issue — wait an hour
retry-after 421 TS03 15m # TS03 = connection rate — 15min then retry
</domain>
# Apple iCloud
<domain icloud.com me.com mac.com>
max-smtp-out 10
max-msg-per-connection 100
</domain>
# Conservative policy for ISPs not specifically configured
<domain *>
max-smtp-out 20
max-msg-per-connection 200
max-msg-rate 1000/m
</domain>DKIM Signing Configuration
PowerMTA supports DKIM signing natively for domains configured with private keys. The configuration maps each sending domain to its DKIM private key and selector:
# DKIM signing in /etc/pmta/config
# Method 1: Direct private key reference (simple setup)
<dkim>
domain yourdomain.com
selector mail
private-key-file /etc/pmta/dkim/yourdomain.com.private.key
header-list from:to:subject:date:message-id:content-type
canonicalization relaxed/simple
sign-hash sha256
</dkim>
# Method 2: Multiple domains with domain-key blocks
<domain-key mail._domainkey.yourdomain.com>
type DK
private-key /etc/pmta/dkim/yourdomain.com.private.key
domain yourdomain.com
selector mail
</domain-key>
<domain-key mail._domainkey.anotherdomain.org>
type DK
private-key /etc/pmta/dkim/anotherdomain.org.private.key
domain anotherdomain.org
selector mail
</domain-key>Generate 2048-bit DKIM keys for PowerMTA:
# Generate key pair
openssl genrsa -out /etc/pmta/dkim/yourdomain.com.private.key 2048
openssl rsa -in /etc/pmta/dkim/yourdomain.com.private.key
-pubout -out /etc/pmta/dkim/yourdomain.com.public.key
# Set permissions — private key must be readable by pmta user only
chown pmta:pmta /etc/pmta/dkim/yourdomain.com.private.key
chmod 600 /etc/pmta/dkim/yourdomain.com.private.key
# Get the DNS record value
openssl rsa -in /etc/pmta/dkim/yourdomain.com.private.key
-pubout 2>/dev/null | grep -v -- '---' | tr -d 'n'
# Publish this value in: mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=..."Bounce Classification and Accounting
PowerMTA’s accounting system writes delivery events (bounces, successful deliveries, FBL complaints) to CSV files for processing by downstream list management systems. The accounting configuration determines what data is captured and how often files are rotated:
# Accounting file configuration
# Bounce log — records every bounce event
<acct-file /var/log/pmta/bounce.csv>
move-interval 1h
move-to /var/log/pmta/accounting/
world-readable yes
records b
record-fields b timeLogged,bounceCat,vmta,orig,rcpt,srcMta,dlvSourceIp,jobId,dsnStatus,dsnMta,dsnDiag
</acct-file>
# Full delivery accounting
<acct-file /var/log/pmta/acct.csv>
move-interval 24h
move-to /var/log/pmta/accounting/
world-readable yes
records d
record-fields d timeLogged,orig,rcpt,vmta,jobId,dlvStatus,dsnStatus
</acct-file>
# FBL (complaint) log
<acct-file /var/log/pmta/fbl.csv>
move-interval 24h
move-to /var/log/pmta/accounting/fbl/
world-readable yes
records feedback-loop
record-fields f timeLogged,format,header_To,header_Return-Path,reportedDomain,header_X-FBLId
</acct-file>Automatic bounce suppression rules
# Automatic actions based on bounce category
<bounce-action>
type permanent
match bad-mailbox bad-domain routing-errors inactive-mailbox
action suppress
</bounce-action>
<bounce-action>
type transient
match quota-issues bad-connection
action retry
retry-after 4h
</bounce-action>
<bounce-action>
type transient
match spam-related
action retry
retry-after 6h
max-tries 3
</bounce-action>Access Control and Security
# Restrict SMTP injection to trusted sources only
# Messages can only be injected from these IPs
<smtp-server>
allow-unencrypted-plain yes # Allow password authentication without TLS for localhost
max-smtp-in 50 # Maximum incoming injection connections
</smtp-server>
# Source IP allowlist — only these IPs can inject mail
<source 127.0.0.1/8>
relay yes
</source>
<source 10.0.0.0/8>
relay yes
</source>
# All other sources — no relay
<source *>
relay no
</source>Monitoring and Management
Web monitoring interface
# Enable web management interface
<http>
port 8080
address 127.0.0.1 # Restrict to localhost; use SSH tunnel for remote access
enable-config-editing yes
</http>Essential CLI monitoring commands
# Overall system status
pmta status
# Queue depth per virtual MTA
pmta show status detail
# Per-domain delivery statistics
pmta show domain gmail.com
# Active queue depth
pmta show queue
# Inspect bounce log (last 100 lines)
tail -100 /var/log/pmta/bounce.csv | cut -d',' -f1,2,4,5,10
# Reload configuration after changes (no restart required)
pmta reload
# Flush deferred messages to a specific domain (use carefully)
pmta resume domain gmail.com
# Check suppression list
pmta show suppressed address@example.comHardware and Capacity Planning
PowerMTA’s throughput ceiling is determined by hardware, not software configuration. Key sizing guidelines:
| Daily volume target | CPU | RAM | Storage | IPs |
|---|---|---|---|---|
| Up to 500K/day | 4 cores | 8GB | SSD 100GB | 1 – 3 |
| 500K – 2M/day | 8 cores | 16GB | NVMe 200GB | 3 – 10 |
| 2M – 10M/day | 16 cores | 32GB | NVMe RAID 500GB | 10 – 30 |
| 10M+/day | Multi-server cluster | 64GB+ | NVMe RAID per node | 30+ |
The most common bottleneck at high volume is disk I/O — PowerMTA queues are disk-based. NVMe storage is effectively mandatory above 1M/day. The second common bottleneck is DNS resolution — run a local caching resolver (Unbound or Bind) so MX lookups do not serialise delivery at repeated popular destination domains.
Situation: Single PowerMTA config shared across all clients — IP reputation cross-contamination. High-complaint clients damaging low-complaint clients on shared IPs.
Action taken: Implemented vMTA architecture: each client assigned its own IP pool (2-4 IPs) and <vmta> block. Complaint rate above 0.05% triggers automatic throttling to that client vMTA.
Outcome: Cross-contamination eliminated. Top clients maintained 97%+ Gmail inbox placement even while problem clients were throttled. Compliance issues isolated and resolved per-client.
PowerMTA Production Configuration: The Key Directives
A production PowerMTA configuration for high-volume bulk email sending involves dozens of directives across global configuration, domain blocks, VMTA definitions, and queue management. The directives that have the most direct impact on deliverability performance and operational reliability are worth understanding in detail.
max-smtp-out in each domain block controls concurrent SMTP connections to that ISP from each IP in the pool. Setting this correctly for each ISP at the current reputation tier is the primary throughput optimisation lever. Gmail at High reputation: 20-25 connections per IP. Microsoft: 10-15. Yahoo: 15-20. EU ISPs (GMX/Web.de): 5-8. These values should be reviewed quarterly and updated when Postmaster Tools or SNDS shows reputation tier changes.
retry-after in domain blocks controls the retry backoff sequence for 4xx deferrals. A production retry sequence for major ISPs: first retry at 5 minutes, second at 15 minutes, third at 45 minutes, subsequent retries every 2 hours. Too-aggressive retry (retrying every 60 seconds) generates throttle pressure that ISPs interpret as flood sending; too-conservative retry (waiting 4 hours between retries) extends campaign delivery windows unnecessarily.
queue-life sets how long a message waits in the queue before being expired with a permanent failure. Production queue-life for bulk email: 72 hours. This gives enough time for ISP throttle to clear and messages to eventually deliver, while preventing indefinitely-queued messages from consuming queue resources. For transactional email, queue-life should be shorter (24 hours for most flows, 2 hours for authentication flows like password resets).
smtp-tls-mode require at the global level or per-domain ensures TLS encryption for all outbound SMTP sessions — both for compliance with Gmail/Yahoo/Microsoft requirements and for security. Per-domain exceptions with smtp-tls-mode if-available can be added for any legacy destinations known to have TLS issues, but the default should be require for all major ISPs.
Production Deliverability & Infrastructure Architecture Recommendation
Operating high-volume outbound mail streams demands rigid technical segregation. Senders cannot mix cold prospecting, transactional receipts, and mass newsletters on shared pools or unmanaged IPs. Carrier algorithms—specifically Google Postmaster spam filters and Microsoft SmartScreen heuristics—penalize unmanaged concurrency spikes and elevated bounce counts instantly. Enterprises must operate dedicated, high-performance PowerMTA or KumoMTA clusters configured with domain-level throttling, automated RFC 5965 FBL suppression loops, and dedicated bare-metal hardware.
High-Volume Sending Operations Roadmap
Step 1 (Pre-Flight Sanitization & DNS): Scrub contact databases via multi-pass syntax, MX, and disposable mailbox filters. Ensure 100% strict FCrDNS PTR and 2048-bit DKIM cryptographic alignment across all outbound IPs.
Step 2 (Wire Throttling & Stream Isolation): Configure per-destination connection caps (max-smtp-out, rate-limit) and isolate sending reputations into segregated Virtual MTAs with dedicated IPv4 addresses.
Step 3 (Automated Telemetry & Suppression): Deploy real-time pipe scripts to ingest RFC 5965 ARF abuse reports and RFC 3464 DSN hard bounces, enforcing immediate in-band suppression before the next send.
The AutoSMTP Dedicated Outreach Fleet Advantage
AutoSMTP provisions and manages enterprise-grade PowerMTA and KumoMTA clusters on dedicated bare-metal servers. Complete domain isolation, automated gas-pedal warming, and proactive deliverability telemetry.
Turnkey Dedicated Bare-Metal Clusters
Pre-configured PowerMTA and KumoMTA installations on enterprise hardware with dedicated IPv4 subnets and predictable flat pricing.
Automated Gas-Pedal IP Warming
Dynamic ramp-up algorithms that modulate hourly dispatch volume against real-time deferrals and Google Postmaster spam ratios.
Native FBL & Socket Interceptors
Automated RFC 3464 bounce ingestion, Yahoo/Outlook CFL complaint webhooks, and instant in-band suppression sync across all fleet nodes.
Strict Cryptographic Alignment
2048-bit DKIM key rotation, strict DMARC enforcement (p=reject), FCrDNS PTR verification, and automated TLS cipher hardening.
Ready for Dedicated Sending Infrastructure?
Eliminate shared pool throttle penalties and take complete control over your mail delivery with custom-tuned MTA clusters.
Deploy Dedicated MTA Fleet →