SMTP Relay Port: How to Choose Between 25, 465, 587, and 2525

If you are searching for an SMTP relay port, you are probably trying to make an application, website, printer, server, or automation send email reliably. The short answer is: use the port and encryption mode your SMTP provider documents—most often 587 with STARTTLS for authenticated application sending.

The confusion exists because SMTP has two different jobs. A mail server uses SMTP to relay messages to another mail server, while an app or device uses SMTP to submit a message to a trusted provider that will send it onward. Those flows can use the same protocol, but they have different security expectations, default ports, and failure modes. The message-submission standard separates submission from relay: it normally assigns port 587 to submission, while server-to-server relay continues on port 25. (rfc-editor.org)

This guide explains which SMTP relay port to select, what the TLS setting must be, how to configure it correctly, and how to prove that mail is actually leaving your system—not merely that a TCP connection opened.

The quick SMTP relay port decision

Use this table as your starting point. Your email provider’s own setup documentation always wins, because providers can enable different ports and authentication methods.

For an ordinary application connecting to a transactional email provider, configure port 587, enable TLS through STARTTLS, require authentication, and use the provider hostname rather than a hard-coded IP address. SendGrid, for example, supports TLS connections on 25, 2525, and 587 and identifies 587 as the usual recommendation; it reserves port 465 for SSL/TLS connections. (twilio.com)

Do not treat a port number as a security setting by itself. The port and TLS mode are a pair:

• Port 587 + STARTTLS: connect in SMTP, read server capabilities, then upgrade the connection to TLS before authenticating.
• Port 465 + implicit TLS: start the TLS handshake immediately. Do not issue plaintext SMTP commands first.
• Port 25: traditionally server-to-server relay; it may offer STARTTLS, but many cloud networks and ISPs restrict outbound access to it.
• Port 2525: not an IETF standard SMTP submission port; it is a practical alternate listener offered by some providers.

What an SMTP relay port actually does

An SMTP relay is a server that accepts your outgoing message and takes responsibility for attempting delivery to the recipient’s mail system. Your application normally authenticates to that relay using a username and password, an API-key-as-password convention, OAuth, a client certificate, or an approved source IP address.

A port is simply the TCP endpoint on which that relay listens. It does not decide whether a message reaches an inbox. It decides how your software starts its conversation with the relay.

Submission versus relay

These terms are often used loosely, but the distinction matters:

1. Message submission is your application, mail client, scanner, or device handing a newly created message to an authorized service.
2. Message relay is one SMTP server passing a message to another SMTP server on the route toward the recipient.
3. Final delivery is the receiving system placing the message into a mailbox, rejecting it, quarantining it, or routing it elsewhere.

RFC 6409 separates submission from relay specifically so a submission service can apply its own authentication and policy rules. It specifies port 587 as the normal submission port; port 25 remains the relay port. (rfc-editor.org)

For most builders, this leads to a straightforward architecture:

Your app → authenticated SMTP provider → recipient mail server → recipient inbox
             port 587 + STARTTLS

You usually do not need to operate the middle-to-right portion yourself. A managed delivery provider handles queueing, retries, bounce processing, IP reputation operations, and recipient-server compatibility. If you are comparing delivery services, also compare the operational details behind transactional email pricing, not only the headline monthly price.

Port 587: the practical default for an SMTP relay

Port 587 is the normal answer for the query “what SMTP relay port should I use?” It is intended for message submission, not unauthenticated internet-wide relay. The standards guidance is durable: use the submission service for clients and applications, and keep server-to-server transport separate. (rfc-editor.org)

With port 587, the client usually follows this sequence:

1. Open a TCP connection to smtp.provider.example:587.
2. Read the server greeting, commonly a 220 reply.
3. Send EHLO and read the advertised capabilities.
4. Confirm that STARTTLS is offered.
5. Send STARTTLS and complete certificate validation plus the TLS handshake.
6. Send EHLO again inside the encrypted session.
7. Authenticate using a mechanism the provider advertises.
8. Send MAIL FROM, one or more RCPT TO commands, then DATA.

The second EHLO is not a cosmetic detail. SMTP capabilities can change after the TLS upgrade, so well-behaved clients refresh the capability list inside the encrypted session.

When port 587 is the right choice

Choose 587 when all of these are true:

