SMTP Ports 25, 465, and 587 Explained

Port 25 is reserved for server-to-server mail relay and is widely blocked by ISPs and cloud hosts for client or application submission. Ports 465 (implicit TLS) and 587 (STARTTLS) are the correct choices for authenticated message submission from email clients, apps, and transactional systems. Choose 465 or 587 according to your provider’s documentation and firewall rules.

What each SMTP port actually does

SMTP has three commonly used ports with distinct roles defined by RFCs and operational practice.

Port 25 — server-to-server relay

• Original SMTP port.
• Used by mail transfer agents (MTAs) to hand messages between servers.
• Almost never the right port for a desktop client, a mobile app, or your application’s outbound mail.
• Many residential ISPs, VPS providers, and cloud platforms block outbound traffic on port 25 to reduce spam.

If your code or client is trying to connect on 25 and the connection times out or is refused, the port is almost certainly filtered. Switch to a submission port.

Port 587 — message submission with STARTTLS

• Defined for authenticated client submission (RFC 6409).
• Connection starts in clear text, then upgrades to TLS via the STARTTLS command before credentials are sent.
• Still the most widely supported submission port across providers.
• Requires the client or library to support the STARTTLS upgrade sequence.

Port 465 — message submission with implicit TLS

• Originally assigned for SMTPS; later clarified and recommended for implicit TLS submission (RFC 8314).
• TLS is negotiated immediately; there is no clear-text phase.
• Preferred by many modern providers for simplicity and security.
• ArawaMail documents port 465 with SSL/TLS for outbound client connections.

Which port should your app or client use?

Decision rules that work in practice:

1. Prefer the port your provider documents. ArawaMail’s connect-device guide specifies SMTP on port 465 with SSL/TLS.
2. If both 465 and 587 are offered, either is fine provided TLS is enforced and authentication is required.
3. Never use port 25 for application or user submission. It is the wrong role and is frequently blocked.
4. If 587 or 465 is blocked by a corporate firewall, some providers also accept submission on alternate ports (commonly 2525). Check the host’s documentation rather than guessing.

Common firewall and hosting restrictions

Outbound port 25 is the most frequently blocked. Shared hosting, digital-ocean-style droplets, and many corporate networks drop it by default. Port 465 and 587 are far more likely to be open, but some aggressive firewalls still restrict them. When testing:

• Confirm the connection reaches the host (telnet/nc or a library timeout tells you quickly).
• Verify the TLS mode matches the port (implicit on 465, STARTTLS on 587).
• Authenticate with the full email address and the mailbox or API credential the host expects.

How ArawaMail handles outbound SMTP

ArawaMail supports both human mailboxes and application sending. For mailbox clients the documented settings are:

• SMTP host: the provider SMTP hostname for your domain
• Port: 465
• Encryption: SSL/TLS (implicit)
• Username: full email address
• Password: the mailbox password

Application and transactional traffic is normally sent through the HTTP API rather than raw SMTP. The API still enforces the same domain authentication (SPF, DKIM, DMARC) that protects mailbox sending. When you need classic SMTP submission from legacy software, use the 465 settings above once the domain is sending-active.

Related guides: SPF, DKIM, and DMARC explained, Send email in Laravel, and Send transactional email from Next.js.

How we analyzed port roles

The guidance follows the current IETF recommendations (RFC 6409 for submission, RFC 8314 for implicit TLS preference), observed blocking behavior on major cloud and ISP networks, and ArawaMail’s published client configuration. Port 25 remains essential for inter-server relay but is the wrong tool for the jobs most developers and end users need to perform.

FAQ

Is port 465 deprecated?
No. Early confusion around the port assignment was resolved; RFC 8314 explicitly recommends implicit TLS on 465 for submission.

Can I use port 25 if my host allows it?
Technically yes for relay, but authenticated submission on 25 is non-standard and often refused by receiving servers that expect proper submission ports.

What about port 2525?
It is a common alternate submission port offered by some providers when 587/465 are blocked. It is not an official standard; use it only when documented by the host.

Does the port choice affect deliverability?
Indirectly. Using the correct submission port with authentication and TLS is required for modern providers. The reputation impact comes from authentication (SPF/DKIM/DMARC) and content, not from the port number itself.

For most teams the practical answer is simple: configure clients and libraries on port 465 or 587 with TLS and authentication, keep port 25 for the mail servers that actually need to talk to each other, and send application traffic through a documented API whenever possible. That combination keeps both human and product email reliable on the same domain.