These ports 465 and 587 are both used for sending mail (submitting mail) but what is the real difference between them?
-
1The only difference is formalized standards and *465* port is for legacy support? – Ilia Ross Apr 03 '13 at 19:45
-
iana's ["Service Name and Transport Protocol Port Number Registry"](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) is the formal guide to the recommended use of ports; the use of 465 for SMTP over SSL is unofficial. Read about Ports in [SMTP](http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol). iana's official usage is not always the same for both the TCP and UDP transport protocols. N.B.: if you are the SMTP _server administrator_, YOU control which port(s) are used; if you are the _client_, you get only ports made available to you. – gerryLowry Dec 03 '14 at 08:18
-
related: http://stackoverflow.com/questions/3484947/why-should-i-convince-developers-to-use-port-587-for-all-smtp-communication – Ciro Santilli OurBigBook.com Dec 21 '15 at 22:17
-
related: https://www.fastmail.com/help/technical/ssltlsstarttls.html – Rick Apr 24 '20 at 04:24
6 Answers
SMTP protocol: smtps (port 465) v. msa (port 587)
Ports 465 and 587 are intended for email client to email server communication - sending out email using SMTP protocol.
Port 465 is for smtps
SSL encryption is started automatically before any SMTP level communication.
Port 587 is for msa
It is almost like standard SMTP port.
MSA should accept email after authentication (e.g. after SMTP AUTH). It helps to stop outgoing spam when netmasters of DUL ranges can block outgoing connections to SMTP port (port 25).
SSL encryption may be started by STARTTLS command at SMTP level if server supports it and your ISP does not filter server's EHLO reply (reported 2014).
Port 25 is used by MTA to MTA communication (mail server to mail server). It may be used for client to server communication but it is not currently the most recommended. Standard SMTP port accepts email from other mail servers to its "internal" mailboxes without authentication.

