Explicit vs. Implicit SMTP: Understanding Secure Email Connections and TLS Handshakes

---

When configuring an email server, connecting a website to an SMTP relay, or setting up an email plugin such as Post SMTP on WordPress, one of the most important decisions is choosing the correct connection security method.

Two commonly available options are Explicit TLS (STARTTLS) and Implicit TLS (SMTPS).

Although both methods use Transport Layer Security (TLS) to encrypt SMTP communications, they differ in how and when the encryption process begins.

Understanding these differences is important for anyone responsible for email infrastructure, application development, website hosting or email deliverability.

In this article, we’ll explore how both methods work, examine the SMTP handshake step by step, look at the different authentication mechanisms, compare the standard SMTP ports and explain which configuration you should use.

1. First, what is SMTP?

SMTP stands for Simple Mail Transfer Protocol. It is the standard protocol used to send email between mail servers and from email applications to outgoing mail servers.

For example, when a visitor submits a contact form on a WordPress website, the website needs a way to send that message to its intended recipient.

The typical process looks like this:

1. A website or application generates an email.
2. The application connects to an SMTP server.
3. The SMTP server authenticates the application, where authentication is required.
4. The application submits the email.
5. The SMTP server processes the message and delivers it to the recipient’s mail server, either directly or through another relay.

There are two important SMTP functions worth distinguishing:

• Message submission: An application, email client or website submits an outgoing email to an SMTP service.
• Message relay: One mail server transfers an email to another mail server for onward delivery.

These functions commonly use different ports and security configurations.

For example, WordPress normally connects to a message submission service, whereas mail servers communicating with other mail servers generally use port 25.

SMTP itself does not automatically provide encryption. TLS is added to protect the connection.

2. Understanding the difference between Explicit and Implicit TLS

Before looking at the technical handshake, let’s understand the fundamental difference.

Explicit TLS vs. Implicit TLS – Quick Comparison

Feature	Implicit TLS (SMTPS)	Explicit TLS (STARTTLS)
Standard port	465	587, 2525
Connection starts	Encrypted	Unencrypted
TLS handshake	Immediately after TCP connection	After the STARTTLS command
SMTP greeting	Inside encrypted tunnel	Before and after TLS upgrade
EHLO commands	Normally one	Normally two
Authentication	After TLS	After TLS
Downgrade exposure	No initial STARTTLS negotiation to strip	Possible if TLS is optional
Security	Strong when correctly configured	Equally strong when TLS is mandatory
Common use	Website and application submission	Website, application and email-client submission

Implicit TLS (SMTPS)

The connection starts with TLS immediately. The client and server negotiate encryption before exchanging any SMTP commands or greetings.

Explicit TLS (STARTTLS)

The connection initially starts as a normal SMTP session. The client and server exchange an initial greeting, and the client then requests an upgrade to TLS using the STARTTLS command.

Once the TLS handshake succeeds, the SMTP conversation continues inside the encrypted connection.

Both methods can provide strong encryption when correctly configured.

3. Implicit TLS (SMTPS)

How does it work?

Implicit TLS is an encryption-first approach.

When an email application connects to an SMTP server using implicit TLS, the TLS handshake begins immediately after the underlying TCP connection is established.

The application cannot exchange SMTP commands or receive the SMTP greeting until the TLS negotiation has completed successfully.

If the TLS handshake fails, the certificate cannot be validated, or the server does not support the expected protocol, the connection should be terminated.

Standard port: 465

Port 465 is officially registered for message submission over implicit TLS.

Step-by-step handshake

The connection follows this sequence:

1. The email application opens a TCP connection to the SMTP server on port 465.
2. The client immediately initiates the TLS handshake.
3. The server presents its TLS certificate.
4. The client validates the certificate, including its trust chain, validity and hostname.
5. The client and server negotiate the TLS session and establish encryption keys.
6. Once encryption is established, the SMTP server sends its greeting.
7. The client sends its EHLO command.
8. The server advertises its available SMTP extensions.
9. The client authenticates.
10. The client submits the email.

