All articles SMTP & Infrastructure

SMTP Ports Explained: 25, 465, 587, and 2525 and When to Use Each

SSam wallness07 Jul 2026
SMTP Ports Explained: 25, 465, 587, and 2525 and When to Use Each

SMTP Ports Explained: 25, 465, 587, and 2525 and When to Use Each

If you've ever configured an email client, set up a mail server, or troubleshot a sending problem, you've encountered SMTP port numbers. Port 25, 465, 587, 2525 — they appear in documentation, error messages, and hosting control panels, often without much explanation of what each one does or why multiple options exist in the first place.

This guide covers what each SMTP port is for, which one to use, and why using the wrong one causes problems that are easy to misdiagnose.

What SMTP Ports Are and Why They Exist

SMTP (Simple Mail Transfer Protocol) is the protocol email uses to travel from one server to another, or from a client to a server. Ports are numbered channels — different ports handle different types of network traffic. Email servers listen on specific ports for incoming SMTP connections, and clients or other mail servers connect to those ports to deliver messages.

The different SMTP ports aren't interchangeable. Each one has a defined purpose, a history, and a specific role in how email moves.

Port 25: Server-to-Server Only

Port 25 is the original SMTP port, defined in the earliest email standards. It's used for server-to-server mail delivery — when one mail server delivers a message directly to another mail server's inbox.

If you're running a mail server that accepts incoming email from the internet, it listens on port 25. When your server sends email to another organization's server, it connects to their port 25.

You should not use port 25 to send outbound mail from your applications or email client. Most ISPs and cloud hosting providers block outbound port 25 connections from residential and VPS IP addresses to prevent spam abuse. Trying to use it for client-to-server submission won't work in most environments, and attempting it flags your sending behavior immediately.

Port 465: SSL Submission

Port 465 was originally assigned for SMTPS — SMTP over SSL — in the late 1990s. It was technically deprecated when STARTTLS emerged as the preferred encryption method, but it never went away. Many email providers continued supporting it, and RFC 8314 in 2018 formally re-designated port 465 for implicit SSL/TLS email submission.

In practice, port 465 means: connect, immediately negotiate an SSL/TLS session, then proceed with SMTP. There's no plain-text handshake phase before encryption begins.

When to use 465: If your email client or application requires implicit TLS and your provider supports it, port 465 is a valid choice. Some older applications specifically require 465 and won't work with STARTTLS on 587.

Port 587: The Standard for Email Submission

Port 587 is the modern, standard port for email submission — meaning authenticated clients and applications sending outbound email to a relay. It's defined in RFC 2476 and RFC 4409, and it's what email clients, marketing platforms, and application code should use when connecting to an SMTP relay.

Port 587 uses STARTTLS — the connection starts as plain text, then upgrades to encrypted before authentication or message content is exchanged. This is slightly different from 465's approach but equally secure in practice.

When you configure your email client to send mail, use port 587 with STARTTLS. When you configure your application to use an SMTP relay like MailDog's SMTP service, start with port 587.

Port 2525: The Firewall Escape Hatch

Port 2525 isn't an official SMTP standard, but it's widely offered by SMTP relay providers as an alternative to 587. The reason is practical: some corporate firewalls, shared hosting environments, and network configurations block outbound port 587.

Port 2525 offers the same functionality as 587 but on a port that's less frequently blocked by network policies. If 587 isn't working in your environment, 2525 is the first alternative to try — before you start diagnosing more complex issues.

Quick Reference: Which Port to Use

  • Port 25 — Server-to-server delivery only. Not for client or application submission. Frequently blocked on consumer and VPS networks.
  • Port 465 — Implicit SSL/TLS submission. Still widely supported. Use when your client specifically requires implicit TLS.
  • Port 587 — STARTTLS submission. The standard choice for email clients and applications sending through a relay.
  • Port 2525 — Alternative to 587. Use when port 587 is blocked by your network environment.

Why Port Choice Affects Deliverability

Using the wrong port — especially trying to use port 25 for client submission — can cause email to be blocked silently or rejected with a 421 or 550 error. These failures are frustrating because error messages often don't clearly identify port as the cause.

Beyond connection failures, sending on non-standard ports can sometimes trigger rate limiting or filtering at the ISP level. Some receiving servers look at the submission chain in headers, and inconsistencies can raise flags.

If you're seeing connection timeouts or refusals when configuring SMTP, port and firewall rules are among the first things to check. Verify that your network allows outbound connections on whatever port you're using.

Configuring for Common Use Cases

For email clients (Outlook, Apple Mail, Thunderbird): use port 993 for IMAP with SSL and port 587 with STARTTLS for SMTP submission. Most clients default to these if you use the auto-configure option with a properly set up domain.

For application code connecting to an SMTP relay: use port 587 as the default. The MailDog documentation includes code examples for common languages and frameworks with the correct port and TLS configuration.

The MailDog SMTP relay supports ports 465, 587, and 2525, so you can use whatever works in your specific environment. If you're unsure which applies to your setup, the MailDog support team can help identify whether a port issue is causing your delivery problems.

Related articles

Transactional Email Infrastructure Design: Building for Reliability at Scale
SMTP & Infrastructure
Sam wallness

Transactional Email Infrastructure Design: Building for Reliability at Scale

Transactional email has fundamentally different infrastructure requirements from marketing campaigns — it needs to be fast, reliable, and completely isolated from anything that could drag down its deliverability. This guide covers the architecture decisions that matter: queue design, authentication, suppression lists, monitoring, and how to test before you go live.

Read article
SMTP Server Hardening: Locking Down Your Mail Transfer Agent
SMTP & Infrastructure
Sam wallness

SMTP Server Hardening: Locking Down Your Mail Transfer Agent

A misconfigured SMTP server can be exploited as an open relay, used to send spam from your domain, or damage your sending reputation in ways that take weeks to repair. This practical hardening checklist covers open relay prevention, TLS enforcement, rate limiting, authentication requirements, and the ongoing monitoring that keeps your mail server secure long-term.

Read article