PowerMTA SMTP test — listeners, smtp-user, port 587

PowerMTA (PMTA) is a commercial high-volume MTA for transactional and marketing email. By default it accepts injection only from 127.0.0.1 on port 25 without authentication, so remote clients cannot relay; testing submission from an external tool like SMTP Tester requires a listener, TLS, authentication, and relay permissions.

This guide covers the operator workflow: wiring up a submission listener, verifying auth and relay permissions per source IP, handshake-only testing against production, confirming VMTA assignment, and reading the transcript stage by stage, so you catch configuration mistakes before an application team goes live.

Configuring a submission listener

Add a listener directive to your PowerMTA configuration file (typically /etc/pmta/config):

smtp-listener 0.0.0.0:587

This accepts connections on port 587 from any IP. For TLS, also configure:

smtp-server-tls-certificate /etc/pmta/certs/mail.example.com.pem
smtp-server-tls-key /etc/pmta/certs/mail.example.com.key

STARTTLS is enabled by default when a certificate is present; ensure allow-starttls is not set to false.

One detail that trips people up: 0.0.0.0:587 binds to all interfaces, but PMTA also supports binding a listener to a specific IP, for example smtp-listener 10.0.5.20:587. Connections to any other address on the same box are then refused at the TCP layer, which looks identical to a firewall drop. Connection refused on a box you know is up usually means the listener is bound elsewhere; check with pmta show listeners.

After changes, apply them with pmta reload (see reload vs restart for when each applies).

Setting up smtp-user authentication

Define SMTP users that remote injectors authenticate as:

<smtp-user injector1>
  password s3cureP@ss
  authentication-method password
</smtp-user>

Then create a source block that links authenticated sessions to relay permissions:

<source {auth}>
  smtp-service yes
  always-allow-relaying yes
  require-auth true
</source>

The {auth} source matches any connection that has successfully authenticated. always-allow-relaying yes lets those sessions send to external domains (without it, PMTA only accepts mail for local domains). require-auth true means unauthenticated connections from external IPs cannot relay.

Testing auth against the configured source

Auth is a two-part match: the credential must exist in an <smtp-user> block, and the session must land in a <source> block that permits what it tries to do. A password-only test misses the second half; read the AUTH exchange in the transcript:

• The EHLO response advertises the mechanisms, for example 250-AUTH PLAIN LOGIN. A mechanism not on that line fails before the password is checked.
• A 334 challenge then 235 2.7.0 Authentication successful confirms the credential; SMTP Tester redacts the base64 credential material.
• A 535 means a credential or authentication-method mismatch. A 235 followed by 550 relaying denied at RCPT TO means auth worked but the matched source does not grant relay.

Test every <smtp-user> you hand out: it is common to copy a user block, change the name, and forget the password line or the reload.

Relay permissions per source IP

Auth alone does not grant relay in PMTA; what grants relay is the <source> block the connection matches, matched by connecting IP first, then authentication. PMTA evaluates source directives in order, so a more specific IP source placed before {auth} wins for those addresses:

<source {auth} 10.0.0.0/8>
  always-allow-relaying yes
  require-auth true
</source>

<source {auth}>
  always-allow-relaying no
  require-auth true
</source>

Authenticated connections from the application network relay to external domains; connections from anywhere else fall through to the second rule and are limited to local domains. A run from your workstation exercises a different source path than one from the application subnet; verify both.

Testing with SMTP Tester

1. Host: your PMTA server's public hostname; port 587, security STARTTLS.
2. Username: the <smtp-user> name (e.g. injector1); password from that block.
3. Auth method: PLAIN or LOGIN (both work).
4. From: any address your VMTA accepts.
5. To: an external recipient (permitted by always-allow-relaying yes on the auth source).
6. Click Run. The transcript shows EHLO → STARTTLS → AUTH → 235.

A 250 Ok after DATA with a message ID (250 Ok: queued as 11A2B-00001-00) confirms the message entered the queue; trace it with pmta show queue or the PMTA logs.

Handshake-only mode for production instances

On a production box, a full test queues a real message that can go out to a real recipient, consume sending IP reputation, and show up in your logs as an anomaly.

Handshake-only mode (Advanced settings) stops after authentication: DNS resolution, TCP connect, EHLO, STARTTLS if configured, AUTH, then a verdict. No MAIL FROM, no RCPT TO, no DATA, nothing queued. It still authenticates, so it exercises the same <smtp-user> and {auth} source matching as a real injection; it cannot verify queue acceptance, VMTA assignment, or relay permission. Use it for:

• Verifying a new <smtp-user> credential before handing it to an application team.
• Confirming a listener change took effect after a reload.
• Routine probes of production instances where a test message is undesirable.

Run the full test against staging, or against production only to verify queue acceptance and VMTA selection, to a recipient you control.

What each transcript stage means

Reading the transcript is where the diagnostic value is:

If a stage fails, everything after it never ran. Match the last successful stage against the error list below to pinpoint the directive at fault.

Testing from the application network vs localhost

Where you test from matters as much as what you test:

• From localhost (127.0.0.1, port 25, no auth): verifies injection works and the default source accepts mail (the trust path local applications use).
• From the application subnet (internal IPs, port 25 or a custom submission port): verifies the <source 10.x.x.x/...> rules your application servers match. Test this before onboarding a new app server.
• From an external network (public hostname, port 587, STARTTLS, auth): verifies the remote-submission path for third-party senders or SaaS tools.