Example SMTP transaction over implicit TLS

The following is an illustrative SMTP conversation. All SMTP messages shown here take place inside the already-established TLS tunnel.

[CLIENT] TCP connection established: port 465

[CLIENT] TLS handshake initiated
[SERVER] TLS certificate presented
[CLIENT] Certificate validated
[CLIENT] TLS session established

[SERVER] 220 smtp.example.com ESMTP service ready

[CLIENT] EHLO wordpress.example.com

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

[CLIENT] AUTH LOGIN
[SERVER] 334 VXNlcm5hbWU6
[CLIENT] [Base64-encoded username]
[SERVER] 334 UGFzc3dvcmQ6
[CLIENT] [Base64-encoded password]
[SERVER] 235 2.7.0 Authentication successful

The client can now submit an email using the standard SMTP commands:

MAIL FROM:<sender@example.com>
250 2.1.0 Sender accepted

RCPT TO:<recipient@example.com>
250 2.1.5 Recipient accepted

DATA
354 Start mail input

Subject: SMTP TLS Test

This is a test email sent over implicit TLS.

.
250 2.0.0 Message accepted

QUIT
221 2.0.0 Closing connection

The important point is that even the initial SMTP greeting (220) is encrypted because it is sent after the TLS handshake.

Advantages of implicit TLS

• Encryption is established before any SMTP application data is exchanged.
• No initial plaintext SMTP negotiation takes place.
• There is no STARTTLS command to be stripped from the initial SMTP conversation.
• It is straightforward to configure in modern email applications.
• It reduces the risk of accidentally transmitting credentials over an unencrypted connection.

However, implicit TLS is not immune to every type of attack. Certificate validation, hostname verification and secure DNS/network configuration remain important.

4. Explicit TLS (STARTTLS)

How does it work?

Explicit TLS takes a different approach.

Instead of establishing encryption immediately, the client initially establishes a normal SMTP connection.

The client and server exchange their initial SMTP greetings and capabilities. If the server advertises STARTTLS support, the client can request an upgrade to an encrypted connection.

This is known as a TLS upgrade.

The important part is that the application must not send authentication credentials or sensitive email content before the TLS handshake has successfully completed.

Standard ports: 587 and 25

Port 587 is the standard message submission port and commonly uses STARTTLS.

Port 25 is primarily used for server-to-server SMTP delivery and can also support STARTTLS.

Port 2525 is an alternative commonly offered by some SMTP providers when standard outbound SMTP ports are restricted. It is not a universally standardised SMTP submission port.

Step-by-step handshake

The connection follows this sequence:

1. The email application opens a TCP connection to port 587.
2. The SMTP server sends its initial greeting.
3. The client sends its first EHLO command.
4. The server advertises its available SMTP extensions, including STARTTLS if supported.
5. The client sends the STARTTLS command.
6. The server responds with 220 Ready to start TLS.
7. The TLS handshake begins.
8. The server presents its TLS certificate.
9. The client validates the certificate and hostname.
10. The client and server establish an encrypted TLS session.
11. The SMTP protocol state is reset.
12. The client sends a second EHLO command.
13. The server advertises its capabilities again, this time within the encrypted connection.
14. The client authenticates and submits the email.

Example SMTP transaction

Stage 1: Initial unencrypted connection

[CLIENT] TCP connection established: port 587

[SERVER] 220 smtp.example.com ESMTP service ready

[CLIENT] EHLO wordpress.example.com

[SERVER] 250-smtp.example.com Hello
[SERVER] 250-STARTTLS
[SERVER] 250-ENHANCEDSTATUSCODES
[SERVER] 250 SIZE 52428800

At this stage, the connection is not encrypted.

The client knows that the server supports STARTTLS because it has advertised the extension.

Stage 2: Requesting the TLS upgrade

The client sends:

[CLIENT] STARTTLS

The server responds:

[SERVER] 220 2.0.0 Ready to start TLS

