Contents
Virtual MTA (vMTA) configuration is the mechanism through which PowerMTA maps outbound sending activity to specific IP addresses. In production environments, IP address allocation and isolation are the primary tools for reputation management — transactional email, marketing campaigns, and cold outreach must operate from separate IP pools to prevent reputation events in one traffic type from affecting others. This reference covers the complete virtual MTA and pool configuration for multi-IP production environments.
Virtual MTA Architecture
A virtual-mta block defines a sending identity: the source IP PowerMTA binds for outbound SMTP connections and the hostname presented in the EHLO/HELO command. Each virtual-mta corresponds to exactly one source IP. Multiple virtual-MTAs are grouped into virtual-mta-pools, and pools are referenced in domain blocks to route traffic for specific destination ISPs.
# Architecture overview: # virtual-mta (1 per IP) # ↓ grouped into # virtual-mta-pool (IP group for load distribution) # ↓ referenced by # domain block (per-ISP delivery configuration) # # Example: 3 IPs dedicated to Gmailsmtp-source-host 185.x.x.10 mail1.yourdomain.com smtp-source-host 185.x.x.11 mail2.yourdomain.com smtp-source-host 185.x.x.12 mail3.yourdomain.com virtual-mta gmail-ip-1 virtual-mta gmail-ip-2 virtual-mta gmail-ip-3 virtual-mta-pool gmail-pool max-smtp-out tuning 8 mx-rollup gmail.com
Single IP Virtual MTA Configuration
For environments with a single sending IP, the virtual MTA configuration is straightforward. One virtual-mta block, a single-member pool, and domain blocks referencing that pool. This is the starting configuration for new IP warming schedule — before adding additional IPs to the pool.
smtp-source-host 185.x.x.10 mail1.yourdomain.com dkim-sign domain="yourdomain.com" \ key-file="/etc/pmta/dkim/yourdomain.private" \ selector="s1" virtual-mta primary-mta # During IP warming — keep connection limits conservativevirtual-mta-pool primary-pool max-smtp-out 3 # Low during warming phase max-msg-rate 500/d # Start at 500/day, increase weekly retry-after 15m mx-rollup gmail.com
Multiple IP Pool Configuration
When multiple IPs are available, they should be allocated to pools based on destination ISP, not mixed arbitrarily. Gmail traffic should go to Gmail-optimized IPs (with Gmail-specific warming history), Microsoft traffic to Microsoft-optimized IPs, etc. Mixing traffic from multiple ISPs across the same IP pool creates competing reputation signals.
# ISP-separated IP pool architecture # Gmail pool — IPs with Gmail warming historyvirtual-mta gmail-ip-1 # 185.x.x.10 virtual-mta gmail-ip-2 # 185.x.x.11 virtual-mta gmail-ip-3 # 185.x.x.12 # Microsoft pool — IPs with Outlook warming historyvirtual-mta ms-ip-1 # 185.x.x.20 virtual-mta ms-ip-2 # 185.x.x.21 # EU ISP pool — IPs configured for GMX, T-Online, Orangevirtual-mta eu-ip-1 # 185.x.x.30 virtual-mta eu-ip-2 # 185.x.x.31 # Transactional — protected pool, minimal volumevirtual-mta trans-ip-1 # 185.x.x.40
Traffic Type Isolation: Transactional vs Marketing vs Cold
The most critical isolation decision is separating transactional email (2FA codes, receipts, account notifications) from marketing (campaigns, newsletters) and cold outreach. Transactional email must never share IPs with marketing or cold email — a complaint rate event on a marketing campaign must not affect transactional delivery.
# Traffic type isolation architecturesmtp-source-host 185.x.x.40 trans1.yourdomain.com dkim-sign domain="yourdomain.com" key-file="/etc/pmta/dkim/trans.private" selector="trans" virtual-mta trans-ip-1 smtp-source-host 185.x.x.50 mkt1.yourdomain.com virtual-mta mkt-ip-1 virtual-mta mkt-ip-2 # Routing: two injection listeners for two traffic types smtp-listener 127.0.0.1:2525 {{ default-virtual-mta trans-ip-1 }} # Transactional smtp-listener 127.0.0.1:2526 {{ default-virtual-mta mkt-ip-1 }} # Marketing # Your application sends to port 2525 for transactional, 2526 for marketing
Per-Virtual-MTA DKIM Signing Configuration
# DKIM signing can be set globally in virtual-mta or per-domain in domain block # Best practice: set in virtual-mta for global signing, override in domain block if neededsmtp-source-host 185.x.x.10 mail1.yourdomain.com # Sign with main domain key dkim-sign domain="yourdomain.com" \ key-file="/etc/pmta/dkim/yourdomain.private" \ selector="s1" \ header-list="From:To:Subject:Date:Message-ID:Content-Type:MIME-Version" # For multi-brand deployments: per-brand DKIM keyssmtp-source-host 185.x.x.60 brand-a-mail1.com dkim-sign domain="brand-a.com" \ key-file="/etc/pmta/dkim/brand-a.private" \ selector="s1"
Per-IP Accounting and Monitoring
# Monitor delivery statistics per virtual MTA pmta show vmta gmail-ip-1 pmta show vmta gmail-ip-2 # accounting log format analysis by source IP # The dlvSourceIp field in CSV accounting log shows the source IP per delivery grep "185.x.x.10" /var/log/pmta/accounting-YYYYMMDD.csv | \ awk -F, '$8 == "250" {{delivered++}} $8 ~ /^4/ {{deferred++}} $8 ~ /^5/ {{bounced++}} \ END {{print "IP 185.x.x.10 — delivered:", delivered, "deferred:", deferred, "bounced:", bounced}}'
Frequently Asked Questions
Operating PowerMTA at production volume?
We manage PowerMTA environments for high-volume senders — configuration, IP warming, daily reputation monitoring, and operational response. Fully managed. No self-service.
