SMTP ports 25, 587, 465 and 2525: which one to use, how to test it, and the IMAP and POP3 ports

Short answer: to send mail from an app, a script or a mail client, use port 587 with STARTTLS or port 465 with TLS from the first byte, and log in. Port 25 is for mail servers delivering to each other, not for you. To read mail, IMAP uses 993 (TLS) or 143, and POP3 uses 995 (TLS) or 110. All of them run over TCP only.

IANA lists UDP next to several of these numbers, but no mail protocol uses UDP, so a firewall rule for mail only needs TCP. Port 2525 is not a mail port at all in the IANA registry (it is assigned to an unrelated service); it works only where a provider has chosen to listen on it. SendGrid and Mailgun, for example, list it next to 587, with the same STARTTLS behaviour.

Which port should an app or script use?

Port 587 or 465, with the username and password of the account you send from. Never point an application at port 25 of your provider’s or your own server for sending. Port 25 on a mail server accepts mail for the domains that server is responsible for, plus relaying for clients it already trusts, and many networks block it outbound anyway. The message submission standard (RFC 6409) tells the server on 587 to refuse mail, by default, until the client has logged in, which is what you want.

The common mistake is pairing the port with the wrong encryption setting. Libraries name the two modes differently, and “SSL” and “TLS” in a settings screen usually mean “TLS from the start” and “STARTTLS”:

Get it wrong and the failure looks like a network problem. A client that starts TLS on port 587 gets a plain-text greeting back, and OpenSSL-based clients report wrong version number. A client that expects a plain-text greeting on port 465 gets none, because the server is waiting for a TLS handshake; the connection hangs until the server gives up and closes it (after ten seconds in our test against Gmail) or the client times out.

A minimal Python sender for port 587. Replace SMTP_HOST, SMTP_USER, SMTP_PASSWORD and the two addresses with your own:

import smtplib
import ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "app@example.com"
msg["To"] = "you@example.com"
msg["Subject"] = "Test from the server"
msg.set_content("It works.")

ctx = ssl.create_default_context()
with smtplib.SMTP("SMTP_HOST", 587, timeout=15) as s:
    s.starttls(context=ctx)
    s.login("SMTP_USER", "SMTP_PASSWORD")
    s.send_message(msg)

For a mailbox at a large provider, use the host names from the provider’s own help pages. These are the values as of October 2026; each host answered on these ports with a valid certificate when we connected:

None of them wants your normal account password in an app. Apple and Yahoo ask for an app password, Google for an app password (which needs 2-Step Verification) or a “Sign in with Google” login, and Microsoft lists OAuth for Outlook.com.

Port 587 or 465?

Both are standard, and both are fine. On 587 the session starts in plain text, the client sends STARTTLS, and the rest is encrypted. On 465 TLS starts before the first SMTP line, as it does for HTTPS. RFC 8314 (2018) registered 465 again for this purpose under the name submissions, asks servers and clients to support both ports, and says the two are equally secure when both sides insist on TLS. So the frequent advice that 465 is “deprecated” or “legacy” is out of date.

The practical difference is what happens when something interferes. With STARTTLS, a client that carries on in plain text when the server does not offer the upgrade can be downgraded by anyone in the path. Make sure yours refuses that: set requireTLS in Nodemailer; Python’s starttls() already raises an error when the server does not offer it. Port 465 has no plain-text phase to attack, which is why RFC 8314 wants mail clients to move to implicit TLS over time. If both ports are open, either is correct; 465 is the one with less to get wrong.

Port 25: delivery between servers, and why it is often blocked

When a server delivers mail to you@example.com, it looks up the MX record of example.com and connects to that host on port 25. An MX record has no field for a port, so delivery between servers is port 25 by definition. Encryption there is opportunistic: both sides use STARTTLS if both support it. A domain that wants to make TLS mandatory for incoming mail publishes an MTA-STS policy (RFC 8461) or DANE records.

This is a real exchange with Gmail’s inbound server on port 25, our address replaced with a documentation address. Note that it offers STARTTLS but no AUTH: an MX server does not take logins, it takes mail for its own domains.

