---
title: "SMTP Port 587 vs 465 vs 25: Developer Guide | SendHQ"
description: Choose the right SMTP port for application email. Compare 587, 465, and 25, configure TLS safely in Nodemailer, and diagnose connection failures.
canonical: https://sendhq.cc/blog/smtp-port-587-vs-465-vs-25
last-updated: 2026-09-23
author: Dhrumil Barot
author_bio: Dhrumil is an email marketing expert. Dhrumil built SendHQ so developers and AI agents can send, receive and track email without fighting deliverability on their own.
published: 2026-09-23
updated: 2026-09-23
---
# SMTP Port 587 vs 465 vs 25: Which Should Your App Use?

By [Dhrumil Barot](https://sendhq.cc/about.md#founder), Founder

Use port 587 with required STARTTLS for most application email, port 465 for implicit TLS, and reserve port 25 for server-to-server relay. Includes Nodemailer configuration and debugging steps.

Published September 23, 2026 · Updated September 23, 2026

Use port 587 with required STARTTLS for most application email submissions. Use port 465 when your provider specifies implicit TLS, where encryption starts as soon as the connection opens. Do not use port 25 for normal application submission: it is primarily for server-to-server mail relay and is often restricted by hosting networks. Whichever submission port you choose, require TLS, validate certificates, authenticate, and follow your provider's documented settings.

## The decision in one table

| Port | Intended role | TLS mode | Use it in an application? |
| --- | --- | --- | --- |
| 587 | Authenticated message submission | STARTTLS upgrades the connection | Yes, usually the least surprising default |
| 465 | Authenticated message submission | Implicit TLS from the first byte | Yes, when the provider documents it |
| 25 | SMTP relay between mail servers | Usually STARTTLS when available | No, unless you operate mail transfer infrastructure |
| 2525 or another alternative | Provider-specific submission | Provider-specific | Only when the provider explicitly supports it |

The key distinction is not "secure port" versus "insecure port." Ports 587 and 465 can both provide properly authenticated TLS. The difference is when TLS begins.

## Why these SMTP ports have different jobs

SMTP originally used port 25 for transferring mail. As email systems matured, standards separated message submission by an application or mail client from message relay between mail servers.

[RFC 6409](https://www.rfc-editor.org/info/rfc6409/) reserves port 587 for message submission and says relay continues to use port 25. That separation lets a submission server require authentication, reject malformed sender data, and apply policy before accepting a message.

[RFC 8314](https://www.rfc-editor.org/info/rfc8314/) later standardized implicit TLS submission on port 465. It recommends supporting both implicit TLS on 465 and STARTTLS on 587 during the transition, and notes that their security properties are not significantly different when both implementations require successful TLS negotiation.

That last condition matters. Opportunistic encryption is not enough for an application submitting credentials and message content. If TLS cannot be established, the send should fail rather than fall back to plaintext.

## Port 587: authenticated submission with STARTTLS

On port 587, the client opens a plain TCP connection, receives the SMTP greeting, sends `EHLO`, and checks whether the server advertises `STARTTLS`. It then requests the TLS upgrade. Authentication and message submission happen only after the encrypted channel is established.

Port 587 is a practical default because it is the standards-defined submission port and is widely documented by providers. But the application must require the upgrade. A library setting that merely uses STARTTLS "when available" can silently continue without encryption if the server or network path does not offer it.

For Node.js, Nodemailer's official [SMTP transport documentation](https://nodemailer.com/smtp) says to use `secure: false` on port 587 and let STARTTLS upgrade the connection. Set `requireTLS: true` so a missing or failed upgrade becomes an error.

Choose 587 when:

- Your provider lists 587 as its submission port.
- Your runtime and SMTP library support STARTTLS correctly.
- Your egress network allows the port.
- You want the most conventional application submission configuration.

## Port 465: submission with implicit TLS

On port 465, the TLS handshake begins immediately after the TCP connection opens. SMTP commands are exchanged only after the encrypted session is ready. There is no separate STARTTLS command.

This is why copying a port number without copying its TLS mode causes confusing failures. If a client connects to 465 as if it were plaintext and waits for an SMTP greeting, both sides wait for different protocols. If a client tries an immediate TLS handshake against a STARTTLS endpoint on 587, the server expects SMTP commands instead.

In Nodemailer, port 465 uses `secure: true`. In generic mail libraries, the same mode may be called implicit TLS, TLS wrapper, SMTPS, or SSL/TLS. "SSL" is often legacy interface wording; the production connection should still negotiate a modern TLS version.

Choose 465 when:

- Your provider explicitly supports implicit TLS on 465.
- Your library has a clear implicit TLS setting.
- Port 587 is unavailable in your deployment network.
- You prefer encryption to begin before any SMTP protocol exchange.

Amazon SES, for example, documents port 587 with STARTTLS and port 465 with implicit TLS in its [official connection test guide](https://docs.aws.amazon.com/ses/latest/dg/send-email-smtp-client-command-line.html).

## Port 25: relay, not your application's default

Port 25 remains essential for mail transfer agents delivering messages to recipient domains. That does not make it the right port for your web application, job worker, or AI agent.

Application traffic on port 25 creates avoidable operational problems. Providers may expect relay behavior rather than authenticated submission, and infrastructure networks may restrict it. AWS states that Amazon EC2 restricts port 25 traffic by default in its [SES SMTP troubleshooting guidance](https://docs.aws.amazon.com/ses/latest/dg/troubleshoot-smtp.html).

Use port 25 only when you deliberately operate SMTP relay infrastructure and understand queueing, DNS, TLS policy, abuse controls, bounce handling, and reputation. Switching an application to port 25 is not a real fix for a blocked 587 or 465 connection.

## A safe Nodemailer configuration

Keep the host, port, and credentials in secrets or deployment configuration. Derive the TLS mode from the documented port, fail closed when STARTTLS is expected, and set bounded timeouts.

```
import nodemailer from "nodemailer";

const port = Number(process.env.SMTP_PORT ?? "587");

if (![465, 587].includes(port)) {
  throw new Error("SMTP_PORT must be 465 or 587");
}

const implicitTls = port === 465;

export const mailer = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port,
  secure: implicitTls,
  requireTLS: !implicitTls,
  auth: {
    user: process.env.SMTP_USERNAME,
    pass: process.env.SMTP_PASSWORD,
  },
  tls: {
    minVersion: "TLSv1.2",
  },
  connectionTimeout: 10_000,
  greetingTimeout: 10_000,
  socketTimeout: 30_000,
});
```

Do not "fix" certificate errors with `rejectUnauthorized: false`. That disables server certificate validation and makes interception harder to detect. Fix the hostname, trust store, certificate chain, or provider configuration instead.

At deployment time, verify connectivity and authentication without sending a message:

`await mailer.verify();`

Nodemailer's `verify()` checks DNS resolution, the TCP connection, TLS negotiation, and authentication. Its documentation also warns that verification does not prove the server will accept a particular sender address. That policy check happens during an actual submission.

## Test the TLS mode without sending email

Use OpenSSL to separate a network or TLS problem from an application-library problem. These commands open a connection but do not submit a message:

```
# Port 587: connect, then negotiate STARTTLS
openssl s_client -starttls smtp -crlf \
  -connect smtp.example.com:587 \
  -servername smtp.example.com

# Port 465: begin TLS immediately
openssl s_client -crlf \
  -connect smtp.example.com:465 \
  -servername smtp.example.com
```

Check the certificate verification result, negotiated TLS version, certificate hostname, and SMTP greeting. Do not paste credentials into shell history while testing. AWS publishes equivalent commands for its regional SES endpoints in the connection guide linked above.

Interpret common failures by layer:

- `ECONNREFUSED`: the host is reachable, but nothing accepts connections on that port, or a firewall rejected it.
- Timeout: DNS, routing, firewall, provider egress policy, or a blocked port may be responsible.
- Wrong version number or unexpected greeting: the port and TLS mode probably do not match.
- Certificate hostname mismatch: use the provider's documented SMTP hostname, not an IP address or dashboard URL.
- Authentication rejected: confirm that you are using SMTP credentials, not an unrelated API key, and that the account is allowed to submit.
- Sender rejected: verify the sending domain or address and check provider policy. A successful connection test does not validate the envelope sender.

Log the failure class, SMTP response code, provider request or message ID, and retry decision. Never log passwords, authorization data, or full message bodies.

## Sending safely in production

Choosing the right port solves transport setup. It does not solve duplicate sends, consent, authentication, or inbox placement.

Treat email as an external side effect. Persist an idempotency key before submission, record the provider response, and distinguish a definitive rejection from an unknown outcome caused by a timeout. If the connection drops after the server may have accepted the message, blindly retrying can send a duplicate. Reconcile by your idempotency key or provider event history first.

For an AI agent, use explicit states such as `draft`, `approved`, `sending`, and `sent`. Require human approval for new recipients, bulk changes, sensitive content, or unusually high volume. Give the agent a narrowly scoped credential and a recipient or domain allowlist. The port number is not a permission boundary.

Send only expected transactional email and consented marketing or subscription email. Google currently requires TLS for mail sent to personal Gmail accounts and imposes additional authentication and unsubscribe requirements in its [email sender guidelines](https://support.google.com/mail/answer/81126). Those requirements are a baseline, not a promise of inbox placement.

Keep three outcomes separate:

1. **Accepted:** your submission server returned a success response and took responsibility for processing.
2. **Delivered:** a recipient mail server later accepted the message.
3. **Inbox placement:** the receiving system placed it in an inbox rather than spam or another category.

Correct TLS and a `250` response establish neither delivery nor inbox placement. Track delivery events, bounces, complaints, and suppressions after submission.

## Production checklist

- Use 587 plus required STARTTLS, or 465 plus implicit TLS, exactly as your provider documents.
- Keep certificate validation enabled and require TLS before authentication.
- Store SMTP credentials in a secret manager and rotate them without code changes.
- Run a non-sending connection verification during deployment or a controlled health check.
- Set connection, greeting, and socket timeouts.
- Retry transient failures with backoff, but reconcile unknown outcomes before retrying a send.
- Use idempotency keys at the application boundary.
- Verify your sending domain and configure SPF, DKIM, and DMARC.
- Send only to expected or consenting recipients and honor suppression and unsubscribe state.
- Monitor acceptance, delivery, bounces, complaints, and latency as different signals.

## FAQ

### Is port 465 obsolete?

No. RFC 8314 standardized port 465 for SMTP submission with implicit TLS. It is valid when your provider supports it and your client begins TLS immediately.

### Is port 587 encrypted?

Not from the first byte. It normally starts with an SMTP connection and upgrades through STARTTLS. When the client requires a successful upgrade before authentication or submission, the resulting session is encrypted.

### Should I use port 2525 if 587 fails?

Only if your provider documents 2525 or another alternative and specifies its TLS mode. It is a provider convention, not a universal standards-based substitute. First identify whether the original failure is DNS, egress policy, TLS mode, authentication, or provider configuration.

### Does the SMTP port affect deliverability?

Not directly. The submission port controls how your application connects to its provider. Recipient systems evaluate message authentication, sender reputation, content, recipient engagement, complaint signals, and their own policies. A correct port is necessary plumbing, not an inbox guarantee.

If you would rather use an API and webhooks than manage SMTP connection modes, credentials, and provider events yourself, [build the workflow with SendHQ](https://sendhq.cc/index.md). You still own consent, message intent, and retry policy; SendHQ gives your application one observable email interface.

## Keep reading

- [How to Send Transactional Email in Node.js with an Email API](https://sendhq.cc/blog/send-transactional-email-nodejs-api): Build a production-safe Node.js email flow with fetch, stable idempotency keys, explicit error handling, durable retries, and honest deliver Read article →
- [AWS SES Endpoints: How to Choose the Right Region and URL](https://sendhq.cc/blog/aws-ses-endpoints-region-url): Choose the right Amazon SES API, SMTP, or inbound endpoint, configure regional resources safely, and migrate regions without losing identity Read article →
- [Amazon SES Pricing Tiers Explained (July 2026)](https://sendhq.cc/blog/amazon-ses-pricing-tiers-2026): Amazon SES shifted from a simple a la carte model to tiered plans (Essentials, Pro, Enterprise) on July 21, 2026. Here is the cost breakdown Read article →