SMTP Ports Explained: 25, 465, 587, and 2525
Why Port Choice Matters
Picking the wrong SMTP port doesn't just cause a connection error—it can mean your mail is sent unencrypted, silently dropped by your ISP, or refused entirely by the receiving server. Each of the four ports in common use has a specific purpose, a specific encryption model, and a specific context where it belongs. Understanding the differences takes five minutes and saves hours of debugging.
Port 25: Server-to-Server Delivery
Port 25 is the original SMTP port, defined in RFC 821 back in 1982. It's still the port used for MTA-to-MTA delivery—when one mail server hands off a message to another. Every publicly accessible mail server that accepts inbound email listens on port 25.
What port 25 is not for: sending mail from an application or email client. Virtually every residential ISP and cloud hosting provider (AWS, GCP, Azure, DigitalOcean) blocks outbound port 25 by default to prevent their infrastructure from being used for spam. Trying to send application mail over port 25 on one of these networks results in a silent firewall drop, not a connection error—which makes it a frustrating problem to debug.
If you're running your own mail server and need to accept inbound email, port 25 must be open on the receiving side. But for your application submitting mail to a relay, use 587 or 465.
Port 587: The Submission Port (Recommended Default)
Port 587 is defined in RFC 6409 as the message submission port. It's the right choice for applications, email clients, and services that need to submit mail to a relay or SMTP server. Unlike port 25, it requires authentication—clients must present credentials before the server accepts any messages.
Encryption on port 587 uses STARTTLS: the connection starts unencrypted on port 587, then upgrades to TLS via the STARTTLS command before any authentication or message data is exchanged. A properly configured client always upgrades to TLS; a misconfigured one might fall back to plaintext. Make sure your SMTP client has STARTTLS set to "required" (not optional).
Port 587 is unblocked by most ISPs and cloud providers, which is why it's the standard recommendation for SMTP submission. If you're configuring an application to send through MailDog's relay, port 587 with STARTTLS is the primary option.
Port 465: Implicit TLS (SMTPS)
Port 465 has a complicated history. It was briefly assigned for SMTPS (SMTP over implicit SSL) in the 1990s, then deprecated in favor of STARTTLS on 587, then officially reassigned in RFC 8314 (2018) as the port for implicit TLS submission.
The practical difference from 587: with port 465, the TLS handshake happens immediately when the connection opens—there's no plaintext negotiation phase at all. The session is encrypted from the first byte. This is architecturally cleaner than STARTTLS because there's no possibility of a STARTTLS stripping attack (where a network adversary removes the STARTTLS advertisement to force a plaintext connection).
Modern email clients and libraries support port 465 with implicit TLS. If your SMTP client supports it, it's a fine choice. If you're working with older tooling that only supports STARTTLS, stick with 587.
Port 2525: The ISP-Blocked Fallback
Port 2525 is not defined in any RFC—it's an unofficial alternative that emerged as a practical workaround. Some ISPs that block port 25 also block port 587, particularly in certain regions or on corporate networks with restrictive outbound firewall policies. Port 2525 avoids those blocks by using a non-standard port that most firewalls leave open by default.
Most managed SMTP relays, including MailDog, offer port 2525 for this reason. It typically runs STARTTLS, same as 587. Don't use it as your primary port—use it only when 587 is blocked in your specific network environment.
Quick Reference Table
- Port 25 — MTA-to-MTA only; blocked by most ISPs for outbound app mail; no auth required
- Port 587 — Application/client submission; STARTTLS; auth required; recommended default
- Port 465 — Application/client submission; implicit TLS; auth required; cleaner than STARTTLS
- Port 2525 — Unofficial fallback; STARTTLS; use when 587 is blocked by your network
Choosing the Right Port for Your Setup
For most applications connecting to a managed SMTP relay:
- Try 587 with STARTTLS required first. It works in the vast majority of environments.
- If your environment or client supports implicit TLS, use 465 instead—it's the more secure option.
- If 587 is blocked (common in some corporate or cloud environments), fall back to 2525.
- Never use 25 for application sending unless you're an MTA delivering to another MTA directly.
What About TLS Versions?
The port determines the connection model; the TLS version is a separate configuration. TLS 1.0 and 1.1 are deprecated—any SMTP server or client you set up should negotiate TLS 1.2 at minimum, with TLS 1.3 preferred where both endpoints support it. If your SMTP library or server config has an option to set the minimum TLS version, set it to 1.2 explicitly rather than relying on defaults.
For a broader look at how SMTP infrastructure fits together—including relay vs. self-hosted options—see the MailDog documentation. If you're debugging connection issues with a specific port configuration, the support team can help diagnose firewall or TLS negotiation problems.