• You are sending from application code, a CMS, an automation platform, or an internal service.
• Your SMTP provider documents STARTTLS support on 587.
• Your client has an explicit setting such as STARTTLS, TLS, Use TLS, or Encryption: STARTTLS.
• You can authenticate with scoped SMTP credentials, OAuth, or a provider-supported mechanism.

A successful connection on port 587 does not mean your app can send as any address it wants. Providers commonly verify sender identities and domains, and many will reject or rewrite unauthorized envelope senders or visible From: addresses.

The most common port 587 mistake

The usual mistake is leaving TLS optional. A client may connect, see STARTTLS, but continue in plaintext if configuration does not require an upgrade. Modern implementations should require encryption for credentialed SMTP submission. RFC 8314 describes cleartext access as obsolete and recommends TLS protection for message submission. (datatracker.ietf.org)

In a library that distinguishes “use TLS if available” from “require TLS,” choose the setting that fails closed when TLS cannot be negotiated. Never solve a certificate or handshake issue by turning off certificate verification in production.

Port 465: implicit TLS, not STARTTLS

Port 465 is for SMTP submission using implicit TLS. The key word is implicit: the TLS handshake begins immediately after TCP connects. Only after that secure channel exists does the client speak SMTP.

RFC 8314 recommends implicit TLS for submission on port 465 and describes it as the registered submissions service. It also recommends TLS for submission generally rather than cleartext access. (datatracker.ietf.org)

This is why these two configurations are different even though both encrypt mail between your app and its relay:

When to use port 465

Use 465 when your provider specifically supports or prefers it, or when a network path interferes with STARTTLS but allows an immediate TLS connection. Some providers expose both 465 and 587; in that case, follow their documentation and make the encryption toggle match the port.

The wrong pairing causes predictable failures:

• STARTTLS configured on 465: the client expects a readable SMTP greeting but the server expects a TLS handshake.
• Implicit TLS configured on 587: the client sends TLS handshake bytes to a server waiting for SMTP commands.
• Plaintext SMTP on 465: the session fails before authentication.

Provider terminology can be inconsistent. One UI may call the setting SSL, another calls it TLS, and another calls it secure connection. What matters is connection behavior: on port 465, TLS starts immediately; on port 587, encryption normally starts through STARTTLS.

Port 25: use it for mail-server relay, not app submission

Port 25 is the original SMTP transport port and remains central to server-to-server email. If you run a mail transfer agent such as Postfix, Exim, Exchange, or another relay that delivers directly to recipient MX servers, it will generally make outbound SMTP connections to port 25 on those destination servers.

That is different from configuring a web app to log into a delivery provider. For application submission, port 25 is often a poor first choice because networks may block, throttle, inspect, or deprioritize it as an anti-abuse measure.

AWS documents a concrete example: by default, EC2 allows outbound port 25 only to private IPv4 addresses, and AWS provides a separate process to request removal of the restriction. (repost.aws)

When port 25 is appropriate

Port 25 can be appropriate when you are:

• Operating an internet-facing mail transfer agent.
• Relaying mail from one mail server to another.
• Sending from a controlled network that permits outbound port 25.
• Prepared to manage reverse DNS, IP reputation, queue retries, recipient-server failures, and abuse controls.

It is not the right port merely because an old plugin, device manual, or code sample labels it “SMTP.” The original port is still valid for mail transfer; it is simply not the best default for authenticated application submission.

Why direct port 25 delivery is operationally expensive

A direct-to-MX server must look credible to recipient systems. That means correct DNS, a stable public IP, forward and reverse DNS consistency, SPF and DKIM alignment, sensible retry behavior, secure TLS behavior, and protection against becoming an open relay.

Google’s sender requirements illustrate the difference between “SMTP connected” and “message is deliverable.” Google requires all senders to use SPF or DKIM, and it requires bulk senders—defined in its guidance as more than 5,000 messages per day to personal Gmail accounts—to use SPF, DKIM, and DMARC. Its guidance also calls for valid forward and reverse DNS records and TLS during transmission. (support.google.com)

Port 2525: a useful fallback, not a universal standard

Port 2525 is commonly offered by SMTP delivery providers as an alternate route when a host, firewall, ISP, VPN, or office network blocks 25 or 587. It is not the standard submission port defined by the message-submission RFC, so do not assume every provider supports it.

