Configuring Secure SMTP in PowerMTA: Implicit TLS, Explicit TLS and SMTP Authentication

---

PowerMTA is a powerful Mail Transfer Agent (MTA) used by organisations to manage high-volume email delivery. Whether it is being used for transactional emails, marketing campaigns or application-based email submission, securing SMTP connections is an essential part of operating a reliable email infrastructure.

When integrating applications such as WordPress, CRM systems, email marketing platforms or custom-built applications with PowerMTA, administrators need to decide how those applications will connect securely to the mail server.

PowerMTA supports both commonly used SMTP encryption methods:

• Implicit TLS (SMTPS): Encryption is established immediately when the connection starts, typically using port 465.
• Explicit TLS (STARTTLS): The connection begins as a normal SMTP session and is upgraded to TLS using the STARTTLS command, typically using port 587.

In this guide, we’ll look at how to configure both methods in PowerMTA, including SMTP listeners, TLS certificates, authentication, relay permissions and practical testing.

The examples use a Linux-style PowerMTA configuration. The same underlying SMTP principles apply to Windows deployments, although certificate paths and service-management commands will differ.

1. Understanding PowerMTA SMTP listeners

Before configuring TLS, it is important to understand how PowerMTA accepts incoming SMTP connections.

PowerMTA uses the smtp-listener directive to specify which IP addresses and ports it should listen on.

For example:

smtp-listener 0.0.0.0:25
smtp-listener 0.0.0.0:2525

This instructs PowerMTA to accept SMTP connections on ports 25 and 2525 across all IPv4 network interfaces.

You can also bind listeners to specific IP addresses.

For example:

smtp-listener 192.0.2.10:25
smtp-listener 192.0.2.10:2525

This is particularly useful when a PowerMTA server has multiple network interfaces or public IP addresses and you want to control which interface accepts SMTP connections.

For our secure SMTP configuration, we will introduce two additional listeners:

Port	Connection type	Encryption
25	Standard SMTP	Opportunistic STARTTLS
2525	Custom SMTP submission	Depends on configuration
465	SMTPS	Implicit TLS
587	SMTP submission	Explicit STARTTLS

The following sections explain how to configure ports 465 and 587.

2. Preparing the TLS certificate

Before enabling encrypted SMTP connections, PowerMTA needs a valid TLS certificate and its corresponding private key.

The certificate identifies the SMTP server to connecting applications.

For example, if applications connect to:

smtp.example.com

The TLS certificate must be valid for smtp.example.com.

The certificate should:

• Be issued by a trusted Certificate Authority.
• Include the correct hostname in its Subject Alternative Name (SAN).
• Be within its validity period.
• Include the necessary intermediate certificate chain.
• Have a corresponding private key.

For the following examples, assume we have:

SMTP hostname: smtp.example.com

Certificate: /etc/pmta/smtp-cert.pem

PowerMTA’s smtp-server-tls-certificate directive specifies the PEM certificate file used for inbound TLS connections.

A typical configuration is:

smtp-server-tls-certificate /etc/pmta/smtp-cert.pem

Depending on the certificate format and PowerMTA configuration, the PEM file must contain the server certificate and corresponding private key. If the private key is encrypted, the appropriate password must also be supplied using the directive’s supported syntax.

Important: Protect the private key carefully. Restrict filesystem permissions and ensure the PowerMTA service account has access to the certificate file.

Do not expose the private key or its password in public repositories, support tickets or configuration examples.

3. Configuring Implicit TLS on port 465

Implicit TLS establishes encryption immediately when an application connects to PowerMTA.

Unlike STARTTLS, there is no initial unencrypted SMTP greeting.

PowerMTA supports this using the tls=yes parameter on the SMTP listener.

Configuration

First, configure the TLS certificate:

smtp-server-tls-certificate /etc/pmta/smtp-cert.pem

Next, configure the port 465 listener:

smtp-listener 0.0.0.0:465 tls=yes

The tls=yes parameter instructs PowerMTA to expect a TLS connection immediately.

When an application connects to port 465, the TLS handshake takes place before the SMTP greeting is exchanged.

What happens during the connection?

The connection follows this sequence:

1. WordPress or another application opens a TCP connection to port 465.
2. The client immediately initiates the TLS handshake.
3. PowerMTA presents its configured certificate.
4. The client validates the certificate.
5. The TLS session is established.
6. PowerMTA sends its SMTP greeting inside the encrypted connection.
7. The client sends EHLO.
8. PowerMTA advertises its SMTP capabilities.
9. The client authenticates.
10. The application submits its email.

Example SMTP conversation

The following is an illustrative transaction after the TLS handshake has completed:

220 smtp.example.com ESMTP service ready

EHLO wordpress.example.com

250-smtp.example.com Hello
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 SIZE 52428800

AUTH LOGIN

334 VXNlcm5hbWU6

[Base64-encoded username]

334 UGFzc3dvcmQ6

[Base64-encoded password]

235 2.7.0 Authentication successful

Notice that the SMTP server does not send its 220 greeting until the TLS handshake has completed.

Everything in the SMTP conversation is therefore transmitted through the encrypted connection.

Security considerations

For port 465:

• Always use a valid TLS certificate.
• Ensure the certificate hostname matches the SMTP hostname.
• Disable insecure TLS protocols.
• Require SMTP authentication for application submission.
• Do not permit unauthenticated relay from untrusted networks.

4. Configuring Explicit TLS (STARTTLS) on port 587

STARTTLS works differently from implicit TLS.

Instead of establishing encryption immediately, PowerMTA initially accepts a normal SMTP connection and advertises that it supports STARTTLS.

The application then requests an upgrade to TLS.

Configuration

The first requirement is the same TLS certificate:

smtp-server-tls-certificate /etc/pmta/smtp-cert.pem

Next, configure the listener:

smtp-listener 0.0.0.0:587

Unlike port 465, we do not specify tls=yes because the connection must initially establish a normal SMTP session.

We then configure the relevant source settings to allow STARTTLS and require encryption before authentication.

<source {submission}>

    smtp-service yes

    allow-starttls yes

    require-starttls-before-auth yes

    allow-unencrypted-plain-auth no

    require-auth true

    always-allow-relaying yes

</source>

These directives control the behaviour of connections matching this named source.

Let’s understand what each setting does:

Directive	Purpose
smtp-service yes	Enables SMTP service for the source.
allow-starttls yes	Allows clients to upgrade their connection using STARTTLS.
require-starttls-before-auth yes	Requires TLS before SMTP authentication.
allow-unencrypted-plain-auth no	Prevents plaintext PLAIN/LOGIN authentication without encryption.
require-auth true	Requires SMTP authentication.
always-allow-relaying yes	Allows authenticated clients matching this source to relay messages.

The always-allow-relaying setting is particularly important for an authenticated submission service. It must only be used with appropriately restricted and authenticated sources, not as a blanket permission for untrusted connections.

What happens during the connection?

The connection follows this sequence:

1. The application connects to PowerMTA on port 587.
2. PowerMTA sends its initial SMTP greeting.
3. The application sends EHLO.
4. PowerMTA advertises STARTTLS.
5. The application sends STARTTLS.
6. PowerMTA responds that TLS negotiation can begin.
7. The TLS handshake takes place.
8. The certificate is presented and validated.
9. The application sends another EHLO.
10. PowerMTA advertises the available authentication mechanisms.
11. The application authenticates.
12. PowerMTA accepts the email for processing.

Example SMTP conversation

Initial connection

220 smtp.example.com ESMTP service ready

EHLO wordpress.example.com

250-smtp.example.com Hello
250-STARTTLS
250 SIZE 52428800

At this point, the connection is not encrypted.

Requesting encryption

STARTTLS

220 2.0.0 Ready to start TLS

The TLS handshake now takes place.

After successful TLS negotiation

EHLO wordpress.example.com

250-smtp.example.com Hello
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 SIZE 52428800

The application can now authenticate:

AUTH LOGIN

334 VXNlcm5hbWU6

[Base64-encoded username]

334 UGFzc3dvcmQ6

[Base64-encoded password]

235 2.7.0 Authentication successful

The important detail is that PowerMTA requires encryption before authentication.

If a client attempts to authenticate before issuing STARTTLS, the connection should not proceed with password-based authentication.

5. Configuring SMTP authentication and users

Enabling TLS alone does not secure an SMTP submission service completely.

You must also configure authentication so that only authorised applications and users can submit email.

PowerMTA supports SMTP user definitions through the smtp-user configuration block.

For example, create an SMTP user named wordpressuser:

<smtp-user wordpressuser>

    password ChangeThisToAStrongPassword

    authentication-method password

    source {submission}

</smtp-user>

This configuration defines:

• An SMTP username.
• Its associated password.
• Password-based SMTP authentication.
• The source configuration that applies when this user authenticates.

The {submission} source references the source block configured earlier.

You can create multiple SMTP users for different customers, websites or applications.

For example:

<smtp-user customer1>

    password StrongPassword1

    authentication-method password

    source {submission}

</smtp-user>


<smtp-user customer2>

    password StrongPassword2

    authentication-method password

    source {submission}

</smtp-user>

