SMTP port numbers, and why the port was never the hard part

The four numbers, from the registry

If the number is all you came for: submit on 587 with STARTTLS, or on 465 with TLS from the first byte. Both are standards track and both are fine. Do not submit on 25. Here is what the registry actually records for each one, because most pages on this topic, including the one that used to be here, paraphrase each other rather than the source.

Two of those rows are worth a second look, and neither is the one people argue about.

Port 2525 has no mail registration at all. IANA records 2525/tcp as ms-v-worlds, which has nothing to do with email. It works as a fallback on the providers that offer it because it is a port almost nobody has a reason to close, and that is the entire property. There is no specification behind it, no requirement that anyone listen there, and no behavior you can rely on beyond whatever your provider documents.

Port 465 carries two registrations. It holds urd, and since December 2017 it also holds submissions. RFC 8314 calls that assignment “a one-time procedural exception to the rules” and explains the mess behind it: “Historically, port 465 was briefly registered as the ‘smtps’ port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a different service.” Every page that says 465 was deprecated and then brought back is compressing that. It was revoked, reassigned, used anyway by most of the world’s mail software, and finally documented a second time because the alternative was worse.

Port 25 is for relay between servers, and the reason your application cannot use it is written down. RFC 5068, a Best Current Practice published in November 2007, set out to “promote transition of initial message submission from port 25 to port 587” and recorded what providers were already doing: “A proactive technique used by some providers is to block all use of port 25 SMTP for mail that is being sent outbound, or to automatically redirect this traffic through a local SMTP proxy, except for hosts that are explicitly authorized.” The same document sets the counterpart requirement in capitals: “Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.” Microsoft puts it more plainly on its own setup page: “Some network firewalls or ISPs block port 25 because that port is used by email servers to send messages.”

RFC 6409 is the one-line answer for 587: “Port 587 is reserved for email message submission as specified in this document.” If you want the long version of any of this, SMTP port number takes each port on its own, and SMTP TLS covers pairing the encryption mode to the port.

The one thing here that did move, and almost nobody noticed

Here is the part that makes this page worth writing. The advice at the top of every SMTP ports page on the internet, including the one that used to be at this URL, is some version of “use 587 with STARTTLS”. The IETF stopped putting it that way in January 2018.

RFC 8314 is standards track and it is not subtle. Connections to submission servers should “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”. Section 3 says it again: “this specification now recommends the use of Implicit TLS for POP, IMAP, SMTP Submission, and all other protocols used between an MUA and an MSP”. Implicit TLS for submission is port 465.

Now the honest half, because a page that stopped there would be wrong in the other direction. The same RFC tells clients and servers to “implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period”, and states flatly 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”. Nothing on 587 is broken. The preference is architectural rather than cryptographic: STARTTLS produced a command injection flaw that multiple implementers hit independently, which the RFC says “suggests that it is a less secure architecture than Implicit TLS”.

And then the thing that makes the whole question useless as advice. Microsoft’s own setup page for client SMTP submission says close to the opposite: “If your device or application recommends or defaults to TCP port 465, it doesn’t support the required versions of TLS for client SMTP submission in Microsoft 365 or Office 365” (Microsoft Learn, How to set up a multifunction device or application to send email using Microsoft 365 or Office 365, read September 24, 2026). The standards body prefers 465. Microsoft reads a default of 465 as evidence that your software is too old to talk to it. Both are right about their own system, and the port number does not tell you which system you are pointed at.

So the number was never the answer. What you actually needed to know was which server you are submitting to and what it will accept today, and that is not a constant. The Office 365 page has Microsoft’s values and the dates it has published, and the Gmail page has Google’s.

The port was never the hard part

I wrote a line about the last interface I built a company on, and it transfers here almost without editing: “The dashboard was never the product. It was the bottleneck.” The ports are the same shape. They are the part of an SMTP setup that holds still, which is why nearly every page about SMTP is really a page about ports, and why those pages are interchangeable.

Four things around the port have moved, and every one of them is where sends actually fail now. Each is a page below, so treat this as the routing table.

Who is allowed to authenticate. Microsoft: “SMTP AUTH is disabled for organizations created after January 2020 but you can enable it per-mailbox” (Microsoft Learn). That is a tenant-level decision, not a setting in your application, so the fix for a correct password that still fails is often a person with admin rights rather than a change to your config. Start at Office 365 SMTP settings, then SMTP authentication for what the server is actually asking for.

