SMTP Ports: What 25, 465, 587 and 2525 Are Registered For

One setup guide tells you to use port 587. The next one says 465. A third offers 2525 as the fallback "if your host blocks the others", with no explanation of what 2525 is. Three answers, one connection, and the disagreement is not really about email at all. It is about which of these numbers a standards body actually assigned to mail, and which one a vendor started using because a firewall was in the way.

IANA's service-name registry settles most of it in about a minute: port 465 carries the service name submissions, 587 submission and 25 smtp. The one place it does not settle is the interesting part.

What Is The IANA Service Name For Port 465?

IANA lists two service names on TCP port 465: submissions, "Message Submission over TLS", referenced to RFC 8314 and dated 12 December 2017, and urd, a URL Rendezvous Directory service unrelated to mail. Port 587 is submission, "Message Submission", under RFC 6409, and port 25 is smtp, "Simple Mail Transfer".

IANA maintains the Service Name and Transport Protocol Port Number Registry, and every number in circulation resolves there. Port 2525 is ms-v-worlds. It is not a mail port, it has never been a mail port, and no RFC mentions it in this context.

That last line is worth sitting with, because port 2525 appears in a great many vendor setup pages beside the registered ports as though it were a peer of them. It is a convention, offered by hosts whose customers find the real ports blocked. It works when the far end has chosen to listen there. It is not a standard, it is not more or less secure than anything else, and nothing about it is guaranteed by anyone.

Relay and submission are two different jobs

The reason there is more than one mail port is that there are two different transactions, and the specifications separate them deliberately.

RFC 5321 defines SMTP itself, and its receiving-strategy section says an SMTP server should attempt to keep a pending listen on the SMTP port, specified by IANA as port 25, at all times. That is server-to-server relay: one mail transfer agent handing a message to the next, unauthenticated, addressed by the recipient's MX records. Because MX records carry no port number, relay always happens on 25. There is no alternative for it and never has been.

RFC 6409 defines the other transaction, message submission, where a person's software hands a new message to their own provider to be sent. Its opening states the split plainly: message relay is unaffected and continues to use SMTP over port 25, while message submission uses the protocol specified there, normally over port 587. Section 3.1 is more direct still. Port 587 is reserved for email message submission, and messages received on that port are defined to be submissions.

RFC 5068, the operational companion, turns that into requirements an operator has to meet. Submission agents must listen on port 587 by default, must require authentication on port 587, and must never permit relaying of unauthenticated messages to other domains.

Reading it that way makes one thing obvious. The port question belongs to the first step only. It describes how your message gets into the mail system, not how it travels through it and not how it is judged at the other end.

Port 465 has a history, and the history is the confusion

The reason 465 and 587 both exist for the same job is not a design decision. It is an accident that got standardised twenty years later.

RFC 8314 section 7.3 records it. Port 465 was briefly registered as the "smtps" port, and the registration was revoked on the grounds that it made no sense, since MX infrastructure has no way to specify a port and so relay always uses 25. The number was then reassigned to a different service, which is the urd entry still sitting in the registry today. In the meantime, widely deployed mail software had read "smtps" as meaning submission over TLS and had been using 465 for exactly that, by default, whenever a user asked for a secure connection during account setup.

By 2017 that practice was too entrenched to unwind, so IANA assigned an alternate usage of TCP port 465 alongside the existing one, under the service name submissions. RFC 8314 calls it a one-time procedural exception requiring explicit IESG approval, and states that it does not set a precedent.

So both ports are correct. One was designed for the job and one grew into it, and the registry now says so out loud.

STARTTLS on 587, implicit TLS on 465

The mechanical difference between the two is when encryption starts.

On 587 the connection opens in cleartext and the client issues the STARTTLS command defined by RFC 3207 to negotiate TLS before authenticating. On 465 the TLS handshake begins immediately on connection, before any SMTP is spoken, which RFC 8314 calls implicit TLS.

RFC 8314 also settles the security argument that setup guides like to have. It states that there is no significant difference between the security properties of STARTTLS on port 587 and implicit TLS on port 465 if the implementations are correct and if both the client and the server are configured to require successful negotiation of TLS prior to message submission. It recommends that clients and servers implement both for a transition period, which is why every provider offers both.

