SMTP ports 25, 587, 465 and 2525: which one should you use?

Pick the wrong SMTP port and nothing happens: the connection hangs, the scanner shows a vague error, or the app says "authentication failed" when the password is right. The fix is usually simple once you know what each port is for. This guide gives the short answer, the standards behind it, and a troubleshooting checklist.

Which SMTP port should you use?

Start with what is doing the sending. A mail server delivering to another domain uses port 25. Anything that logs in to a provider to send (a mail app, a website plugin, a scanner, a CRM) should use port 587 or 465.

If you only remember one thing: 587 or 465 with a username and password (or OAuth) for anything that isn't a mail server. Check which of the two your provider documents, because not every provider supports both.

If you need a refresher on how the SMTP conversation itself works, read what is SMTP first.

What is port 25 for?

Port 25 is the original SMTP port, and it's still the only port used between mail servers. RFC 5321 says a server should keep a listener on "the SMTP port (specified by IANA as port 25) at all times".

There's no alternative for inbound mail. When a server looks up your MX record, it gets a host name and a priority, never a port. As RFC 8314 puts it, "the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used." Your mail server, or the filtering service in front of it, must accept connections on 25.

Encryption on port 25 is negotiated with STARTTLS and is usually opportunistic: if either side can't do TLS, many servers fall back to plain text. STARTTLS and email encryption in transit explains the risk, and MTA-STS is how a receiving domain makes TLS mandatory.

What is port 587 for?

Port 587 is the submission port. RFC 6409 reserves it "for email message submission", meaning a user's client handing a new message to its own provider. Two rules set it apart from port 25:

• Authentication is required. RFC 6409 says the submission server must, by default, return an error to MAIL FROM if the session hasn't authenticated, using reply code 530. That's the 530 5.7.0 error you see when a client forgets to log in.
• TLS is negotiated with STARTTLS. The client connects in plain text, sees STARTTLS in the server's EHLO reply, upgrades the connection, then authenticates.

Microsoft 365 uses this port for authenticated client submission. Microsoft Learn lists smtp.office365.com, "587 (recommended) or 25", with TLS 1.2 or 1.3 required.

What is port 465 for?

Port 465 is submission with implicit TLS: the TLS handshake starts as soon as the TCP connection opens, before any SMTP is spoken. It has an odd history. RFC 8314 explains that 465 was "briefly registered as the 'smtps' port", then revoked, but "some widely deployed mail software" kept using it for secure submission anyway. In 2018, RFC 8314 made it official again under the name "submissions".

RFC 8314 also changed the recommendation. It says connections to submission servers should "be made using 'Implicit TLS' ... in preference to connecting to the 'cleartext' port and negotiating TLS using the STARTTLS command". For a transition period, it says clients and servers "SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465."

It adds an important point: there is "no significant difference between the security properties of STARTTLS on port 587 and Implicit TLS on port 465" if both sides are correct and require TLS before sending. The practical advantage of 465 is that there's no plain-text phase for an attacker to tamper with, and no way for a misconfigured client to carry on without encryption.

Provider support varies

Don't assume 465 works everywhere:

Sources: Microsoft Learn and Google Workspace Admin Help. If you're setting up a scanner or app on Microsoft 365, our scan to email guide compares the three options, and SMTP AUTH and Basic auth retirement covers what changes for password-based sending.

What about port 2525?

Port 2525 isn't an email port in any standard. The IANA port registry lists TCP 2525 for an unrelated service called "MS V-Worlds". Some email sending services accept SMTP on 2525 as an alternative for networks that block 25, 587 or 465.

Treat it as a provider-specific workaround:

• Use it only if your sending service documents it.
• Require TLS and authentication, exactly as you would on 587.
• Expect it to be blocked on some corporate networks, since firewalls often allow only the standard ports outbound.

Why do ISPs and cloud providers block port 25?

Malware on home computers and abused rented servers can send spam straight to receiving mail servers on port 25, bypassing any provider that would notice. Blocking outbound 25 from networks that shouldn't run mail servers closes that path, while legitimate users keep sending through authenticated submission on 587 or 465. Microsoft notes that "some network firewalls or ISPs block port 25 because that port is used by email servers to send messages."

The anti-abuse group M3AAWG still recommends it: "Blocking port 25 for all but a few restricted purposes is still considered an industry best practice." Its advice to providers is to "Provide email submission services on ports 465 and 587" and to require authentication for submission.

The large cloud platforms follow similar rules:

• Microsoft Azure. Microsoft Learn says "The Azure platform blocks outbound SMTP connections on TCP port 25 for deployed VMs" on most subscription types. Standard Enterprise Agreement and MCA-E subscriptions aren't blocked; Enterprise Dev/Test subscriptions are blocked by default but can request an exemption. Microsoft recommends an authenticated SMTP relay on port 587, which "isn't restricted in Azure, regardless of the subscription type."
• Google Cloud. Google's documentation says connections to destination TCP port 25 outside your VPC network "are blocked", though some projects are exempt, and that it does not restrict ports 587 or 465.
• Amazon EC2. AWS says that by default, port 25 traffic "is blocked to public IPv4 addresses and IPv6 addresses", and you can request that the restriction be removed.

Many home and business ISPs block outbound 25 too. If you run a mail server on a network like this, hand outgoing mail to an authenticated relay or smart host on 587 or 465 instead of delivering directly.

How do you troubleshoot SMTP port problems?

Work through these in order. Most problems are found in the first three steps.

1. Confirm the host and port pair. Check your provider's documentation for the exact host name, port and encryption mode. A wrong host name (such as an MX host where a submission host is expected) causes confusing errors.
2. Match the encryption mode to the port. Port 465 needs implicit TLS, often labeled "SSL" or "SSL/TLS" in settings. Port 587 needs STARTTLS, often labeled "TLS" or "STARTTLS". A mismatch usually shows up as a hang or a garbled handshake error rather than a clear message.
3. Test whether the port is reachable. On Windows, run Test-NetConnection smtp.example.com -Port 587 in PowerShell. On macOS or Linux, run openssl s_client -starttls smtp -connect smtp.example.com:587 for STARTTLS or openssl s_client -connect smtp.example.com:465 for implicit TLS. A timeout points to a firewall, ISP or cloud block, not to your credentials.
4. Read the reply code. 530 5.7.0 means the server wants you to authenticate or start TLS first. 535 5.7.8 means the username, password or authentication method was rejected. Look up anything else in the SMTP error code lookup.
5. Check the TLS version. Old printers and scanners sometimes support only TLS 1.0 or 1.1. Microsoft 365 requires TLS 1.2 or later for client submission, so a firmware update or a local relay may be the only fix.
6. Check provider-side settings. In Microsoft 365, SMTP AUTH must be enabled for the mailbox; Microsoft says it's disabled for organizations created after January 2020 but can be enabled per mailbox.
7. Send a test and read the headers. Once mail goes out, send to an outside mailbox and check SPF, DKIM and DMARC in the deliverability test. A message that sends but lands in spam is an authentication problem, not a port problem.

Next steps

• Set every app, scanner and website plugin to 587 or 465 with authentication, and note which mode each uses.
• If anything still sends directly on port 25 from an office or cloud server, move it to an authenticated relay.
• Check that your inbound side accepts mail on port 25 and offers STARTTLS: the Email Health Check reviews your MX, SPF and DMARC records in one pass.
• For low-volume senders such as a self-hosted server, scanner or contact form, iBlockSpam's outbound relay is a smart host with DKIM signing and outbound filtering, with 500 messages per domain per month included.