Common Mail and Web Ports Explained (and STARTTLS)
Each of the ports below has a specific, historically-defined job. Mixing them up (like configuring a mail client to submit through port 25 instead of 587) is a common source of "it should be working" connectivity problems.
Last updated: August 29, 2026
Port reference
| Port | Protocol | Purpose | Encryption |
|---|---|---|---|
| 25 | SMTP | Server-to-server mail relay | STARTTLS |
| 587 | SMTP Submission | Client/app sending mail via provider | STARTTLS |
| 465 | SMTPS | Client/app sending mail via provider | Implicit TLS |
| 143 | IMAP | Reading mail (mailbox sync) | STARTTLS |
| 993 | IMAPS | Reading mail (mailbox sync) | Implicit TLS |
| 110 | POP3 | Reading/downloading mail | STARTTLS |
| 995 | POP3S | Reading/downloading mail | Implicit TLS |
| 80 | HTTP | Web traffic | None (plaintext) |
| 443 | HTTPS | Web traffic | Implicit TLS |
Implicit TLS vs STARTTLS
On an implicit TLS port (465, 993, 995, 443), the TLS handshake happens the moment the connection opens; there's never a plaintext phase. On a STARTTLS port (25, 587, 143, 110, and optionally 80 via similar upgrade mechanisms), the connection starts in plaintext and the client explicitly requests an upgrade to TLS mid-conversation. This means a STARTTLS connection briefly exists in plaintext, which is exactly the window a downgrade attack (see the MTA-STS guide) targets by simply blocking that upgrade request.
Why port 25 is different from 587
Port 25 is for server-to-server relay: one mail system delivering to another. Port 587 is the submission port, meant for an end-user's mail client or an application to hand off outgoing mail to their own provider, authenticated with a username and password. Most residential ISPs block outbound port 25 entirely to cut down on spam from compromised home devices, which is why "just send it on 25" almost never works from a laptop or a typical app server. 587 (or 465) with authentication is the correct choice.
Why an open port with no STARTTLS is a red flag
If a STARTTLS-capable port responds but never offers the STARTTLS upgrade, any client connecting to it has no way to encrypt the session. Mail (or credentials, for IMAP/POP3) would go over that connection in plaintext. That's worth fixing even if the port "works," since working and working securely aren't the same thing.
Test TCP connectivity to common mail, web and sysadmin ports with banner grab and STARTTLS detection.
Frequently asked questions
What port should my email client actually use to send mail?
587 with STARTTLS (or 465 with implicit TLS), authenticated with your provider's credentials. Not 25, which is for server-to-server relay and is commonly blocked outbound by residential ISPs anyway.
Why is port 25 often blocked by ISPs?
Mainly to reduce spam sent directly from compromised home devices acting as their own tiny mail servers. Legitimate outbound mail from an end user or application is expected to go through the provider's authenticated submission port (587/465) instead.
What does "STARTTLS not offered" mean in a scan result?
It means the server responded on that port but never advertised the ability to upgrade the connection to TLS, so anything sent over it, including credentials, would travel unencrypted unless the client refuses to proceed.
Is a closed mail port always a problem?
No. If you're not running a mail server on that host at all, a closed port is expected and fine. It only matters if the host is supposed to be handling mail on that port.