PowerMTA FAQ — Technical Configuration & Operations

For a production PowerMTA deployment processing one to five million messages per day, minimum recommended specifications are: 4 CPU cores (8 recommended), 8 GB RAM (16 GB recommended for environments with large retry queues), 100 GB disk space with a separate disk or volume for the PowerMTA spool directory (SSD strongly preferred — spool I/O is the primary bottleneck at high queue depths), and a 1 Gbps network interface. The operating system should be CentOS 7/8, RHEL 7/8, or Debian 10/11. Ubuntu is supported but less commonly used in production high-volume deployments. File descriptor limits must be increased well beyond system defaults — ulimit -n should be set to 65535 or higher, configured in /etc/security/limits.conf and reflected in the systemd service file if running PowerMTA as a systemd service.

PowerMTA's source IP configuration is managed within virtual-mta blocks in the main configuration file (config.conf). Each virtual-mta defines a name, a source IP address (or address range), and optionally a specific sending domain. The virtual-mta-pool directive groups multiple virtual-MTA definitions for round-robin or other distribution strategies. Source IP selection per destination domain is controlled through domain blocks, where the route and virtual-mta-pool directives map specific destination domains to specific IP pools. For example, all Gmail-destined traffic can be routed through a Gmail-specific virtual-mta-pool, while Outlook traffic routes through a separate pool with different connection limits. This per-domain routing is the mechanism for ISP-specific traffic isolation at the MTA layer.

DKIM signing in PowerMTA is configured per domain using the dkim-sign directive within domain blocks or within virtual-mta blocks for domain-specific key assignment. Each dkim-sign directive specifies the key file path, signing domain, selector, and canonicalization method. For multi-domain environments, the recommended approach is a directory-based key structure (e.g., /etc/powermta/dkim/domain.com/selector.pem) with PowerMTA configuration referencing the selector and domain dynamically. Key rotation without delivery interruption follows a specific sequence: (1) generate the new key pair, (2) publish the new public key in DNS under a new selector while leaving the old selector active, (3) update PowerMTA configuration to sign with the new key, (4) verify signing with the new key using a test message and DKIM header inspection, (5) remove the old DNS selector record after the DNS TTL has expired. Attempting to remove the old DNS record before TTL expiry will cause DKIM validation failures for messages in transit that were signed with the old key.

PowerMTA's bounce processing is controlled by bounce-processor configuration and the bounce pattern database. Inbound bounce messages are received by PowerMTA's built-in SMTP listener (configured via the smtp-listener block for bounce reception) and classified against PowerMTA's pattern matching engine. Hard bounces (permanent failures — 5xx response codes indicating invalid address, domain does not exist, mailbox does not accept mail) trigger immediate suppression of the recipient address through the unsubscribe mechanism. Soft bounces (temporary failures that exceeded maximum retry age) are classified separately. The bounce pattern database (bounce-patterns.conf or the built-in pattern set) maps specific response text patterns to bounce categories. Custom bounce patterns can be added for ISP-specific bounce message formats not covered by the default database. Bounce data can be written to a log file or piped to an external processing script via the bounce-pipe directive for integration with list management systems.

Per-domain connection limits in PowerMTA are set within domain blocks using the max-smtp-out directive (maximum simultaneous outbound SMTP connections to that domain) and the smtp-pattern-list directive for response-adaptive throttling. For Gmail, production deployments typically use 5–15 simultaneous connections per IP, with the exact value determined by monitoring deferral rate response. Microsoft Outlook requires more conservative limits — 3–8 connections per IP — and is more likely to apply connection-level rate limits that PowerMTA must respect via the max-msg-rate directive. The max-conn-rate directive controls connection establishment rate (connections per second) separately from the concurrent connection count. For new IP addresses in warming, both max-smtp-out and max-conn-rate should be set to conservative values and adjusted upward as warming progresses and deferral rates confirm ISP acceptance. The retry-after directive controls the minimum delay before a new connection attempt following a deferral for a specific recipient domain.

PowerMTA's retry behavior is primarily controlled by three directives within domain blocks: retry-after (minimum time before the first retry following a temporary failure), max-smtp-retries (maximum number of delivery attempts before classifying as a permanent failure), and expire-after (maximum age of a message in the delivery queue before generating a bounce). For minimizing retry pressure at Gmail and Microsoft, recommended conservative values are: retry-after 15m (fifteen minute minimum between retries — the PowerMTA default of 10 minutes is too aggressive for high-volume operations), exponential backoff via retry-multiplier (not a standard PowerMTA directive — this is achieved through custom retry-after schedules or via the pmta-accounting pipe to an external controller), and expire-after 2d (two day maximum queue age, reducing to four to eight hours for time-sensitive campaigns). The hold-domain directive allows an operator to manually pause delivery to a specific domain — this is the manual intervention mechanism for situations where automated retry logic is producing adverse signals and delivery needs to be paused while the cause is investigated.

PowerMTA's accounting log is configured via the acct-file and acct-smtp-file directives, with field selection controlled by the acct-smtp-format or custom pipe format. For a complete per-message delivery analysis suitable for ISP response tracking and deliverability monitoring, the accounting record should include: etype (event type — delivery, bounce, or transient failure), orig (message ID), bounceCat (bounce category classification), dsnStatus (DSN status code — the three-part X.Y.Z code from the RFC 3463 response), dsnDiag (full ISP diagnostic message text — critical for identifying novel deferral codes), vmtaName (the virtual-MTA used, which identifies the source IP), destDomain (destination domain), dlvSourceIp (actual source IP used for the delivery attempt), and timestamps for both message receipt and delivery event. The dsnDiag field is the most operationally important — it contains the full text of the ISP response that determines whether a deferral is a simple rate limit or a reputation-related signal requiring review.

