SMTP Ports 465 and 587: Which One Your Mail Client Should Use

When you set up an email account by hand, the outgoing server screen asks for a hostname, a port and a security setting. The port is almost always 587 or 465, and the security setting is some variation of "STARTTLS" or "SSL/TLS". Pick the wrong pairing and the app spins for a minute and then reports that it could not connect, with nothing to tell you which half was wrong.

The two ports exist for the same purpose. They differ only in how the encrypted connection gets started, and once you see that, the settings screen stops being a guessing game.

The short answer#

• Port 587 is message submission. The connection opens in cleartext, the server advertises that it supports encryption, and the client sends the STARTTLS command to upgrade before logging in.
• Port 465 is message submission over implicit TLS. The TLS handshake happens the moment the connection opens, before the server even says hello. There is no cleartext phase.

Once the connection is encrypted, what happens next is identical on both: the client authenticates with a username and password (or a token), sends the message, and the provider takes it from there. RFC 8314, the 2018 standard that governs this, says there is no significant difference in security between the two, as long as both client and server require TLS to succeed before any mail is submitted. That condition is the whole story, and we will come back to it.

Submission is not relay#

Email moves in two distinct hops, and they use different ports.

• Submission is your mail app handing a new message to your own provider's server. You are a known customer, so the server requires you to log in. This is 587 or 465.
• Relay is your provider's server delivering that message to the recipient's server, which it finds by looking up the recipient domain's MX records. This is always port 25, because an MX record names a host and has no field for a port.

The split exists partly because of spam. RFC 6409, the submission standard, notes that many networks block outbound traffic on port 25 so that infected machines cannot send mail directly, which pushes legitimate users onto a submission server that insists on authentication. The same RFC says a submission server must, by default, refuse to accept mail from a session that has not logged in. That is why you can usually reach 587 from a home connection even when 25 is blocked.

This split also marks where different protections apply. Standards such as MTA-STS and DANE secure the relay hop on port 25, between mail servers. They say nothing about the connection from your laptop to your provider. You can check a domain's relay-side policy with our MTA-STS checker, but the submission hop is protected by the port and security setting in your mail app, and nothing else.

Port 587: submission with STARTTLS#

IANA registers 587 as submission, referencing RFC 6409. A session looks like this: the client connects, the server sends a greeting, the client sends EHLO, and the server replies with a list of the features it supports. If STARTTLS is in that list, the client sends the command, the server answers 220 Ready to start TLS, and the two sides run a TLS handshake over the same connection. The client then sends EHLO again and carries on, now encrypted.

The weakness is in the part before the upgrade. RFC 3207, which defines STARTTLS for SMTP, describes the attack itself: someone in the network path deletes the STARTTLS line from the server's feature list, and the client never tries to encrypt. A client that treats encryption as optional will then log in and send the password in the clear. The defence is a client set to require STARTTLS, which drops the connection instead of carrying on.

There was a subtler problem too. Because the connection starts in cleartext, an attacker could slip extra commands into the stream just before the upgrade, and some servers processed them as if they had arrived inside the encrypted session. CERT tracked this in 2011 as a STARTTLS command injection flaw found independently in several mail servers. RFC 3207 already required both sides to discard anything learned before the handshake, and the fix was to enforce that properly. The authors of RFC 8314 point to this episode as evidence that the upgrade design invites implementation mistakes.

Port 465: submission over implicit TLS#

On 465 the client opens the connection and immediately starts a TLS handshake. Only after it completes does the server send its SMTP greeting. If the handshake fails, there is no plain session to fall back to, and nothing an attacker can strip out, because no feature list is exchanged in the clear.

The port has an awkward history. It was briefly registered for SMTP over TLS, the registration was withdrawn, and the number went to another protocol, yet mail software kept using it for encrypted submission. RFC 8314 made that usage official in 2018 with a second registration, service name submissions. Our explainer on how IANA port assignments work covers why 465 now carries two names. What matters in practice is that 465 is a fully standard submission port, not a legacy leftover.

RFC 8314 goes further than legitimising it. It recommends that mail clients connect to submission servers using implicit TLS in preference to STARTTLS, and it asks clients and servers to support both 587 and 465 during a transition period. The reasoning is simple: a connection that is encrypted from the first byte has fewer ways to go wrong.

Which one should you pick#

• Use what your provider documents. Most large providers accept both. If their setup page lists only one, use that one.
• If both are offered, prefer 465. It follows the current standard's recommendation, and a misconfigured client fails loudly instead of quietly sending a password unencrypted.
• If you use 587, set the security option to require STARTTLS, not "use if available". The difference between those two settings is the difference between a protected login and one an attacker can downgrade.
• Do not use 25 for submission unless your provider tells you to. It is often blocked on home and mobile connections, and servers listening there are set up to receive mail from other servers.

You may also see port 2525 in the documentation for bulk sending services. SendGrid, for example, lists it alongside 25 and 587. It is not a mail port in IANA's registry, where 2525 is assigned to an unrelated service. Providers offer it as a fallback for networks that block the standard numbers, so treat it as a provider-specific setting rather than a standard one.

Why the wrong setting hangs instead of failing#

Many mail apps label the two security options "SSL/TLS" and "STARTTLS". "SSL/TLS" means implicit TLS and belongs with 465. "STARTTLS" belongs with 587. Swap them and the two sides wait on each other:

• STARTTLS on 465: the client connects and waits for a text greeting. The server is waiting for a TLS handshake. Neither speaks, and the connection times out.
• SSL/TLS on 587: the client opens with a TLS handshake. The server replies with a plain-text greeting, which the client cannot parse as TLS, so you get a handshake or "wrong version number" style error.

So a long pause before an error usually points to STARTTLS on 465, and an immediate TLS error points to SSL/TLS on 587. If the connection succeeds but login fails, the port is fine and the problem is the credentials. Many providers now require an app-specific password or an OAuth sign-in instead of your normal password.

Testing a submission server#

OpenSSL can speak just enough SMTP to test both modes from any machine that has it installed:

• openssl s_client -connect smtp.example.com:465 tests implicit TLS. You should see a certificate chain, then a 220 greeting from the mail server.
• openssl s_client -starttls smtp -connect smtp.example.com:587 tests STARTTLS. OpenSSL reads the greeting, sends EHLO and STARTTLS, then shows the certificate the same way.

In the output, check that the certificate's name matches the hostname you configured and that it has not expired. A certificate for a different name is a common reason one client connects and a stricter one refuses. Our explainers on certificate chains and TLS 1.2 versus 1.3 help with reading the rest of it.

If the command hangs with no output at all, the port is probably filtered on your network. Try the same command from a different connection before assuming the server is down.

What the message headers record#

Each server that handles a message adds a Received header, and the first one added by your provider describes the submission hop. Look for the protocol word after with. Under RFC 3848, ESMTPS means the session used TLS, ESMTPA means the sender authenticated, and ESMTPSA means both. RFC 8314 also asks submission servers to record the negotiated TLS cipher suite in that header, and some do. You can paste a full header into our email header analyzer to see every hop in order, or read our guide to reading email headers for what each field means.

The takeaway mirrors the one for LDAP's ports 389 and 636. The port number alone does not make a connection safe. Implicit TLS on 465 is encrypted by design, while STARTTLS on 587 is encrypted only if the client refuses to continue without it. Check that setting once, and the most common way a mail password leaks is closed.