For example, SendGrid supports 2525 for unencrypted or TLS connections, alongside 25 and 587, while Postmark documents 25, 2525, and 587 with STARTTLS availability. (twilio.com)

Use 2525 only after answering two questions:

1. Does your selected provider explicitly list it?
2. Does your application support the encryption method the provider requires on that port?

If the answer is yes, port 2525 can be a sensible operational fallback. If the answer is no, do not guess. Changing port numbers until a connection happens to work can result in an unencrypted session or a configuration that fails after a provider-side policy update.

Configure the SMTP relay port correctly

A complete SMTP configuration has more moving parts than host plus port. Gather each of these values before editing code or an application dashboard:

• SMTP hostname: the provider’s documented hostname, such as smtp.example.com.
• Port: normally 587, or 465 when using implicit TLS.
• TLS mode: STARTTLS versus implicit TLS.
• Authentication method: username/password, API key convention, OAuth, or IP allowlisting.
• Username: provider-specific; it may be a mailbox address, an account name, or a fixed literal.
• Secret: a dedicated SMTP password, API key, or access token—not a personal account password unless the provider explicitly requires it.
• Approved sender: a verified domain and sender address.
• Envelope sender / return path: where bounces are directed, when your provider lets you set it.

A worked Node.js example using port 587

The following example uses Nodemailer with a generic provider. Nodemailer’s SMTP transport is designed to send mail via SMTP and supports a configurable SMTP host, port, authentication, and TLS behavior. (nodemailer.com)

Install the package:

npm install nodemailer

Set environment variables rather than committing credentials:

export SMTP_HOST='smtp.your-provider.example'
export SMTP_PORT='587'
export SMTP_USER='your-smtp-username'
export SMTP_PASS='your-smtp-secret'
export MAIL_FROM='Example App <notifications@example.com>'

Create send-test-email.mjs:

import nodemailer from 'nodemailer';

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT),
  secure: false,          // false means connect with SMTP, then use STARTTLS
  requireTLS: true,       // fail rather than sending without TLS
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  }
});

await transporter.verify();

const result = await transporter.sendMail({
  from: process.env.MAIL_FROM,
  to: 'you@recipient-example.net',
  subject: 'SMTP relay port 587 test',
  text: 'This message was submitted using SMTP port 587 and STARTTLS.'
});

console.log({
  messageId: result.messageId,
  accepted: result.accepted,
  rejected: result.rejected,
  response: result.response
});

Run it:

node send-test-email.mjs

In this configuration, secure: false is correct because port 587 does not start with an implicit TLS handshake. requireTLS: true makes the client insist on STARTTLS before proceeding. Do not copy this setting to port 465.

The same example on port 465

If your provider documents port 465 with implicit TLS, change only the relevant transport settings:

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: 465,
  secure: true,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  }
});

Here secure: true tells the client to start TLS immediately. Avoid setting secure: true on 587 unless your provider explicitly documents a nonstandard arrangement.

For provider-specific fields, supported authentication methods, and sender-domain setup, consult the service’s email API reference and setup guides rather than assuming every SMTP server accepts the same credentials.

How to test an SMTP relay port before deploying

Test in layers. This prevents you from diagnosing a sender-identity issue as if it were a firewall problem.

1. Test network reachability

From the same host, container, or serverless runtime that will send production mail, test whether the TCP port is reachable:

nc -vz smtp.your-provider.example 587

A successful TCP connection proves only that the network path is open. It does not prove TLS, authentication, sender authorization, or delivery.

2. Inspect a STARTTLS session on port 587

OpenSSL can show the TLS negotiation after SMTP STARTTLS:

openssl s_client \
  -starttls smtp \
  -connect smtp.your-provider.example:587 \
  -servername smtp.your-provider.example \
  -crlf

After the handshake, type:

EHLO test.example.com

Look for a successful SMTP response and advertised extensions. If you expected STARTTLS, it should have been negotiated before you provide credentials. Never paste real production credentials into a shared terminal recording or support ticket.

3. Inspect an implicit TLS session on port 465

For port 465, omit -starttls smtp because TLS begins at connection time:

openssl s_client \
  -connect smtp.your-provider.example:465 \
  -servername smtp.your-provider.example \
  -crlf