The conditional in that sentence is the whole risk. STARTTLS starts in the clear, so a client that treats TLS as optional can be talked out of it. Implicit TLS has no cleartext phase to downgrade. If your sending software has a setting that reads like "use TLS if available", that setting is the problem, on either port.

The port that is probably blocked is 25

RFC 5068 describes the practice that shapes real deployments: some providers block all use of port 25 for outbound mail, or redirect it through a local proxy, except for explicitly authorised hosts. The document declines to recommend for or against the practice and instead pushes the constructive path, which is using the official submission port.

Nearly twenty years on, that blocking is close to universal on consumer connections and common on cloud instances, where outbound 25 typically has to be requested and justified. It is the single most likely explanation for a connection that hangs on 25 and works instantly on 587, and it is also why port 2525 exists as a folk remedy: a customer whose network blocks 25 and, less often, 587, needs some number that is not on anybody's block list.

None of this is a deliverability signal. A blocked port produces a connection failure, which is loud, immediate and nothing like a message that is accepted and filed as junk.

What a receiver says about a message that did arrive is a different reading, and what each reply code class instructs separates a list problem from a sending problem.

What a provider actually publishes

Google's Workspace administrator documentation is a clean worked example. It offers three ways to connect a device or application, and the ports separate them.

The SMTP relay service at smtp-relay.gmail.com lists configuration options of port 25, 465 or 587. The Gmail SMTP server at smtp.gmail.com lists the same three, and the setup steps are specific about which is which: for SSL enter 465, for TLS enter 587. The restricted server at aspmx.l.google.com lists port 25 only, states that TLS and authentication are not required, sends to Gmail and Google Workspace users only, and asks you to verify the IP address of the sending device or app instead.

That third option is the one that shows what the ports mean. It is unauthenticated, so it can only be port 25, and the price of skipping authentication is that Google has to identify you some other way. Note also the dated policy change on the same page: from 1 May 2025, Google Workspace accounts no longer support sign-in from apps or devices using a username and password alone. Provider port lists survive for years; provider authentication policies do not, so re-read the page rather than a summary of it. The per-provider settings themselves are covered in Gmail SMTP settings and Office 365 SMTP settings.

The port is not a deliverability lever

Sender-side advice sometimes reaches for the port as though it were a tuning knob. It is not one, and the reason is structural rather than a matter of opinion. The receiving system that decides whether your message reaches an inbox never sees your submission port. It sees a relay connection on 25 from your provider, carrying authentication results, a sending domain and a reputation history attached to that domain.

We run client campaigns through a sending platform on dedicated mailboxes, on domains kept separate from the client's primary domain, and the port has never been a variable in that setup, because the platform holds the connection. The things that do move placement are covered in the cold email deliverability guide, the ceilings that bind before any of them are in email sending limits by provider, and the question of what kind of server you need at all is SMTP server. If a relay sits in the path, SMTP relay is the shape of that hop. You can also see what a campaign would look like for your market.

The short version

Relay is port 25 and has no alternative, because MX records cannot carry a port. Submission is port 587 by design and port 465 by history, both registered, both correct, and equally secure when TLS is required rather than merely available. Port 2525 is registered to something else entirely and survives as a workaround for blocked networks. Outbound 25 being blocked is the ordinary explanation for a connection that will not open, and none of these numbers has any bearing on whether the message lands in an inbox.

Choosing the right submission port only handles the outgoing half of an account, and how IMAP fits alongside SMTP covers the separate protocol, host and port needed to read mail back.

Port assignments are taken from the IANA Service Name and Transport Protocol Port Number Registry, and provider configuration from the provider's own documentation. Verify current terms with the provider before relying on them.

Sources: IANA Service Name and Transport Protocol Port Number Registry, RFC 5321, Simple Mail Transfer Protocol, RFC 6409, Message Submission for Mail, RFC 5068, Email Submission Operations, RFC 8314, Cleartext Considered Obsolete, RFC 3207, SMTP Service Extension for Secure SMTP over TLS, Send email from a printer, scanner, or app, Google Workspace Admin Help