220 mx.google.com ESMTP 5b1f17b1804b1-4a19026b877si161509505e9.3 - gsmtp
250-mx.google.com at your service, [203.0.113.10]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
221 2.0.0 closing connection 5b1f17b1804b1-4a19026b877si161509505e9.3 - gsmtp

Outbound port 25 is the one most often blocked. Home internet providers block it so that an infected PC cannot send spam directly, and many cloud and VPS providers block it by default and open it on request or never. Test from the server itself:

nc -vz -w 5 gmail-smtp-in.l.google.com 25

Debian does not install nc by default; add it with sudo apt install netcat-openbsd. A line ending in succeeded! means the path is open. A timeout means something between you and Google drops the connection, usually the provider. In that case, send through a relay (a “smarthost”) on 587 or 465 with an account there; in Postfix that is the relayhost setting plus SASL credentials. Before you set up a mail server on a VMHeaven server, read the Acceptable Use Policy or ask support how port 25 is handled on the plan you use. The AUP forbids unsolicited bulk mail, and any activity that leads to a blocklist entry (Spamhaus, for example) can lead to suspension or termination.

How to test an SMTP port from the command line

First check that the port answers at all, from the machine that will send. Replace smtp.example.com with your server:

nc -vz -w 5 smtp.example.com 587

Test-NetConnection -ComputerName smtp.example.com -Port 587

TcpTestSucceeded : True on Windows, or succeeded! from nc, only proves a TCP connection. To see whether the server speaks SMTP with a valid certificate, open a real session with openssl s_client. For port 587:

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

Once the TLS summary appears, type EHLO client.example.com and press Enter. A healthy submission server, here Gmail’s, answers like this:

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = smtp.gmail.com
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Verified peername: smtp.gmail.com
Server Temp Key: X25519, 253 bits
250 SMTPUTF8
250-smtp.gmail.com at your service, [203.0.113.10]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

• Verification: OK and Verified peername mean the certificate chain is trusted and matches the name you gave. A wrong name shows Verification error: hostname mismatch, and openssl carries on with the session anyway, so read that line. Without -verify_hostname, openssl checks only the chain, and a certificate for another name would pass.
• 250-AUTH lists the login methods. Many servers offer it only after TLS: before STARTTLS, Gmail’s list on 587 has STARTTLS and no AUTH.
• The lone 250 SMTPUTF8 under the summary is left over from the plain-text EHLO that openssl sends by itself before STARTTLS (as mail.example.com, unless you add -name).

On a Mac, the built-in openssl is LibreSSL, which understands -starttls, -crlf and -quiet but not -brief or -verify_hostname: leave those two out, or install OpenSSL with Homebrew. For port 465, drop -starttls smtp. The 220 greeting now arrives inside TLS:

openssl s_client -connect smtp.example.com:465 -crlf -brief -verify_hostname smtp.example.com

Verification: OK
Verified peername: smtp.gmail.com
Server Temp Key: X25519, 253 bits
220 smtp.gmail.com ESMTP ffacd0b85a97d-48db9aac6a4sm14598922f8f.28 - gsmtp
250-smtp.gmail.com at your service, [203.0.113.10]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

What the other answers mean:

• Didn't find STARTTLS in server response, trying anyway...: the server did not offer STARTTLS. On your own server that usually means no certificate is configured for that port.
• wrong version number: you started TLS on a port that expects plain text first, such as 587 or 25 without -starttls smtp.
• unexpected eof while reading at the end: harmless. The server closed the connection without a TLS goodbye.
• RCPT TO or QUIT never reaches the server: without -quiet, openssl treats a line that starts with a capital R (renegotiate) or Q (quit) as its own command. Type SMTP commands in lower case, which servers accept, or add -quiet.

-crlf makes openssl end each line with CR LF, as SMTP requires. If you pipe commands in, add -quiet or -ign_eof so that openssl waits for the answers instead of hanging up at the end of the input, and end each line with a plain \n; adding \r yourself doubles it, and stricter servers answer with an error.

IMAP and POP3 ports

