PowerMTA Professional Guide

Multi-IP Deployment Design

Add source IPs without creating inconsistent routing, DNS or reputation management.

Purpose and scope

Add source IPs without creating inconsistent routing, DNS or reputation management. This chapter emphasizes stable identity, least privilege, controlled change, and measurable delivery outcomes. It separates configuration correctness from reputation and recipient-policy issues.

Operational model

Trace each message through submission identity, source policy, routing decision, VirtualMTA selection, queue, remote SMTP response, accounting record and bounce action. A change is not complete until every stage is observable and reversible.

Planning checklist

• Record the envelope sender, authenticated user, source network and intended VirtualMTA.
• Verify source IP ownership, PTR, forward DNS, HELO and signing domain.
• Define provider-specific limits only when response evidence supports them.
• Preserve a validated configuration and a rollback path before editing production.
• Confirm complaint, bounce and unsubscribe suppression paths before volume increases.

Illustrative configuration

# Illustrative structure — adapt and validate against your licensed release
smtp-listener 0.0.0.0:2525

<source 127.0.0.1>
    always-allow-relaying yes
</source>

<virtual-mta vmta-primary>
    smtp-source-host 192.0.2.10 mail1.example.com
</virtual-mta>

<domain *>
    max-smtp-out 2
    max-msg-per-connection 10
    retry-after 10m
    bounce-after 4d
</domain>

The reserved address 192.0.2.10 is documentation-only. Replace it with an assigned source IP and validate all syntax locally.

Controlled implementation

1. Export or copy the current working configuration.
2. Make one logical change and annotate its purpose.
3. Run the PowerMTA configuration test available in your installation.
4. Reload safely and watch startup, submission and delivery logs.
5. Send controlled tests to accounts you own and inspect the received headers.
6. Compare queue depth and response-code distribution before and after the change.

Failure patterns

• Routing references a VirtualMTA or pool that is not defined.
• The configured source IP is not present on the host or cannot reach the Internet.
• PTR and HELO describe different identities.
• A broad source or sender rule authorizes unintended traffic.
• Rates are increased while complaints, unknown users or temporary failures are rising.
• Queue commands are used to hide symptoms instead of correcting the cause.

Validation evidence

systemctl status pmta
ss -lntp
# Review the PowerMTA logs configured on this server
# Send one controlled test and inspect Authentication-Results, Received and Return-Path

Production standard

Document the owner, change date, expected result, rollback action and monitoring window. Treat provider limits as operational controls—not guaranteed deliverability. Authentication alignment, recipient consent, list hygiene and complaint handling remain mandatory.

Related resources