SMTP Ports Explained: 25, 465, 587, and 2525

For sending authenticated email from a client or sequencer, use port 587 with STARTTLS, or port 465 with implicit TLS. Use port 2525 only as a fallback when a network blocks 587. Do not use port 25 to submit mail; it is reserved for server-to-server relay and is blocked outbound by most providers.

The rest of this guide explains why these distinctions exist and how the encryption modes differ. For the full sending setup, see the SMTP server setup guide.

Port 25 is the original SMTP port defined in RFC 5321. It handles server-to-server relay: when one mail server hands a message to the next mail server on the path to the recipient. It is the port your inbound mail arrives on, which is why your domain's MX records point receivers at a server listening on 25.

Picture the path of a message you send to a recipient at another company. Your submission server accepts the message from your client, looks up the recipient domain's MX record, opens a connection to that destination server on port 25, and delivers the message. The first hop (client to your server) is submission. The second hop (your server to theirs) is relay over port 25. The two hops use different ports on purpose, because they have different trust models.

What port 25 is not for is client submission. Because spammers historically abused open relays on port 25 to blast mail directly, the industry moved authenticated client submission to dedicated ports. An open relay on 25 will forward mail for anyone, which is exactly the behavior a spammer wants and exactly the behavior blocklists punish on sight.

Encryption on port 25 is opportunistic: servers may negotiate STARTTLS if both support it, but will fall back to plaintext if not. That is acceptable for relay between cooperating servers, since the alternative is no delivery at all, but it is unsuitable for sending credentials. You never want to risk transmitting a username and password over a channel that might silently drop to plaintext.

Key point: if your sequencer or app asks for port 25 to send authenticated mail, something is misconfigured. Use 587 or 465 instead. The one time you legitimately care about port 25 is when you run your own receiving server, because that is the port inbound mail will arrive on, and it must be reachable from the public internet for delivery to work.

Most residential ISPs and cloud platforms block outbound port 25 by default. The reason is spam control. A compromised home computer or a cheap VPS could otherwise send mail directly to any recipient server, bypassing authenticated submission entirely. A single infected machine on a fast connection can attempt millions of direct deliveries before anyone notices, so the cheapest defense is to refuse outbound 25 from networks that have no reason to run a mail server.

Providers that block or restrict outbound port 25 include major cloud platforms (AWS, Google Cloud, and Azure throttle or block it by default) and nearly all consumer ISPs. Getting it unblocked usually requires a support request and proof of legitimate use, and is often denied. AWS, for example, asks you to fill out a request form and assign a reverse DNS record before it will consider lifting the throttle, and even then approval is not guaranteed for new accounts.

This is the single most common reason a self-hosted mail server cannot send: the host blocks outbound 25. People spend hours checking their configuration when the real problem is a firewall they do not control. A fast test is to try opening a connection to a known mail server on port 25 from the host in question; if the connection never completes while 587 to the same provider works, the network is the culprit. The practical consequences for self-hosting are covered in self-hosted email server. For client submission you sidestep the issue entirely by using 587 or 465, which are not subject to the same blocks because they carry authenticated traffic that the provider can hold accountable.

Port 587 is the designated message submission port, defined in RFC 6409. It is the port a mail client uses to hand an outgoing message to its own server with authentication. The RFC drew a deliberate line between submission and relay so that a server can apply stricter rules to mail it originates: require a login, enforce sender rules, add tracking headers, and rate-limit per account.

Port 587 uses STARTTLS. The connection opens in plaintext, the client issues the STARTTLS command, and the session upgrades to an encrypted TLS channel before any credentials or message content are sent. Submission on 587 requires authentication, which is exactly what you want for cold email sending. A correctly configured server will refuse the AUTH command until STARTTLS has completed, so credentials never cross the wire in the clear.

A simplified 587 session looks like this in order: the server greets with 220, the client sends EHLO and sees STARTTLS listed in the capabilities, the client issues STARTTLS, the TLS handshake runs, the client re-sends EHLO over the now-encrypted channel, authenticates with AUTH LOGIN, and only then sends MAIL FROM, RCPT TO, and DATA. If any step is skipped, the server rejects the message.

This is the default you should reach for. Google Workspace (smtp.gmail.com), Microsoft 365 (smtp.office365.com), and almost every transactional relay support 587. If you connect a sequencer over SMTP, 587 with STARTTLS is the standard configuration. See Microsoft 365 SMTP settings for the exact provider values.

Port 465 has a complicated history. It was originally registered for SMTPS, then deprecated, then formally re-registered for submission with implicit TLS in RFC 8314.

The difference from 587 is timing. On port 465 the TLS handshake happens immediately on connection; there is no plaintext phase and no STARTTLS upgrade. The whole session is encrypted from the first byte.

RFC 8314 actually recommends implicit TLS (port 465) over STARTTLS for new deployments, because there is no plaintext window at all. In practice both 465 and 587 are secure when configured correctly. Use whichever your provider documents. Mixing them up, for example pointing a client at 465 but telling it to use STARTTLS, produces a TLS handshake error.

Port 2525 is not an official IANA-assigned SMTP port and is not part of any RFC. It exists because some networks block the standard submission ports, and several relay providers chose to also listen on 2525 as a workaround.

When you might use it:

• Your office or hosting network blocks 587 and 465.
• Your relay provider explicitly documents 2525 as an alternate port.

It typically supports STARTTLS, the same as 587, but behavior is provider-defined since there is no standard. Treat 2525 as a last resort, not a default. If neither 587 nor 465 works, check whether your network is blocking outbound ports before reaching for 2525.

These terms get used loosely, which causes configuration mistakes. Here is the accurate picture:

When a client UI says "SSL" it almost always means implicit TLS (port 465), and "TLS" or "STARTTLS" means the upgrade flow (port 587). The actual encryption is TLS in both cases; true SSL is obsolete and should never be used. The rule that prevents errors: match the encryption mode to the port. Implicit TLS goes with 465, STARTTLS goes with 587.

When a send fails, the port and encryption settings are the first thing to check, because they produce distinct, recognizable symptoms. Work through them in order rather than changing settings at random.

A practical test sequence: first try 587 with STARTTLS. If it times out rather than returning an auth error, the port is blocked at the network level, so try 465. If 465 connects but 587 does not, you have confirmed selective blocking. If both time out, the network blocks all outbound submission and you need a different network or a relay reachable on 2525. If a port connects but then throws a TLS error, the encryption mode is mismatched, not the port itself. Separating connection failures from encryption failures from authentication failures is the whole skill here, and the common SMTP errors and fixes guide expands each branch.

For cold outreach, the port choice is straightforward, but it is only one piece of inbox placement. Encryption protects the connection; it does nothing for reputation. Authentication records and warmup do the heavy lifting.

Recommended setup:

1. 1Use 587 with STARTTLS as your primary submission port.
2. 2Fall back to 465 with implicit TLS if your tool prefers it.
3. 3Use 2525 only if both are network-blocked.
4. 4Never use 25 for sending.

Then make sure the rest is in place: publish SPF, DKIM, and DMARC, and ramp volume with the cold email warmup guide. If sends fail on a given port, the common SMTP errors and fixes guide maps the symptoms to causes.

Managed providers remove port and credential guesswork entirely. InboxKit provisions real Google Workspace and Microsoft 365 mailboxes that connect to 24-plus sequencers natively, so you never hand-configure ports or worry about a blocked 25.