SMTP Tester's origin is external; for internal paths, run the same test from a machine in that subnet against the internal IP.

Verifying the selected VMTA

PowerMTA routes messages through virtual MTAs (VMTAs) based on rules in <domain> and <pattern> blocks. Once a message enters the queue, the sending IP, DKIM signing, and delivery throttling come from the VMTA assignment, not from the injection port or auth user.

A 250 Ok at the end of DATA only proves the message was queued, not that it was assigned to the VMTA you expect. To confirm selection, deliver a test message and check the first Received header at the destination (added by the receiving MTA): it shows the connecting IP, which is the VMTA's source IP, for example Received: from mailout1.example.com (mailout1.example.com [203.0.113.45]). Match 203.0.113.45 against the source IP defined for the VMTA you expected; if it does not match, your vmta selection rule (in the application or a <pattern> block) did not fire.

If messages are accepted (250) but never delivered, check:

• pmta show queue: is mail stuck in a queue?
• VMTA binding: does the VMTA have a valid source IP and route?
• DNS: can PMTA resolve the recipient domain's MX records?
• Bounce logs: pmta show counters for delivery failures.

Port and listener verification

Port 25 and custom submission ports behave differently: port 25 with the default config accepts unauthenticated injection from trusted sources, while a submission port like 587 usually requires auth. Verify what is actually listening with pmta show listeners, which lists every bound address and port with its TLS state, and compare it with the EHLO response in the transcript: a submission listener advertises 250-STARTTLS and 250-AUTH PLAIN LOGIN; if those lines are missing, you connected to a different listener than intended.

A frequent mix-up: connecting to port 25 while expecting STARTTLS and auth, because that listener was left on defaults with no certificate. The transcript makes the mismatch obvious in seconds. Test additional ports (2525, 465) after listener changes, since smtp-listener directives apply per address and port.

Reload vs restart

PMTA supports two operations with different scopes and risk:

• pmta reload applies most configuration changes (listeners, smtp-user blocks, source directives) without dropping connections or the queue. Use it for auth and listener changes.
• pmta restart (or a service restart) is needed for some low-level changes and as a fallback when a reload fails validation. Connections reset and delivery pauses briefly, so avoid it during peak sending hours.

If a change does not take effect, confirm the reload succeeded first: PMTA validates the configuration and reports errors instead of applying a broken file. Then re-run the test; an auth failure right after adding a user almost always means the reload did not happen or failed validation.

Common errors

Why test before you deploy

A pre-flight test prevents polluting the things you rely on to debug later:

• Logs: a failed integration spams mail-*.log with thousands of rejected connections, burying real signals; one controlled test isolates the failure in a short transcript.
• Queues: a misrouted batch can sit retrying for hours, distorting delivery counts. Handshake-only mode queues nothing.
• Reputation: messages accepted on a production IP may actually be delivered. Keep test traffic off production IPs, or route it through a dedicated test VMTA.

How this compares to telnet and swaks

• telnet: fine for a one-off EHLO to see extensions, but it cannot do STARTTLS, and typing base64 AUTH credentials by hand is error-prone. No transcript record, no TLS diagnostics.
• swaks: scriptable, good for CI or cron probes, but requires installing a tool on the test host and composing TLS and auth flags each run.
• SMTP Tester: no installation, full handshake with credential redaction, readable per-stage transcript, certificate details. Tradeoff: it runs from the browser's network location, so for internal source-IP testing use swaks or telnet on the internal host.

Related: fixing SMTP authentication error 535 covers the 535 error in more depth, the KumoMTA SMTP test guide covers the other common self-hosted MTA, and what is an SMTP test explains the handshake stages. For port choice, see SMTP port 587 vs 465; for how transcript-based testing compares to other web-based testers, see SMTP Tester vs smtper.net.

Security notes

• Never expose an unauthenticated listener to the public internet: without require-auth true, anyone can inject spam through your server.
• Use strong passwords for <smtp-user> blocks; rotate them if compromised.
• Restrict relay by IP in addition to auth where possible (<source {auth} 10.0.0.0/8>).
• SMTP Tester redacts credentials from the transcript, so it is safe to share in tickets or team chats.
• Monitor PowerMTA's accounting and bounce logs for unauthorized injection.

Frequently asked questions

Can I test PowerMTA without sending a real message?

Yes. Handshake-only mode (Advanced settings) stops after authentication: nothing is queued and no recipient receives anything. Use the full test only to verify queue acceptance and VMTA selection.

The transcript shows 235 but delivery still fails. Why?

Authentication and relay are the injection half. Once queued, delivery depends on the VMTA's source IP, route, DNS, and the recipient's policy; the Received header at the destination shows the IP used, which should match the expected VMTA.

Why does my test get relay denied even though auth succeeded?

Relay permission comes from the matched <source> block, not authentication alone. Your connection matched a source without always-allow-relaying yes, or a more specific IP rule took precedence. SMTP Tester connects externally, so it may match different source rules than your application servers.

The transcript shows no STARTTLS extension on port 25. Is that broken?

Probably not. The default port 25 listener has no certificate, so PMTA does not advertise STARTTLS there; that is normal for plaintext injection from trusted networks. Assign a certificate or use a dedicated submission port for TLS.

Should I use pmta reload or a full restart after config changes?

Use pmta reload for listener, smtp-user, and source changes; it applies the configuration without dropping the queue. Reserve restarts for low-level changes or failed reloads, and avoid peak sending windows.