What the credential grants. Google defines an app password as “a 16-digit passcode that gives a less secure app or device permission to access your Google Account”, and opens the same page with “App passwords aren’t recommended and are unnecessary in most cases” (Google Account Help, Sign in with app passwords, read September 24, 2026). You asked for permission to send one email. What the credential grants is the account. The Gmail app password page works through what that means in practice, and SMTP password covers where the credential comes from on other providers.

What a retry does. An SMTP transaction has nowhere to carry “this is the same message I sent you a minute ago”. A connection that drops after the server has accepted the message, and a client that retries because retrying is correct behavior, produce two emails. That used to be rare because the client was a person who could check a Sent folder. The Gmail SMTP page quotes what RFC 5321 has to say about it, which is less than you would hope, and sets it beside the Idempotency-Key header our send endpoint takes instead.

Whether a human is present. Google’s recommended path, and Microsoft’s, is OAuth, and OAuth is a browser, a consent screen and a person clicking. The fallback for devices without a browser still shows a code for somebody to type somewhere else. A sender running unattended cannot produce either, so it ends up holding the credential the provider opens its own documentation by recommending against, on a path that provider files under printers and scanners. Gmail SMTP settings walks the three moments in that path that quietly need a person. That is the real state of SMTP in 2026, and no port number expresses any of it.

Why a constant is the wrong thing to be famous for

Ask any model which SMTP port to use and it will answer 587 with STARTTLS, instantly and with total confidence, because that sentence is repeated near-identically across the web. It is also, as the section above shows, the formulation the standard stopped preferring eight years ago, because the sentence was copied far more often than the RFC was read.

That is the failure mode of a topic made of constants. The constant is easy, so everybody writes it, so all the writing agrees, and the agreement gets mistaken for authority. Meanwhile the part that decides whether your send works is state. Does this tenant permit SMTP AUTH today. Did this app password survive somebody’s routine password change last week. Did the first attempt commit before the socket closed. None of that can be memorized in advance by anyone, human or otherwise.

I made a related point about tooling once and it is the same shape: “Claude doesn’t need MCP to call an API. Claude needs MCP to know what API to call.” The model is not short of facts. It is short of a way to find out what is true right now, and the port numbers are precisely the part it never needed help with.

I will say the uncomfortable half too, because we sell AI-native email and it would be cheap to leave it out. Models are confidently wrong about this subject. My own words, posted publicly while building this: “Ask about deliverability and it confidently makes things up.” A page like this one earns its place only by carrying the things that can be checked, against a registry, against an RFC, against a provider’s own documentation, and by marking clearly which sentence rests on which. That is the job now. The four numbers are not.

Why there is no Nitrosend SMTP host

This page ranks for SMTP settings, so the direct answer first. There is no Nitrosend SMTP host. There is no hostname and port to paste into PHPMailer or Nodemailer in place of Gmail’s. The documented submission surfaces are the REST API, the SDK, the MCP server and the CLI, and if a host and port is what you came here for, we do not have one to give you.

That holds even on the path where you keep your own sending infrastructure. You can send through your own Amazon SES, Postmark, Mailgun, Resend or SendGrid account and keep that account’s economics, and every one of those connections is made with an API credential, an access key or a server token. Not a host, a port and a password.

What replaces the settings table is two paths, depending on what is doing the sending. An application firing receipts and password resets makes an authenticated POST to /v1/my/messages with an Idempotency-Key header, and the documented behavior on a retry is exact: the same key with the same payload returns the original message, and the same key with a different payload returns 409 idempotency_conflict. An agent doing campaign and flow work connects itself. Point it at nitrosend.com/SKILL.md and it follows the install skill, with no key to paste and no port to choose. You sign in once, which is the one place a person genuinely belongs. The free plan is 8,000 emails up front and then 500 a month, which is enough to find out whether any of this survives contact with your stack.

The four numbers at the top of this page are correct and will go on being correct, which is the nicest thing anybody can say about them. Use them for what they are for: a device, or a script a person configured and will notice going quiet. They are worth knowing. They are not worth a decision. The decisions are one level up, and they are on the pages below.

FAQ

Go deeper