Complete PowerMTA Configuration Guide

Configuration design

Treat configuration as code: separate global settings, listeners, sources, authentication, virtual MTAs, pools, domain policies, pattern lists and logging into predictable files. Keep secrets outside downloadable examples.

Recommended file layout

/etc/pmta/config
/etc/pmta/conf.d/listeners.conf
/etc/pmta/conf.d/sources.conf
/etc/pmta/conf.d/virtual-mtas.conf
/etc/pmta/conf.d/domain-policies.conf
/etc/pmta/conf.d/patterns.conf
/etc/pmta/conf.d/logging.conf

Change control

• Keep a timestamped backup before every change
• Validate syntax before restart
• Change one policy group at a time
• Record why each rate was chosen
• Test rollback procedures
• Never publish passwords or license material

Global settings

Global directives establish service-wide behavior. Use the smallest set required, and avoid copying old configurations whose assumptions, paths or version syntax you have not verified.

Sources and listeners

Listeners define where PowerMTA accepts SMTP. Source blocks define what a connecting network may do. Relay permission should be explicit and narrow.

Virtual MTAs and pools

A virtual MTA binds delivery identity and source IP. Pools group eligible virtual MTAs. Keep HELO, PTR and source IP mapping stable, and do not rotate identities merely to evade reputation controls.

Domain policies

Provider-specific policies control concurrency, message rate, connection rate, retry behavior and backoff. Start conservative and tune from measured responses rather than generic high-volume recipes.

Validation and deployment

cp -a /etc/pmta /root/pmta-backup-$(date +%F-%H%M%S)
# Run the configuration validation command supplied by your installation
systemctl restart pmta
systemctl status pmta --no-pager

Operational review

• Queue growth by destination
• 4xx and 5xx response distribution
• Connection and TLS failures
• Complaint and unknown-user rates
• Latency from acceptance to delivery
• Disk space and accounting-log rotation