What Is the Difference Between SMTP Ports 25 and 465?
From TCP, DNS, SMTP, and TLS to firewall domain filtering
1. Background
A common requirement in enterprise networks is:
Allow an application server to send email through an approved mail server while preventing it from connecting to unapproved mail domains.
For example:
Application
|
| SMTP
v
Network Firewall
|
v
Mail Server
If the firewall policy only permits:
smtp.example.com
an important question arises:
What information does the firewall use to determine which mail domain the client is accessing?
To answer this question, DNS, TCP, SMTP, TLS, and the firewall must be considered as parts of the same connection flow.
2. Distinguishing URLs, Domains, and IP Addresses
Before discussing firewall filtering, several concepts must be separated.
For example:
https://mail.example.com/path
This is a URL.
Within that URL:
mail.example.com
is the domain or hostname.
DNS resolution might return:
mail.example.com
|
v
203.0.113.10
This is an IP address.
Unlike HTTP, SMTP communication does not normally carry a complete URL. For a connection to a mail server, the more relevant information includes:
- SMTP server hostname or FQDN
- Destination IP address
- Destination port
- TLS SNI
- SMTP application-layer information
Therefore, when discussing SMTP firewall filtering, the more accurate term is:
Domain or FQDN filtering, not URL path filtering.
3. DNS Happens Before the TCP Connection
Assume that the application is configured to use:
smtp.example.com
Before establishing an SMTP TCP connection, the client normally resolves this name:
Application
|
| DNS Query
v
DNS Server
|
| 203.0.113.10
v
Application
The following mapping has now been established:
smtp.example.com
|
v
203.0.113.10
An important distinction is:
DNS resolves a domain to an IP address, while the TCP connection itself uses an IP address and port.
When the client establishes the TCP connection, the packet looks conceptually like this:
TCP SYN
Source: Client IP
Destination: 203.0.113.10:25
The TCP header does not contain a field such as:
smtp.example.com
4. SMTP Port 25: Traditional SMTP with STARTTLS
Port 25 is mainly used for server-to-server SMTP delivery and relay scenarios.
A typical SMTP connection might proceed as follows:
Client SMTP Server
| |
|-------- TCP SYN -------------->|
|<------- TCP SYN/ACK -----------|
|-------- TCP ACK -------------->|
| |
|<------- 220 ESMTP -------------|
|-------- EHLO client.example -->|
|<------- 250-STARTTLS ----------|
| |
|-------- STARTTLS -------------->|
|<------- 220 Ready -------------|
| |
|<======= TLS Handshake =========>|
| |
|<======= Encrypted SMTP ========>|
The important transition is:
SMTP plaintext
|
| STARTTLS
v
TLS
|
v
Encrypted SMTP
Before STARTTLS, SMTP application data may be transmitted in plaintext.
For example:
EHLO client.example.com
Other SMTP negotiation commands may also be visible to an inspection device on the network path before TLS begins.
It is therefore inaccurate to say:
Port 25 does not have any domain information.
A more precise description is:
- The TCP connection uses the destination IP address and port.
- A domain may have appeared earlier in the DNS query.
- SMTP application data may be observable before STARTTLS.
- SMTP data becomes encrypted after STARTTLS succeeds.
5. SMTP Port 465: Implicit TLS
Port 465 works differently from STARTTLS.
RFC 8314 defines port 465 for SMTP submission over TLS. In other words:
TLS starts immediately after the TCP connection is established.
The connection can be represented as follows:
Client SMTP Server
| |
|-------- TCP SYN -------------->|
|<------- TCP SYN/ACK -----------|
|-------- TCP ACK -------------->|
| |
|======= TLS ClientHello =======>|
|<====== TLS ServerHello ========|
| |
|<======= TLS Handshake =========>|
| |
|<======= Encrypted SMTP ========>|
Port 465 is therefore more accurately represented as:
TCP
↓
TLS
↓
SMTP
rather than:
TCP
↓
SMTP plaintext
↓
STARTTLS
↓
TLS
This is one of the most important differences between port 25 with STARTTLS and port 465 with implicit TLS.
6. SNI on Port 465
A TLS ClientHello may contain:
Server Name Indication (SNI)
For example:
TLS ClientHello
SNI:
smtp.example.com
When the client sends SNI and no other mechanism hides it, an intermediate device capable of TLS or SNI inspection may use it to identify the target hostname.
The information flow for port 465 can therefore be understood as:
DNS
|
+---- smtp.example.com
|
v
203.0.113.10
|
+---- TCP:465
|
v
TLS ClientHello
|
+---- SNI: smtp.example.com
However, an important qualification applies:
The presence of SNI does not mean that every port 465 connection can always be identified by every firewall through SNI.
The result depends on whether the client sends SNI, whether the device inspects it, whether the product supports the protocol and policy type, and whether mechanisms such as ECH affect visibility.
7. What Can the Firewall See?
The available information depends on the connection stage.
7.1 DNS Layer
If the firewall can observe DNS traffic, it may see a query such as:
Query:
smtp.example.com
This does not guarantee that the query can be reliably correlated with a later TCP session.
The client might use:
- A DNS cache
- DNS over HTTPS (DoH)
- DNS over TLS (DoT)
- Another DNS resolver
DNS alone should therefore not be assumed to identify every resulting network connection.
7.2 IP and TCP Layers
A firewall can normally obtain the following information from L3/L4 traffic:
Source IP
Destination IP
Protocol
Destination Port
For example:
10.0.1.10
|
| TCP
v
203.0.113.10:465
This information still does not directly carry:
smtp.example.com
7.3 SMTP Plaintext Stage
For port 25 with STARTTLS:
SMTP
↓
EHLO
↓
STARTTLS
↓
TLS
A device with the appropriate application-layer inspection capability may observe plaintext SMTP data before TLS begins.
7.4 TLS ClientHello
For port 465:
TCP
↓
TLS ClientHello
↓
SNI
If the ClientHello contains plaintext SNI, a device that supports TLS or SNI inspection may use that information for a policy decision.
8. Key Differences Between Ports 25 and 465
| Item | SMTP 25 | SMTP 465 |
|---|---|---|
| TCP destination port | 25 | 465 |
| Typical use | Server-to-server delivery or relay | SMTP submission over TLS |
| TCP connection | Yes | Yes |
| Initial application protocol | SMTP | TLS |
| TLS mode | Usually STARTTLS | Implicit TLS |
| When TLS begins | After SMTP negotiation | Immediately after TCP establishment |
| STARTTLS | May be used | Not used in this mode |
| Initial plaintext SMTP | May exist | No plaintext SMTP stage |
| TLS ClientHello | After STARTTLS | Immediately after connection establishment |
| SNI | Depends on TLS and the client | Depends on TLS and the client |
| Firewall-visible information | IP, port, DNS, plaintext SMTP, and TLS metadata | IP, port, DNS, and TLS/SNI metadata |
| Domain filtering | Depends on firewall inspection and policy support | Depends on firewall inspection and policy support |
9. A Common Misunderstanding: Domain Is Not the TCP Destination
Assume that:
smtp.example.com
|
v
203.0.113.10
The client eventually establishes:
TCP → 203.0.113.10:465
At the TCP layer, the destination is:
203.0.113.10:465
The value:
smtp.example.com
is a hostname associated with that IP address.
Therefore:
A domain is information from the application, DNS, TLS, or another higher layer. It is not a field in the TCP header.
This is why domain-based firewall filtering is not simply L3/L4 IP and port filtering.
10. Understanding This in OCI Network Firewall
OCI Network Firewall provides capabilities including stateful network filtering, custom URL and FQDN filtering, and SSL inspection.
These capabilities should be considered separately:
L3/L4 Filtering
|
+---- Source IP
+---- Destination IP
+---- Port
+---- Protocol
FQDN / URL Filtering
|
+---- Domain- or URL-related identification
SSL Inspection
|
+---- Decrypt
+---- Inspect
+---- Re-encrypt
OCI documentation states that Network Firewall supports custom URL and FQDN filtering as well as TLS/SSL inspection. Whether a specific SMTP flow can be matched through SNI, application identification, or decrypted content depends on the protocol, firewall policy, decryption configuration, and product support.
It would therefore be unsafe to conclude:
“OCI Network Firewall can see SNI on port 465, so a URL list must be able to match every SMTP 465 connection directly by SNI.”
A more rigorous engineering conclusion is:
A firewall’s ability to obtain a hostname does not automatically mean that a particular URL or FQDN policy can use that hostname for matching. The final behavior depends on the firewall product’s support for the protocol and policy type.
11. Designing a Policy That Only Allows an Approved Mail Server
Assume that the application may connect only to:
smtp.example.com
Controls can be applied at multiple layers:
Application
|
|
v
Network Firewall
|
+------------+------------+
| |
v v
L3/L4 Policy FQDN / URL
| |
Destination IP Domain Policy
Port 25 / 465
| |
+------------+------------+
|
v
Mail Server
For higher-security requirements, also consider:
- Whether DNS is trusted
- Whether the SMTP server uses stable IP addresses
- Whether the domain resolves to multiple IP addresses
- Whether TLS and SNI are present
- Whether TLS inspection is required
- Whether the firewall supports FQDN identification for this SMTP scenario
- Whether IP address and port restrictions should also be applied
- Whether firewall logs should be retained for validation
12. Troubleshooting
When an application cannot connect to an SMTP server, investigate it in the following order.
Step 1: DNS
nslookup smtp.example.com
Confirm the mapping:
smtp.example.com
↓
IP address
Step 2: TCP
Test port 25:
nc -vz smtp.example.com 25
or port 465:
nc -vz smtp.example.com 465
Confirm whether the TCP connection can be established.
Step 3: Port 25
When STARTTLS is used, test SMTP and TLS negotiation:
openssl s_client -starttls smtp -connect smtp.example.com:25
Inspect:
- SMTP banner
- STARTTLS negotiation
- TLS handshake
- Certificate
- SNI or server name
Step 4: Port 465
Use:
openssl s_client -connect smtp.example.com:465 -servername smtp.example.com
Inspect:
- TLS handshake
- Certificate
- SNI
- TLS version
- Cipher suite
Step 5: Firewall
Finally, inspect firewall logs for:
Source
Destination
Port
Application
Policy
Action
TLS / Decryption
This helps determine whether the connection was rejected at the network layer, failed to match a firewall policy, or failed during TLS or SMTP negotiation.
13. Conclusion
The main difference between SMTP ports 25 and 465 is not:
One has a domain and the other does not.
The actual difference is:
The position at which TLS begins in the SMTP communication flow.
Port 25 with STARTTLS
DNS
↓
TCP:25
↓
SMTP
↓
STARTTLS
↓
TLS
↓
Encrypted SMTP
Port 465 with Implicit TLS
DNS
↓
TCP:465
↓
TLS
↓
Encrypted SMTP
When discussing firewall domain filtering, domain information should be understood as coming from several possible sources:
Domain / FQDN
|
+--------------+--------------+
| | |
v v v
DNS SNI SMTP/Application
| | |
+--------------+--------------+
|
v
Firewall
|
v
Policy Match
The key point is:
A TCP connection knows the IP address and port. Domain information must come from DNS, TLS/SNI, an application-layer protocol, or another source.
Whether a firewall can use that information for domain or FQDN filtering depends on its protocol identification capabilities, supported policy types, and enabled inspection features.
14. References
- RFC 8314 — Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
- Oracle Cloud Infrastructure Network Firewall documentation
- Oracle Cloud Infrastructure Network Firewall — URL/FQDN filtering
- Oracle Cloud Infrastructure Network Firewall — SSL/TLS inspection