The client and server now begin negotiating TLS.

Stage 3: TLS handshake

[CLIENT] TLS handshake initiated
[SERVER] TLS certificate presented
[CLIENT] Certificate validated
[CLIENT] TLS session established

From this point onwards, the SMTP conversation is encrypted.

Stage 4: The second EHLO command

This is an important part of the STARTTLS process.

After successfully negotiating TLS, the SMTP protocol state is reset. The client must send another EHLO command to obtain the server’s capabilities within the encrypted session.

[CLIENT] EHLO wordpress.example.com

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

Notice that the server’s advertised capabilities can differ from the initial response.

For example, the server may only advertise certain authentication mechanisms once encryption has been established.

Stage 5: SMTP authentication

The client can now authenticate securely:

[CLIENT] AUTH LOGIN

[SERVER] 334 VXNlcm5hbWU6

[CLIENT] [Base64-encoded username]

[SERVER] 334 UGFzc3dvcmQ6

[CLIENT] [Base64-encoded password]

[SERVER] 235 2.7.0 Authentication successful

The client can now proceed with the normal SMTP email submission process.

Why does STARTTLS require a second EHLO?

This is not simply a programming convention.

According to RFC 3207, once TLS negotiation has completed, the SMTP protocol returns to its initial state.

Both parties must discard knowledge obtained during the pre-TLS SMTP negotiation. This includes previously advertised SMTP capabilities.

The client therefore sends another EHLO command to obtain a fresh list of capabilities from the server.

This is why you will often see two EHLO commands in an SMTP debug log when using STARTTLS.

Advantages of STARTTLS

• Allows an SMTP service to upgrade an existing connection to TLS.
• Widely supported by email servers and applications.
• Works well with standard message submission on port 587.
• Can provide equivalent encryption security to implicit TLS when both sides require successful TLS negotiation.
• Offers flexibility for different SMTP environments.

5. Understanding SMTP authentication mechanisms

TLS and SMTP authentication are two separate but closely related parts of a secure SMTP connection.

TLS protects the communication channel, whereas SMTP authentication verifies the identity of the application or user attempting to submit an email.

Common authentication mechanisms include:

Authentication method	Description
PLAIN	Sends credentials encoded using Base64. Must be protected by TLS or another suitable security layer.
LOGIN	Uses Base64-encoded username and password challenges. Must be protected by TLS.
CRAM-MD5	Uses a challenge-response mechanism rather than sending the password directly. It is an older mechanism and has security limitations.
XOAUTH2	Uses OAuth 2.0 access tokens instead of traditional passwords.

An important point about PLAIN and LOGIN

You may notice that SMTP servers advertise authentication mechanisms such as PLAIN and LOGIN.

Despite their names, these mechanisms do not encrypt credentials themselves.

For example, the following Base64 string:

dGVzdHVzZXIAbXlwYXNzd29yZA==

is simply an encoded representation of data, not encryption.

Anyone who intercepts it can decode it.

Therefore, AUTH PLAIN and AUTH LOGIN should only be used over a properly protected TLS connection.

A correctly configured SMTP server should prevent the use of password-based authentication without an appropriate security layer.

What about CRAM-MD5?

CRAM-MD5 is an older SMTP authentication mechanism that uses a challenge-response exchange.

Although it avoids sending the password directly, it does not encrypt the SMTP connection or the email being transmitted.

It also has limitations, including a lack of server authentication and weaknesses associated with its underlying cryptography.

It should not be treated as a replacement for TLS.

For modern SMTP deployments, TLS combined with an appropriate authentication mechanism is the preferred approach.

6. SMTP ports explained

Understanding SMTP ports is just as important as understanding the encryption method.

Port	Protocol / security	Typical purpose
25	SMTP with optional STARTTLS	Mail server-to-server delivery and relay
465	Implicit TLS	Secure application and email-client submission
587	SMTP with STARTTLS	Standard secure application and email-client submission
2525	Usually STARTTLS or provider-specific TLS	Alternative submission port where standard ports are blocked