IPv6 delivery in PowerMTA is configured by adding IPv6 addresses to virtual-MTA blocks alongside or separately from IPv4 addresses. The smtp-source-host directive accepts both IPv4 and IPv6 address formats. However, mixed IPv4/IPv6 pools require careful design because ISPs treat IPv6 sender reputation differently from IPv4. Gmail and Microsoft weigh domain reputation more heavily for IPv6 senders than IP reputation — an unwarmed IPv6 address on a domain with established reputation will generally perform better than an unwarmed IPv4 address. Conversely, IPv6 addresses from new prefixes that have no sending history at all may encounter stricter filtering at ISPs that have limited data on the sending organization's IPv6 range. A separate virtual-mta-pool for IPv6 addresses, with separate domain block configuration that allows monitoring IPv6-specific delivery performance independently from IPv4, is the recommended design. This allows IPv6 performance to be evaluated and adjusted without commingling its signals with the IPv4 pool's reputation data.

Automated blacklist monitoring for PowerMTA deployments is typically implemented as an external process that queries blacklist DNS zones at regular intervals (every one to four hours for production environments) and triggers PowerMTA configuration changes when a listing is detected. PowerMTA itself does not include native blacklist monitoring — the integration is via the pmta command-line tool's ability to modify virtual-MTA status (pmta hold virtualMtaName) and the ability to update configuration files with a reload. When a sending IP is listed on Spamhaus — whether SBL (Spamhaus Block List), XBL (Exploits Block List), or PBL (Policy Block List) — the response sequence matters: (1) immediately remove the listed IP from active sending using pmta hold, (2) identify the listing type and cause using the Spamhaus lookup tool, (3) for SBL listings, correct the sending practice that caused the listing before requesting removal, (4) submit the delisting request through Spamhaus's removal process — automated delisting is available for SBL if the sending behavior has demonstrably changed. Attempting delisting without correcting the underlying behavior results in re-listing within days.

FBL processing in PowerMTA involves receiving complaint messages at a designated address and piping them to a processing script via the pipe directive in a domain block for the FBL sender's domain. ISPs that support SMTP-based FBL delivery (Yahoo, Comcast, and others using the ARF — Abuse Reporting Format — standard) send complaint messages to a configured address. PowerMTA receives these messages and forwards them to the processing script, which extracts the original message ID from the complaint and suppresses the complaining recipient. For Microsoft JMRP (Junk Mail Reporting Program), the setup is separate from PowerMTA configuration: registration occurs through Microsoft's JMRP enrollment portal, which requires providing the sending IP ranges and a complaint processing email address. Complaints arrive via email in ARF format at the registered address. Processing these complaints into PowerMTA's suppression list requires extracting the X-HmXmrOriginalRecipient header from the complaint message — this header contains the actual complaining recipient address, which Microsoft hides in the To: header of the complaint for privacy. A script that reads JMRP complaints, extracts X-HmXmrOriginalRecipient, and adds the address to PowerMTA's suppression database completes the integration.

A 421 4.7.0 response from Gmail indicates that Gmail is refusing new SMTP connections from the sending IP, typically due to one of three conditions: (1) the IP has exceeded Gmail's current connection rate limit for its reputation level, (2) Gmail has detected a pattern associated with spam or unwanted mail from this IP, or (3) Gmail's infrastructure is temporarily congested (less common, usually affects all senders rather than specific IPs). The 4.7.0 code specifically — rather than 4.3.0 (which typically indicates simple connection throttling) — suggests Gmail is applying a reputation-related rate limit rather than a generic load management response. The correct operational response is: (1) immediately review Google Postmaster Tools for the sending domain's spam rate — a 421 4.7.0 pattern combined with a spam rate above 0.1% indicates an active reputation problem, (2) reduce sending volume to Gmail and increase retry intervals in PowerMTA configuration, (3) do not increase connection attempts in response to this error — doing so worsens the situation, (4) if the spam rate in Postmaster Tools is below 0.08%, the 421 4.7.0 pattern may be volume-related rather than reputation-related, and a more gradual volume reduction with extended retry intervals is appropriate.

Traffic separation by type in PowerMTA requires a routing decision point that identifies traffic category and directs messages to the appropriate virtual-mta-pool before delivery. There are three implementation approaches: (1) Header-based routing: The sending application adds a custom header to each message (e.g., X-Traffic-Type: transactional or X-Traffic-Type: marketing). PowerMTA's smtp-pattern-list within a queue block reads this header and assigns the message to the appropriate virtual-mta-pool. (2) SMTP port-based routing: The sending application connects to different SMTP ports on the PowerMTA server — for example, port 25 for transactional and port 587 for marketing. PowerMTA's listener configuration assigns incoming connections on each port to a specific virtual-mta-pool. (3) Recipient domain routing: For organizations where traffic type correlates with destination (unusual), domain blocks can route specific destination domains through specific IP pools. Header-based routing is the most flexible and is the recommended approach for most deployments, as it does not require infrastructure-level changes when routing decisions change and provides the cleanest audit trail in PowerMTA's accounting log.