SMTP port numbers, and why the port is the least of an agent’s problems

The four numbers, from the registry

The STARTTLS port is 587. The SMTPS port, with implicit TLS from the first byte, is 465. An AI agent can pick either in a second. What it cannot do is the account, consent and reputation work around the port, and that is where an unattended sender fails. RFC 8314 prefers 465, and Microsoft 365 expects 587. Port 25 is relay between servers, so do not submit on it. Port 2525 is an unofficial fallback. Here is what the registry records for each one.

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 was revoked, reassigned, then documented again. 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.

RFC 8314 now prefers port 465 over 587

The advice at the top of most SMTP ports pages 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”, meaning your mail app and the provider’s submission server. Implicit TLS for submission is port 465.

The same RFC keeps 587 in play. It 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”.

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.

What an agent does differently with SMTP ports

An agent asked to fix a mail setup will answer 587 or 465 instantly, and it will usually be right. The port is the one part of SMTP an agent never needs help with. What changes is how it behaves around the port. It runs unattended, so nobody is there to click a consent screen. It retries on its own when a connection drops. It wires whatever credential it finds straight into code. And when a connection fails it tends to treat the failure as a wrong number and try the next one.

Four things around the port have moved, and every one of them is where sends actually fail now. An agent hits each of them harder than a person does. Each one has its own page below.

• 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 the Nitrosend 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. Gmail will not let an agent hold an address, but a domain the user owns, connected to Nitrosend, will. Without that, the agent 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.

Why the SMTP port number is not the decision

Models commonly answer 587 with STARTTLS, because that sentence is repeated near-identically across the web. It is also, as the section above shows, the formulation the standard stopped preferring in 2018, 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 reach the server before the connection dropped. None of that can be memorized in advance by anyone, human or otherwise.

Nitrosend is built as the email layer for agents, and that is the part it takes on: its agents can add a sending domain and run the DNS checks, which is the state a port number cannot carry.

Why there is no Nitrosend SMTP host

There is no Nitrosend SMTP host to put in place of Gmail’s. 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, Nitrosend does 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. The transactional email guide covers both. 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 5,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 stay correct. Use them for what they are for: a device, or a script a person configured and will notice going quiet.

The same answer holds when the thing asking is an agent. Instead of a host and a port, it connects to the Nitrosend MCP server or calls the transactional email API, and the next section shows what that switch looks like on a real request.

Worked example: an agent fixing a blocked port 25

The prompt, in the user’s words: “Our app sends mail over SMTP port 25 from a cloud host and it is blocked. Fix it.”

Before, unguided. The agent reads the block as a port problem. It swaps 25 for 2525, then 587, then 465, restarting the app after each change. When one connects, it pastes a Gmail app password into the config file to get past authentication. When a send times out it retries, and the customer gets the receipt twice. Each step looks like progress, and none of it touches the reason the host closed port 25.

After, with the Nitrosend MCP server connected. The agent stops cycling ports and moves the send off SMTP:

1. nitro_get_status gets the account context, sender identity and readiness before anything is sent.
2. nitro_manage_domains adds and verifies the customer sending domain, and diagnoses it if a DNS record is missing.
3. nitro_review_delivery runs a read-only review of the receipt content, with validation, spam analysis and preflight. It never sends.
4. nitro_send_test_message sends one real test of the template. It never sends to an audience. A person checks that test before the real send.
5. nitro_send_message sends the transactional email, with an idempotency_key that is reused only for an exact retry.
6. nitro_get_insights reads the analytics for the send afterwards.

The SMTP settings come out of the app. In their place the app makes an authenticated POST to /v1/my/messages with an Idempotency-Key header, so a retry after a dropped connection returns the original message instead of a second email. The email API page has the request in each language. No port is chosen at all.

Where it goes wrong when an agent picks the port

• Port 25 blocked on a cloud host, fixed with a loop. RFC 5068 records providers blocking outbound port 25 for hosts that are not explicitly authorized. An agent that reads the timeout as the wrong number tries 2525, 587 and 465 in turn, and on a host that closes those too it keeps cycling. The block is a policy, so a different number does not fix it. A submission path the host does not block does.
• Credentials in code. To get past authentication the agent writes the SMTP password or a Gmail app password into a config file, a log or a commit. An app password grants the account, not one email, as the Gmail app password page sets out.
• A retry loop with no idempotency. SMTP has nowhere to say “this is the same message”. An agent that retries every timeout sends duplicates. nitro_send_message takes an idempotency_key, and the agent should reuse it only for an exact retry.
• Sends nobody reviewed. An agent that finally gets a connection working often proves it by sending to real recipients. nitro_review_delivery and nitro_send_test_message put a read-only check and a single test ahead of the first real send.

FAQ

Related reading

• SMTP authentication
• Is SMTP TCP or UDP
• IMAP vs SMTP
• SMTP commands

Go deeper