In production, use unique, randomly generated credentials and follow your PowerMTA release’s supported password-storage and authentication practices. The passwords above are illustrative only.

Why separate SMTP users?

Using separate credentials provides several advantages:

• Individual customer access.
• Easier credential revocation.
• Better accountability.
• Separation of application traffic.
• Easier investigation of authentication and relay issues.

It also means that if one customer’s credentials are compromised, you can disable that account without affecting other customers.

6. Putting everything together – Complete example configuration

The following example combines both secure SMTP submission methods into one PowerMTA configuration.

It assumes:

• SMTP hostname: smtp.example.com
• Implicit TLS port: 465
• STARTTLS port: 587
• Certificate: /etc/pmta/smtp-cert.pem
• SMTP username: wordpressuser

Complete configuration

##################################################
# TLS CERTIFICATE
##################################################

smtp-server-tls-certificate /etc/pmta/smtp-cert.pem


##################################################
# SMTP LISTENERS
##################################################

# Standard SMTP listener
smtp-listener 0.0.0.0:25

# Implicit TLS - port 465
smtp-listener 0.0.0.0:465 tls=yes

# Explicit TLS / STARTTLS - port 587
smtp-listener 0.0.0.0:587


##################################################
# SMTP USER
##################################################

<smtp-user wordpressuser>

    password ChangeThisToAStrongPassword

    authentication-method password

    source {submission}

</smtp-user>


##################################################
# AUTHENTICATED SUBMISSION SOURCE
##################################################

<source {submission}>

    smtp-service yes

    allow-starttls yes

    require-starttls-before-auth yes

    allow-unencrypted-plain-auth no

    require-auth true

    always-allow-relaying yes

</source>

This example illustrates the main configuration components. Before using it, merge the settings into the existing configuration rather than replacing your entire PowerMTA configuration file.

In particular, preserve existing source definitions, trusted relay permissions, virtual MTAs, IP restrictions and routing rules.

Also ensure that the source block is correctly matched to the intended listeners and does not unintentionally grant relay permissions to other connections.

Expected behaviour

Setting	Port 465	Port 587
TCP connection	Yes	Yes
Immediate TLS handshake	Yes	No
STARTTLS advertised	No	Yes
TLS certificate presented	Immediately	After STARTTLS
Second EHLO	Not required	Required
SMTP authentication	After TLS	After TLS
Unencrypted authentication	Blocked	Blocked

Both listeners can operate simultaneously, allowing applications to choose whichever connection method they support.

7. Configuring outbound TLS in PowerMTA

So far, we have configured PowerMTA to accept secure connections from applications.

However, there is another side to email delivery.

Once PowerMTA accepts a message, it must connect to the recipient’s mail server and deliver it.

This is known as outbound SMTP delivery.

For example:

WordPress
    |
    | TLS - Port 587
    v
PowerMTA
    |
    | TLS - Port 25
    v
Recipient Mail Server

PowerMTA can use STARTTLS when communicating with remote mail servers.

A typical domain configuration is:

<domain example.net>

    use-starttls yes

</domain>

This tells PowerMTA to use STARTTLS when the remote server advertises support.

By default, this is generally opportunistic: if the remote server does not support STARTTLS, delivery can continue without TLS.

If you want to enforce encryption for a particular destination, configure:

<domain secure.example.net>

    use-starttls yes

    require-starttls yes

</domain>

With require-starttls yes, PowerMTA will not deliver the message over an unencrypted connection if TLS is unavailable or cannot be established.

This is useful for destinations where encrypted transport is mandatory.

Important: Do not blindly enable require-starttls yes for all recipient domains. Some legitimate receiving mail servers may not support TLS, and enforcing it globally can cause delivery failures and queued messages.

Also, this example covers outbound STARTTLS. Do not assume that an outbound port 465 connection can be configured simply by applying the inbound tls=yes listener syntax. Outbound SMTPS support and configuration must be verified against the relevant PowerMTA release.

8. Testing the PowerMTA SMTP configuration

Once the configuration has been applied, it is important to verify that both listeners are working as expected.

OpenSSL provides a convenient way to test SMTP TLS connections without relying on WordPress or another application.

Test port 465 – Implicit TLS

Run:

openssl s_client \
-connect smtp.example.com:465 \
-servername smtp.example.com \
-verify_hostname smtp.example.com \
-verify_return_error \
-crlf

You should see:

• A successful TLS handshake.
• The server’s certificate details.
• The negotiated TLS version.
• The negotiated cipher suite.
• Successful certificate verification.

Once connected, enter:

EHLO test.example.com

PowerMTA should return its SMTP capabilities.

Test port 587 – STARTTLS