- 10,493
- 3
- 23
- 47
-
10*Standard SMTP port accepts email from other mail server without authentication* - is not actually technically correct. Standard 25 port can transfer mail both using authentication and not depending on the configuration of MTA. – Ilia Ross Apr 03 '13 at 20:42
-
2@Ilia standard SMTP port of normal MTA can not reject (all) unauthenticated SMTP connections. – AnFi Apr 03 '13 at 21:07
-
1How about Postfix? It doesn't let relaying mail by default but only for *connections from same network*? – Ilia Ross Apr 03 '13 at 21:47
-
4
-
8Note that while unofficial, port 465 offers the end user more assurance that they are really talking over an encrypted channel. Port 587, with TLS being optional, means an end user could be providing their credentials over an unencrypted channel. With email clients being what they are, you cannot guarantee the MUA is going to even alert the user that the connection has been downgraded. – sporker May 19 '17 at 20:55
-
2Since [RFC 8314][https://tools.ietf.org/html/rfc8314#section-7.3], port 465 is for msa over TLS. – mndrix May 14 '19 at 19:18
-
1
-
1@AaronFranke IMHO it better to choose SMTPS when SMTPS and MSA are available. – AnFi Apr 04 '20 at 07:34
587 vs. 465
These port assignments are specified by the Internet Assigned Numbers Authority (IANA):
- Port 587: [SMTP] Message submission (SMTP-MSA), a service that accepts submission of email from email clients (MUAs). Described in RFC 6409.
- Port 465: URL Rendezvous Directory for SSM (entirely unrelated to email)
Historically, port 465 was initially planned for the SMTPS encryption and authentication “wrapper” over SMTP, but it was quickly deprecated (within months, and over 15 years ago) in favor of STARTTLS over SMTP (RFC 3207). Despite that fact, there are probably many servers that support the deprecated protocol wrapper, primarily to support older clients that implemented SMTPS. Unless you need to support such older clients, SMTPS and its use on port 465 should remain nothing more than an historical footnote.
The hopelessly confusing and imprecise term, SSL, has often been used to indicate the SMTPS wrapper and TLS to indicate the STARTTLS protocol extension.
For completeness: Port 25
- Port 25: Simple Mail Transfer (SMTP-MTA), a service that accepts submission of email from other servers (MTAs or MSAs). Described in RFC 5321.
Sources:
- IANA Service Name and Transport Protocol Port Number Registry
- “Revoking the smtps TCP port” - Email from Internet Mail Consortium director Paul Hoffman, 12 Nov 1998.
- RFC 6409 - Message Submission for Mail
- RFC 5321 - Simple Mail Transfer Protocol
- RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
- RFC 4607 - Source-Specific Multicast for IP
-
1
-
14`SMTPS and its use on port 465 should remain nothing more than an historical footnote.` Except that Gmail and most other email providers use Port 465 for SSL aka SMTPS. It is a reality that's not going anywhere, no matter what IANA specifies. – Eric J. Oct 20 '15 at 20:34
-
6@EricJ. ...But gmail also supports port 587. Do you know which port Google uses internally? Otherwise, the fact that they **support** 465 doesn't really count as evidence it's preferred or even particularly commonly used. – Parthian Shot Mar 21 '16 at 14:10
-
2Well, we are at 2018 and i see no port becoming history. `456` still being used by big players. Also, i would edit my answer to reflect that IANA is a mess, and they still dont agree if they should use `456` or not - RFC 8314 https://tools.ietf.org/html/rfc8314#page-6 - `When a TCP connection is established for the "submissions" service (default port 465), a TLS handshake begins immediately` - This RFC is referenced by your "Port 456" link :) - registration date: 2017-12-12 – Mar 07 '18 at 20:42
-
1"Rendezvous" spelling has now been corrected at [iana.org](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=465) – arni Aug 07 '18 at 15:14
-
3This should be updated to reflect that IANA now has port 465 assigned to both `urd` and `submissions` and that [RFC8314](https://tools.ietf.org/html/rfc8314) recommends implicit TLS / port 465 for message submission. – Billy Dec 03 '18 at 00:32
-
Thank you very much, I had to fallback using 465 due to a issue with my TLS on 587. This just confirmed that I should focus on making 587 work. – May 06 '20 at 00:08
-
2Have you noticed RFC 8314 already? See here: https://tools.ietf.org/html/rfc8314 - basically, 587 is going to be deprecated and port 465 will be used for SMTP over TLS. Note that this new RFC updates RFC 6409 which you answer is based on. – Mikko Rantalainen Nov 13 '20 at 15:25
-
1Also note that port 465 has been registered with IANA for SMTP over TLS *in addition to* Cisco SSM: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=submissions – Mikko Rantalainen Nov 13 '20 at 15:26
The correct answer to this question has been changed by the publication of RFC 8314. As a result, port 465 and 587 are both valid ports for a mail submission agent (MSA). Port 465 requires negotiation of TLS/SSL at connection setup and port 587 uses STARTTLS if one chooses to negotiate TLS. The IANA registry was updated to allow legitimate use of port 465 for this purpose. For mail relay, only port 25 is used so STARTTLS is the only way to do TLS with mail relay. It's helpful to think of mail relay and mail submission as two very different services (with many behavior differences like requiring auth, different timeouts, different message modification rules, etc.) that happen to use a similar wire protocol.
-
1
-
1If you are running a public SMTP service: both for compatibility. If it is private, prefer Implicit TLS on 465 unless you must support clients that do not support it. Supporting excerpt: "However, to maximize the use of encryption for submission, it is desirable to support both mechanisms for Message Submission over TLS for a transition period of several years. As a result, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period" https://tools.ietf.org/html/rfc8314#section-3.3 – Alain O'Dea May 22 '20 at 14:57
-
**Prefer port 465** for Implicit TLS for SMTP submission, per the recommendations in [RFC8314](https://datatracker.ietf.org/doc/html/rfc8314#section-1). – evan.bovie Mar 08 '22 at 07:44
I use port 465 all the time.
The answer by danorton is outdated. As he and Wikipedia say, port 465 was initially planned for the SMTPS encryption and quickly deprecated 15 years ago. But a lot of ISPs are still using port 465, especially to be in compliance with the current recommendations of RFC 8314, which encourages the use of implicit TLS instead of the use of the STARTTLS command with port 587. (See section 3.3). Using port 465 is the only way to begin an implicitly secure session with an SMTP server that is acting as a mail submission agent (MSA).
Basically, what RFC 8314 recommends is that cleartext email exchanges be abandoned and that all three common IETF mail protocols be used only in implicit TLS sessions for consistency when possible. The recommended secure ports, then, are 465, 993, and 995 for SMTPS, IMAP4S, and POP3S, respectively.
Although RFC 8314 certainly allows the continued use of explicit TLS with port 587 and the STARTTLS command, doing so opens up the mail user agent (MUA, the mail client) to a downgrade attack where a man-in-the-middle intercepts the STARTTLS request to upgrade to TLS security but denies it, thus forcing the session to remain in cleartext.
-
6He is correct. Just because ISPs abuse it and haven't updated their documentation does not make it incorrect. He didn't say it isn't used - just that it is not a practice that follows the RFCs. In other words, you should be using 25 and 587 with email, and only use 465 if you HAVE to, for some reason. – dodexahedron Jun 20 '18 at 05:58
-
2PREFER port 465 over port 587, as 465 is used for Implicit TLS for SMTP submission, which follows the recommendations in [RFC8314](https://datatracker.ietf.org/doc/html/rfc8314#section-1). It recommends that "connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command." – evan.bovie Mar 08 '22 at 07:26
-
@dodexahedron Section 3.3 of the RFC is pretty clear: https://www.rfc-editor.org/rfc/rfc8314#section-3.3 The RFC says "it is desirable to migrate core protocols ... to implicit TLS over time." So it is most certainly a "practice that follows the RFCs" to use port 465. – Kaiser Keister Jan 25 '23 at 00:46
-
This is not entirely accurate. Yes, the move to TLS is recommended. That is orthogonal to the recommended port usage. Port 465, specifically, is not recommended, because IANA has reassigned the port, as mentioned in another comment here and in the RFC itself, which has a section discussing this problem, specifically (7.3 and other parts). 587 and STARTTLS are the preferred modern mechanisms. 465 is, essentially, legacy, and shouldn't be used for new deployments. – dodexahedron Mar 02 '23 at 22:44
-
1
Port 465: IANA has reassigned a new service to this port, and it should no longer be used for SMTP communications.
However, because it was once recognized by IANA as valid, there may be legacy systems that are only capable of using this connection method. Typically, you will use this port only if your application demands it. A quick Google search, and you'll find many consumer ISP articles that suggest port 465 as the recommended setup. Hopefully this ends soon! It is not RFC compliant.
Port 587: This is the default mail submission port. When a mail client or server is submitting an email to be routed by a proper mail server, it should always use this port.
Everyone should consider using this port as default, unless you're explicitly blocked by your upstream network or hosting provider. This port, coupled with TLS encryption, will ensure that email is submitted securely and following the guidelines set out by the IETF.
Port 25: This port continues to be used primarily for SMTP relaying. SMTP relaying is the transmittal of email from email server to email server.
In most cases, modern SMTP clients (Outlook, Mail, Thunderbird, etc) shouldn't use this port. It is traditionally blocked, by residential ISPs and Cloud Hosting Providers, to curb the amount of spam that is relayed from compromised computers or servers. Unless you're specifically managing a mail server, you should have no traffic traversing this port on your computer or server.

- 10,246
- 7
- 52
- 62

- 85
- 1
- 1
-
1This answer is now incorrect, port 465 for Implicit TLS for SMTP submission is preferred, per the recommendations in [RFC8314](https://datatracker.ietf.org/doc/html/rfc8314#section-1). See my [above comment](https://stackoverflow.com/questions/15796530/what-is-the-difference-between-ports-465-and-587#comment126188394_32460763). – evan.bovie Mar 08 '22 at 07:30
I don't want to name names, but someone appears to be completely wrong. The referenced standards body stated the following: submissions 465 tcp Message Submission over TLS protocol [IESG] [IETF_Chair] 2017-12-12 [RFC8314]
If you are so inclined, you may wish to read the referenced RFC.
This seems to clearly imply that port 465 is the best way to force encrypted communication and be sure that it is in place. Port 587 offers no such guarantee.
-
-
1"When a TCP connection is established ... [to] port 465, a TLS handshake begins immediately." This model is "inherently simpler to implement, debug, and deploy." Connections to port 587 are made in "cleartext" and TLS is negotiated _afterward_ using the STARTTLS command. "Although there's nothing inherently wrong with [it], the fact that it resulted in a common implementation error (made independently by multiple implementers) suggests that it is a less secure architecture than Implicit TLS." See [RFC8314 Appendix A](https://datatracker.ietf.org/doc/html/rfc8314#appendix-A) for discussion. – evan.bovie Mar 08 '22 at 07:43