Port 25 – Server-to-server delivery

Port 25 is primarily used for transferring emails between mail servers.

For example:

• Mail server A sends an email to mail server B.
• Mail server A connects to mail server B using port 25.
• Both servers negotiate STARTTLS if it is available.
• The email is transferred.

Unlike authenticated message submission, server-to-server SMTP often uses opportunistic TLS.

This means that if the receiving server does not offer STARTTLS, a sending server may still deliver the email without encryption, depending on its security policy.

Port 465 – Implicit TLS

Port 465 is intended for secure message submission over TLS.

The TLS handshake takes place immediately after the TCP connection is established.

It is a good choice for websites, applications and email clients that support implicit TLS.

Port 587 – STARTTLS

Port 587 is the standard message submission port.

The client establishes an SMTP connection and then upgrades it using STARTTLS.

For modern applications, TLS should be mandatory before authentication or message submission.

Port 2525 – Alternative submission port

Some SMTP providers offer port 2525 as an alternative to ports 465 and 587.

This can be useful where hosting companies, firewalls or network providers restrict outbound SMTP traffic.

However, port 2525 does not automatically mean STARTTLS or implicit TLS. Always check the SMTP provider’s documentation to establish which connection mode it expects.

7. Is STARTTLS less secure than implicit TLS?

This is one of the most common questions when configuring SMTP.

The short answer is: not necessarily.

Implicit TLS begins encryption immediately, whereas STARTTLS initially exchanges SMTP commands in plaintext before upgrading the connection.

This creates an important difference in the initial connection phase.

An attacker positioned on the network could potentially interfere with the initial plaintext SMTP conversation and remove or modify the advertised STARTTLS capability. This is commonly known as a STARTTLS-stripping or downgrade attack.

If the client accepts the downgrade and continues without encryption, the connection becomes vulnerable.

However, this does not mean STARTTLS is inherently insecure.

The risk is addressed by configuring the SMTP client to require TLS.

For example, when a WordPress SMTP plugin is configured to use STARTTLS on port 587, it should:

• Require the server to advertise STARTTLS.
• Terminate the connection if STARTTLS is unavailable.
• Validate the server’s TLS certificate.
• Refuse to authenticate if certificate validation fails.
• Never fall back to plaintext SMTP.

In other words, the application must not treat encryption as optional.

The key security difference is the point at which encryption begins, not necessarily the strength of the encryption ultimately established.

RFC 8314 recognises that correctly configured STARTTLS on port 587 and implicit TLS on port 465 can offer equivalent security properties.

8. How to test SMTP TLS connections

You do not need to rely entirely on application logs or WordPress plugin settings to determine whether your SMTP server is configured correctly.

You can test both connection methods directly using OpenSSL.

OpenSSL is a widely used command-line toolkit that supports TLS testing and certificate inspection.

Test implicit TLS on port 465

Run:

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

This immediately initiates a TLS handshake.

Once the connection is established, you can enter SMTP commands such as:

EHLO test.example.com

You should receive the server’s advertised SMTP capabilities.

Look for a successful TLS negotiation and a valid certificate verification result.

Test STARTTLS on port 587

Run:

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

The -starttls smtp option instructs OpenSSL to perform the initial SMTP negotiation and issue STARTTLS before continuing with the TLS handshake.

Once connected, enter:

EHLO test.example.com

You should receive the server’s post-TLS capabilities.

What should you look for?

When testing either connection, check:

• Certificate subject and Subject Alternative Names.
• Certificate issuer and trust chain.
• Certificate validity dates.
• Hostname verification.
• Negotiated TLS protocol version.
• Negotiated cipher suite.
• Successful certificate verification.

A TLS connection being established does not automatically mean the certificate is trusted or belongs to the server you intended to reach.

For additional hostname verification, use:

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

For port 587, add -starttls smtp to the command.

Important: Do not enter real SMTP passwords into a plaintext terminal session or share SMTP debug logs containing credentials or authentication tokens.