Reading mail uses different ports from sending. IMAP keeps the mail on the server and syncs every device; POP3 downloads it to one. Both have a TLS-from-the-start port (993 and 995), which RFC 8314 recommends, and a plain port with STARTTLS (143 and 110). Test them the same way:

openssl s_client -connect imap.example.com:993 -crlf -quiet

Type a1 CAPABILITY, then a2 LOGOUT. A working server, here Gmail’s, greets and lists what it supports:

* OK Gimap ready for requests from 203.0.113.10 5b1f17b1804b1-4a1829d890dmb1672931135e9
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER
a1 OK Thats all she wrote! 5b1f17b1804b1-4a1829d890dmb1672931135e9

For POP3 use port 995 and the command CAPA; a server answers +OK. For the plain ports, add -starttls imap (port 143) or -starttls pop3 (port 110).

Running your own mail server: ports and firewall

A self-hosted mail server needs port 25 open inbound from everywhere, or no other server can deliver to it. Open 587 and/or 465 for your own users to send, and 993 for IMAP. Keep 143 and 110 closed unless an old client needs them. Check what actually listens:

sudo ss -tlnp '( sport = :25 or sport = :465 or sport = :587 or sport = :993 )'

State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*     users:(("master",pid=1240,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*     users:(("master",pid=1240,fd=17))
LISTEN 0      100          0.0.0.0:465       0.0.0.0:*     users:(("master",pid=1240,fd=21))
LISTEN 0      100          0.0.0.0:993       0.0.0.0:*     users:(("dovecot",pid=1188,fd=37))

master is Postfix. In Postfix, 587 and 465 are the submission and submissions services in /etc/postfix/master.cf (older files call 465 smtps), and the stock file ships both commented out. Then open the ports.

sudo ufw allow 22/tcp
sudo ufw allow 25,465,587,993/tcp
sudo ufw enable
sudo ufw status verbose

sudo firewall-cmd --permanent --add-service=smtp --add-service=smtps --add-service=imaps
sudo firewall-cmd --permanent --add-port=587/tcp
sudo firewall-cmd --reload

Then check from outside that the server is not an open relay, which would let anyone send spam through it. Connect to port 25 from another server that is not in Postfix’s mynetworks (a home connection often cannot reach port 25 at all):

openssl s_client -starttls smtp -connect mail.example.com:25 -crlf -quiet

Type ehlo test.example.net, then mail from:<test@example.net>, then rcpt to:<someone@example.org> (a domain your server does not host), then quit. The recipient must be refused:

250 2.1.0 Ok
454 4.7.1 <someone@example.org>: Relay access denied

Postfix answers 454 with its default relay rules (defer_unauth_destination) and 554 if you use reject_unauth_destination. A 250 to that recipient means the server relays for strangers: fix that before anything else. To check that port 25 is reachable from the internet at all, the open port checker tries a TCP connection from our Amsterdam server.

DNS records a mail server needs

Open ports only get your mail delivered if receivers trust it. They check these records, all of which point at the same host name, here mail.example.com on 203.0.113.25:

The PTR record is the one people miss, because it is not in your domain’s DNS at all. It belongs to whoever holds the IP address. Its name must resolve back to the same address (Gmail requires that of every sender) and should be the name the server gives in EHLO. On VMHeaven you set it yourself in the panel, next to each address, and it takes effect within about 30 minutes. The reverse DNS and PTR guide covers setting it, IPv6 and what to do when it does not update.

To see all of it the way a receiver does, run the domain through the mail server check: it reads MX, reverse DNS, SPF, DKIM, DMARC and MTA-STS from DNS and never connects to your server. The blacklist check shows whether your server’s address is already on a public blocklist, which a new server can inherit from whoever used the address before.

A mail server is a small workload: a Standard KVM plan has enough room for Postfix, Dovecot and a spam filter, and Standard and Hi-CPU KVM run on our clean IP range under a strict no-abuse policy. Every server has root access, its own IPv4 address and rDNS you set from the panel. Telling a port that listens only on 127.0.0.1 from one the internet can reach is covered in the guide to checking open ports, and firewall defaults are in UFW firewall setup.

Frequently asked