Then type EHLO test.example.com. If you use -starttls smtp against a true implicit-TLS listener, the test is using the wrong protocol for the port.

4. Send an authenticated test message with Swaks

Swaks is a scriptable SMTP transaction test tool with support for TLS and SMTP authentication. (jetmore.org)

A port 587 test looks like this:

swaks \
  --server smtp.your-provider.example \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user "$SMTP_USER" \
  --auth-password "$SMTP_PASS" \
  --from notifications@example.com \
  --to you@recipient-example.net \
  --header 'Subject: SMTP relay test' \
  --body 'Testing authenticated SMTP submission on port 587.'

Your provider may use a different authentication mechanism, and some use a literal username such as apikey with the generated API key as the password. Follow its documentation exactly.

How to tell whether the setup worked

There are four progressively stronger success signals:

1. TCP connected: the server and port are reachable.
2. TLS negotiated: certificate validation succeeds and encryption is active.
3. SMTP accepted the message: the provider returns a success response after DATA, commonly in the 2xx range.
4. The provider processed delivery: its logs show the message accepted, deferred, delivered, bounced, or suppressed.

The fourth signal is the one that matters for production operations. A relay response such as 250 commonly means the provider accepted responsibility for the message; it does not guarantee that the recipient mailbox displayed it in the inbox.

Check all of the following after a test:

• Your application logs include the SMTP response and provider message identifier.
• The provider’s activity log shows the same message.
• The recipient receives the message, or the provider records a specific bounce or deferral reason.
• The received message headers show expected SPF and DKIM results for your sending domain.
• The visible From: domain matches the domain you authenticated and intended to use.

For recipient testing, use a controlled mailbox you can inspect. Before sending a campaign, billing notice, or password-reset flow, verify that the target list contains valid recipients with an email address verification tool; a functioning SMTP port cannot prevent bounces caused by malformed or nonexistent addresses.

SMTP relay port errors and the fixes that actually work

Connection timeout or ETIMEDOUT

Likely cause: outbound firewall rules, a cloud-provider restriction, VPN routing, corporate proxying, an incorrect hostname, or a blocked port.

Fix: test with nc -vz from the production runtime. If 587 is blocked and your provider supports 2525, test 2525 with the same TLS mode. Do not automatically fall back to port 25: it is often restricted, including by default on AWS EC2. (repost.aws)

wrong version number, handshake failure, or unreadable greeting

Likely cause: mismatched TLS mode and port.

Fix: use implicit TLS for 465 and STARTTLS for 587. SendGrid’s troubleshooting guidance specifically identifies using STARTTLS against port 465 as an example of the wrong protocol for the port. (help.twilio.com)

535 Authentication failed

Likely cause: incorrect username, rotated secret, missing SMTP permission, an account policy that blocks password authentication, or attempting to use a normal account password where an app password or OAuth flow is required.

Fix: generate a new dedicated SMTP credential, check that SMTP access is enabled for the account or API key, and ensure the username format matches provider documentation. Do not log the password or API key while debugging.

530 Must issue STARTTLS first

Likely cause: you connected to a submission listener that requires encryption but your client did not upgrade.

Fix: enable STARTTLS and require it on port 587. If the client cannot use STARTTLS, use port 465 only if the provider supports implicit TLS and your client supports it.

550 Relaying denied, not permitted, or sender rejected

Likely cause: authentication did not complete, the source IP is not allowlisted, your account cannot send from that domain, or the visible From: address is unverified.

Fix: authenticate, verify the sender domain, authorize the exact sender identity, and confirm whether your provider distinguishes the From: address from the envelope MAIL FROM address.

Email sends but lands in spam

Likely cause: this is generally not a port problem. Content, recipient engagement, sender reputation, domain alignment, authentication, message formatting, and complaint patterns affect filtering.

Fix: verify SPF and DKIM first, publish and monitor DMARC, keep transactional and marketing streams separate, use a consistent sender domain, and process bounces and complaints. Google’s guidance requires SPF or DKIM for all senders and SPF, DKIM, and DMARC for its defined bulk-sender category. (support.google.com)

Security rules for SMTP relay configuration

A correct port choice protects only the connection from your application to the relay. It is still essential, because authentication credentials and message contents should not cross that leg in cleartext.

Use these rules in every environment:

