PowerMTA SMTP Listener Configuration — Ports, Authentication, STARTTLS, and Access Control

The PowerMTA SMTP listener is the entry point for all messages injected from your sending application. Correct listener configuration determines which applications can inject messages, what security requirements are enforced, and how traffic is routed to the appropriate virtual MTA pool configuration. An improperly secured listener creates an open relay — one of the most severe email infrastructure security failures.

Basic SMTP Listener Configuration

# Minimal secure SMTP listener — localhost only, no authentication
# Safe for applications running on the same server

    # Accepts connections from localhost only
    # No authentication required (localhost is trusted)
    # No TLS (localhost connections don't need encryption)


# NEVER configure a listener on 0.0.0.0:25 without access control
# This creates an open relay — PowerMTA will deliver anyone's email
# Open relays are blacklisted within hours of discovery

Authenticated Submission Listener (Port 587)

# Port 587 SMTP Submission — for applications on remote hosts
# Requires authentication and STARTTLS

    require-auth        yes         # Require SMTP AUTH credentials
    starttls            required    # Require TLS encryption before AUTH
    
    # TLS certificate (must match your hostname)
    tls-certificate     /etc/pmta/tls/fullchain.pem
    tls-key             /etc/pmta/tls/privkey.pem
    
    # Minimum TLS version (TLS 1.2 minimum for security)
    tls-min-version     TLSv1.2
    
    # Route all authenticated submissions to default pool
    default-virtual-mta-pool  default-pool


# Create SMTP authentication credentials in config
# (or configure authentication against LDAP/database)

    default-virtual-mta-pool marketing-pool

Multiple Listeners for Traffic Separation

# Traffic separation by SMTP listener — different ports for different traffic types

# Port 2525 — Transactional email (time-sensitive)

    default-virtual-mta-pool transactional-pool
    # All messages injected on this port go to protected transactional IPs


# Port 2526 — Marketing email (bulk)

    default-virtual-mta-pool marketing-pool


# Port 2527 — Cold outreach (most aggressive, separate IPs)

    default-virtual-mta-pool cold-outreach-pool


# Application configuration:
# Transactional sender → connects to localhost:2525
# Marketing sender → connects to localhost:2526
# Cold outreach → connects to localhost:2527
# No code changes required — just different SMTP connection targets

Access Control for Remote Application Servers

# If application server is separate from PowerMTA server
# Use allowed-hosts to restrict access to application server IPs


    # Only accept from 10.x.x.x range (private network)
    # Allows connection from any server in internal network


# More restrictive: specific application server IPs only

    allowed-hosts 10.0.1.50 10.0.1.51  # Application servers only
    # Connections from other IPs refused at connection level


# For highest security on public-facing port:
# Use firewall rules rather than PowerMTA access control
# iptables rule to allow only app server:
# iptables -A INPUT -p tcp --dport 25 -s 10.0.1.50 -j ACCEPT
# iptables -A INPUT -p tcp --dport 25 -j DROP

Frequently Asked Questions

Securing Injection Listeners in Production

The SMTP injection listener should never be exposed on a public IP without authentication. Restrict to localhost (127.0.0.1) or a private network interface. If remote injection is required, use STARTTLS with authentication on port 587 and restrict access by IP in the listener configuration. Test listener security by attempting an unauthenticated connection from outside your allowed IP range — it should be refused at the connection level.

Accounting Log Analysis for This Configuration

Monitor this configuration area through the PowerMTA accounting log's dsnDiag field. Filter accounting records for the specific ISP domains affected by this configuration and group dsnDiag responses by first 60 characters to identify the dominant error patterns. A deferral rate above 5% at any single ISP warrants investigation; above 15% requires immediate volume reduction and configuration review.

The dlvSourceIp field in the accounting log enables per-IP analysis within this configuration context. Comparing per-IP deferral rates identifies whether a configuration issue affects all IPs in a pool uniformly (configuration problem) or just specific IPs (reputation or IP-specific problem). This distinction determines the correct remediation path.

Calibrating to Your Current Environment

The parameter values documented in this reference are appropriate for established, warmed IPs with HIGH reputation at the target ISP. New or warming IPs, and IPs with MEDIUM or LOW reputation, require more conservative values. Move up incrementally as reputation signals confirm the infrastructure can sustain additional throughput. Review ISP-specific configuration monthly — Postmaster Tools reputation tier changes and SNDS status changes are the primary triggers.