9. SMTP TLS does not mean end-to-end email encryption

There is another important security consideration that is often overlooked.

TLS protects the connection between two communicating systems. It does not automatically encrypt an email from the original sender all the way to the recipient.

For example, consider this delivery path:

WordPress Website
       |
       | TLS
       v
SMTP Submission Server
       |
       | TLS
       v
Outbound Mail Server
       |
       | TLS
       v
Recipient Mail Server
       |
       v
Recipient Mailbox

Each connection can be encrypted independently.

However, the email may be stored or processed in readable form on intermediate mail servers.

This means that SMTP TLS provides transport encryption, not end-to-end message encryption.

If genuine end-to-end encryption is required, technologies such as S/MIME or OpenPGP should be considered.

What about SPF, DKIM and DMARC?

These technologies are also important for email security, but they solve different problems.

Technology	Purpose
SPF	Identifies which servers are authorised to send email for a domain.
DKIM	Adds a cryptographic signature to help verify message integrity and domain association.
DMARC	Defines how receiving servers should handle messages that fail SPF/DKIM alignment and provides reporting.
TLS	Encrypts the connection between communicating SMTP systems.

These technologies complement one another. None is a replacement for the others.

For organisations looking to strengthen server-to-server email transport security, MTA-STS and DANE can also provide additional protection against certain downgrade and interception attacks.

10. Which SMTP configuration should you choose?

For most modern website and application deployments, both implicit TLS and explicit STARTTLS are suitable.

The decision should be based on the SMTP service you are connecting to and the security capabilities of the application.

Recommended configuration for WordPress

If your SMTP provider supports both methods, the following are sensible choices:

Setting	Recommended configuration
SMTP Host	smtp.example.com
SMTP Port	465 or 587
Encryption	SSL/TLS for 465; STARTTLS for 587
Authentication	Enabled
Username	SMTP account username
Password	SMTP account password or supported token
Certificate verification	Enabled
TLS requirement	Mandatory

For example, in a WordPress SMTP plugin such as Post SMTP:

Option A – Implicit TLS

SMTP Host: smtp.example.com
SMTP Port: 465
Encryption: SSL/TLS
Authentication: Enabled

Option B – Explicit TLS

SMTP Host: smtp.example.com
SMTP Port: 587
Encryption: STARTTLS
Authentication: Enabled

Do not select SSL/TLS on port 587 or STARTTLS on port 465 unless the provider explicitly documents that configuration.

The port and encryption mode must match the SMTP server’s configuration.

Final recommendation

My recommendation is to use port 465 with implicit TLS where the application and SMTP provider support it.

It provides a straightforward encryption-first connection and removes the initial plaintext SMTP negotiation.

However, if port 465 is blocked by your hosting provider or firewall, port 587 with mandatory STARTTLS is an equally valid and secure alternative when correctly implemented.

The most important consideration is not simply whether you use implicit or explicit TLS. It is whether the connection is properly encrypted, the server certificate is validated, authentication is protected, and the application refuses to fall back to an unencrypted connection.

Conclusion

SMTP security is about more than choosing a port number.

Understanding how TLS works, when encryption begins, how SMTP authentication operates and how email servers communicate with one another is essential when building a reliable email delivery infrastructure.

Implicit TLS and explicit STARTTLS are two different approaches to achieving the same objective: protecting SMTP communications against interception and credential exposure.

When correctly configured, both can provide strong transport encryption.

For website owners, developers and system administrators, the best practice is straightforward:

• Use port 465 with implicit TLS or port 587 with mandatory STARTTLS for application email submission.
• Never transmit SMTP credentials over an unencrypted connection.
• Validate TLS certificates and server hostnames.
• Keep TLS configurations and server software up to date.
• Use SPF, DKIM and DMARC to strengthen email authentication.
• Consider MTA-STS or DANE for additional protection of server-to-server email delivery.

A properly secured SMTP connection protects more than just a username and password. It helps safeguard the email submission process and the information transmitted between your applications and mail infrastructure.