• Require TLS for credentialed SMTP submission.
• Validate the relay certificate; do not disable certificate checking to make an error disappear.
• Store SMTP secrets in a secret manager or encrypted environment-variable system.
• Create separate credentials for development, staging, and production.
• Grant only needed sending permissions and rotate credentials after exposure or staff changes.
• Restrict IP-authenticated relays to known egress addresses when using IP allowlists.
• Never expose an unauthenticated relay to the public internet.
• Monitor sending activity, bounces, complaints, and unexpected volume.

MTA-STS is related but solves a different leg of the delivery path. It allows a receiving mail domain to declare TLS requirements for inbound SMTP delivery to its MX hosts; it does not replace TLS between your app and your submission provider. (rfc-editor.org)

SMTP relay port choices by use case

Website forms and transactional application email

Use a managed SMTP provider on 587 with STARTTLS. Create separate credentials for your production app. Configure a verified From: domain, then send password resets, receipts, account notifications, and form confirmations through that relay.

Avoid using a personal mailbox’s SMTP credentials in server code. Account-level restrictions, MFA policies, and sending limits can change, and the account is not designed to be your application’s permanent delivery infrastructure.

WordPress, CMS plugins, and no-code automations

Select 587 and an encryption choice labeled TLS or STARTTLS. If the plugin asks for “SSL,” use that only for 465 when the provider says implicit TLS is supported.

Run a test message from the plugin and then inspect the provider activity log. A green “test successful” message inside a plugin may only indicate that it handed off to PHP or opened a socket; provider logs are the better source of truth.

Printers, scanners, and legacy devices

Try the device’s supported encrypted submission mode first. If it supports STARTTLS and modern certificates, use 587. If it supports only SSL/TLS-style configuration, use 465 only when your mail service documents it.

Google Workspace’s SMTP relay service, for example, documents ports 25, 465, and 587; with TLS, its setup guidance directs on-premises servers to port 587. It can authenticate devices by approved IP addresses, which is useful when a device cannot safely store user credentials. (knowledge.workspace.google.com)

Self-hosted Postfix or another mail transfer agent

Use port 25 for outbound server-to-server delivery, but treat deliverability and abuse prevention as first-class operations work. Alternatively, configure your MTA as a smart host that submits outgoing mail to a managed provider over 587 or 465, depending on the provider’s requirements.

The smart-host approach often avoids cloud port-25 restrictions and removes much of the operational burden of direct delivery. It does not eliminate the need for sender-domain authentication and clean mailing practices.

The durable rule: choose the port and TLS mode as a pair

The best SMTP relay port is not universally one number. It depends on who is connecting and how the session must start.

For most apps, the reliable default is port 587 with STARTTLS and required authentication. Use 465 with implicit TLS when your provider or client requires TLS from the start. Reserve 25 for mail-server relay or controlled infrastructure, and use 2525 only as a documented provider fallback when a network blocks the normal submission route.

Once the connection works, move beyond port testing. Verify sender authorization, SPF, DKIM, DMARC, provider activity logs, bounce handling, and actual receipt in a controlled inbox. That is the difference between “SMTP connected” and an email system you can rely on.

FAQ

What is the best SMTP relay port?

For most applications, use 587 with STARTTLS. It is the normal port for authenticated message submission under RFC 6409. (rfc-editor.org)

Should I use SMTP port 465 or 587?

Use 587 when your client supports STARTTLS. Use 465 when the provider requires implicit TLS or your client is specifically configured for SSL/TLS from the initial connection. Do not enable STARTTLS on a true port-465 implicit-TLS connection.

Why is SMTP port 25 blocked?

Networks commonly restrict port 25 to reduce abuse from compromised machines and spam operations. AWS, for example, restricts outbound port 25 by default for EC2 and Lambda network interfaces unless an account is allowlisted or the restriction is removed through its process. (repost.aws)

Is port 2525 secure for SMTP?

Port 2525 can be secure when your provider supports it and you negotiate TLS correctly, usually with STARTTLS. The port number itself does not encrypt anything; verify the provider’s documented TLS mode.

Does choosing the right SMTP port improve email deliverability?

It improves the chance that your app can securely submit mail to its relay, but it does not by itself improve inbox placement. Deliverability also depends on authentication, domain alignment, reputation, content, recipient quality, bounce handling, and recipient-server policies. (support.google.com)