Run:

openssl s_client \
-starttls smtp \
-connect smtp.example.com:587 \
-servername smtp.example.com \
-verify_hostname smtp.example.com \
-verify_return_error \
-crlf

OpenSSL will:

1. Establish the initial SMTP connection.
2. Read the server’s greeting.
3. Issue the STARTTLS command.
4. Negotiate TLS.
5. Validate the certificate.

Once connected, enter:

EHLO test.example.com

You should receive the post-TLS SMTP capabilities.

Check the SMTP ports

On a Linux PowerMTA server, you can inspect the listening ports using:

ss -lntp | grep -E ':25|:465|:587'

You should see PowerMTA listening on the configured addresses and ports.

You can also use the PowerMTA management command:

pmta show listeners

This helps verify which listeners are active and their TLS configuration.

Test connectivity from Windows

If your application or WordPress server runs on Windows, you can test TCP connectivity using PowerShell:

Test-NetConnection smtp.example.com -Port 465

Test-NetConnection smtp.example.com -Port 587

A successful TCP connection confirms network connectivity, but does not prove that TLS or SMTP authentication is working correctly. Use OpenSSL for the full TLS test.

9. Common configuration problems and troubleshooting

When configuring TLS in PowerMTA, there are several common issues worth understanding.

Problem	Possible cause	What to check
Connection refused on port 465	Listener not configured or service not listening	smtp-listener and firewall
TLS handshake failure	Certificate or private key problem	Certificate file and PowerMTA logs
Certificate verification failed	Invalid, expired or mismatched certificate	Hostname, validity and certificate chain
STARTTLS not advertised	STARTTLS not enabled or certificate unavailable	allow-starttls and certificate configuration
STARTTLS returns 502	Connected to a listener that does not support STARTTLS	Check the actual listener and port
Authentication rejected	Incorrect credentials or source configuration	smtp-user and matching <source>
Authentication rejected before TLS	Client attempted AUTH before STARTTLS	SMTP client encryption settings
Authentication succeeds but relay denied	Relay permission not enabled for the matching source	always-allow-relaying and source matching
Email accepted but not delivered	Outbound delivery or recipient-side problem	VMTA, DNS, queue and delivery logs

An important distinction: Authentication does not automatically mean relay permission

This is worth highlighting.

A user may successfully authenticate with PowerMTA and still receive a relay-denied response.

This happens because authentication and relay permissions are separate controls.

PowerMTA determines the applicable source configuration for the connection. That source must permit the required relay operation.

For authenticated submission, ensure the SMTP user references the intended source and that the source has the appropriate relay permissions.

Avoid granting relay permissions globally to all IP addresses.

10. Security recommendations for production deployments

For a production PowerMTA environment, I recommend the following practices:

1. Use valid TLS certificates

Use a trusted certificate that matches the SMTP hostname. Monitor expiry dates and have a controlled renewal process.

2. Enforce TLS before authentication

Use require-starttls-before-auth yes for STARTTLS submission and configure implicit TLS on port 465.

3. Disable unencrypted password authentication

Use:

allow-unencrypted-plain-auth no

This prevents PLAIN/LOGIN credentials from being transmitted without an appropriate encrypted session.

4. Require SMTP authentication

Use:

require-auth true

for authenticated application submission.

5. Restrict relay permissions

Only authenticated users and explicitly trusted sources should be permitted to relay messages.

6. Use separate SMTP credentials

Create different SMTP accounts for individual applications and customers.

7. Restrict network access

Use firewall rules and IP restrictions where possible, particularly for internal applications.

8. Monitor SMTP activity

Review authentication failures, unexpected connections, relay attempts and delivery logs.

9. Use modern TLS

Disable obsolete SSL/TLS protocols and use the secure TLS versions supported by your installed PowerMTA release.

10. Maintain SPF, DKIM and DMARC

These provide complementary email authentication and domain protection. TLS does not replace them.

Conclusion

PowerMTA can provide secure SMTP submission using both implicit TLS and explicit STARTTLS.

The two methods differ in how encryption is established, but both can provide strong transport security when correctly configured.

For application and website integration, the recommended configurations are:

• Port 465: Implicit TLS, where encryption begins immediately.
• Port 587: STARTTLS, where encryption is required before SMTP authentication.

PowerMTA can also use STARTTLS for outbound connections to recipient mail servers, helping protect email during transport.

The most important considerations are to use valid certificates, enforce encryption before authentication, configure SMTP users correctly, restrict relay permissions and verify the configuration through real TLS handshake tests.

With these controls in place, PowerMTA can provide a secure and flexible SMTP submission service for websites, applications and email delivery platforms.