MailSlurp logo

blog

SMTP Port: Which SMTP Port Should I Use?

Choose the right SMTP port number for sending email. Compare ports 25, 465, 587, and 2525, then test TLS, SMTP AUTH, and inbox delivery with MailSlurp.

An SMTP port is the network port an email client, application, or mail server uses to submit or relay mail. If you are asking which SMTP port should I use, the safest default for application sending is usually port 587 with SMTP AUTH and STARTTLS.

The right SMTP port number still depends on your provider, TLS mode, network rules, and whether you are submitting mail from an app or relaying mail between servers. MailSlurp helps teams test that decision with SMTP diagnostics, sandbox inboxes, message inspection, and deliverability checks.

Quick answer: which SMTP port should I use?

Use this order for most modern applications:

  1. Use port 587 with STARTTLS for authenticated SMTP submission.
  2. Use port 465 when your provider requires implicit TLS from the start of the connection.
  3. Use port 2525 as an alternate submission port when 587 is blocked and your provider supports it.
  4. Use port 25 mainly for server-to-server relay, not ordinary app submission.

If you need one answer, start with 587 and STARTTLS, then validate the connection and inbox result before release.

SMTP ports quick table

Port Common role TLS mode Best use Common mistake
25 Server-to-server relay Opportunistic or policy-specific STARTTLS Mail transfer between MTAs Using it for app submission in a cloud network where outbound 25 is blocked
465 SMTP submission Implicit TLS Providers that require TLS before SMTP commands Configuring it as STARTTLS
587 SMTP submission STARTTLS Default authenticated app sending Treating it as implicit TLS
2525 Alternate SMTP submission Provider-specific, often STARTTLS Fallback when 587 is blocked Assuming every provider supports it

SMTP port numbers at a glance

The port number tells your app where to connect. It does not, by itself, prove that the connection is encrypted or that the message will reach an inbox.

  • Port 587 is the best first setting for most app, SaaS, CI, and transactional email workflows.
  • Port 465 is the right setting when the provider says to use SMTPS, implicit TLS, or SSL from connection start.
  • Port 25 is for mail transfer between servers and is often blocked for app traffic.
  • Port 2525 is an alternate submission port some providers support when standard submission ports are unavailable.

For production email, test the port together with TLS, authentication, sender identity, headers, and final receipt in a MailSlurp inbox.

Scenario Start with Why
SaaS app sending signup, login, OTP, reset, invite, billing, or alert email 587 with STARTTLS Standard authenticated submission with broad provider support
Email client or library asks for secure: false plus STARTTLS 587 Many libraries connect in plain SMTP first, then upgrade with STARTTLS
Email client or library asks for secure: true from connection start 465 Implicit TLS starts before SMTP commands are exchanged
Cloud server cannot connect on standard submission ports 2525 if provider supports it Useful fallback, but only when documented by the provider
Mail server handing off mail to another MTA 25 Relay traffic belongs on the traditional SMTP transfer port

Decision framework

Choose the port by answering these questions in order.

1. Are you submitting email from an app?

Use port 587 first. It is the standard submission port for authenticated application sending. Your client connects, the server advertises capabilities, the client issues STARTTLS, and authentication happens over the encrypted connection.

Use MailSlurp's SMTP tester to check host, port, TLS negotiation, and SMTP AUTH behavior before you put the configuration into production.

For app teams, the practical release check is not just "does the port connect." Send a real staging message to Email Sandbox and confirm the received body, links, headers, OTP codes, reset URLs, and attachments.

2. Does your provider require implicit TLS?

Use port 465 when your provider documents SMTPS or implicit TLS. On 465, the TLS session starts immediately when the connection opens. Do not configure 465 as if it were a STARTTLS upgrade port.

3. Is port 587 blocked?

Use port 2525 only when your provider supports it and your network blocks 587. Port 2525 is common as a provider fallback, but it is not the universal default.

4. Are you relaying mail between mail servers?

Use port 25 for server-to-server mail relay scenarios. Avoid it for normal app submission because many cloud providers, ISPs, and corporate networks restrict outbound 25.

SMTP port settings for common implementation work

Use this checklist when translating the SMTP port decision into an application setting:

  1. Set the SMTP host to the provider's submission hostname, not a web dashboard URL.
  2. Use port 587 with STARTTLS for most app sending.
  3. Use port 465 only when implicit TLS is documented.
  4. Keep SMTP AUTH enabled unless the provider documents another authenticated relay model.
  5. Store credentials in environment-specific secrets and rotate them with a test run.
  6. Send a controlled test email to MailSlurp before enabling user-facing traffic.

For code examples, see the Node SMTP guide, Python SMTP guide, Java SMTP guide, and PHP SMTP guide.

What is the secure port for SMTP?

There is no secure SMTP port by number alone. The secure choice is the port plus the correct TLS mode:

  • 587 with STARTTLS is the normal secure SMTP submission setup.
  • 465 with implicit TLS is secure when your provider expects TLS from connection start.
  • 25 can use STARTTLS between servers, but it is not the right default for app-level authenticated submission.
  • 2525 can be secure when the provider supports TLS and documents the expected configuration.

For most application teams, 587 with STARTTLS is the best answer to secure port for SMTP.

SMTP submission port vs relay port

SMTP submission and SMTP relay solve different jobs.

Job Best port starting point What to validate
App sends password reset, OTP, billing, or notification email 587 with STARTTLS SMTP AUTH, TLS, sender alignment, inbox receipt
Provider requires implicit TLS 465 TLS handshake starts immediately, then AUTH works
Network blocks normal submission 2525 if provider supports it Provider docs, TLS support, production egress policy
Mail server relays to another mail server 25 Relay policy, STARTTLS support, DNS, abuse controls

If your application only needs to send user-facing email, treat this as a submission problem. Start with 587, validate the connection, then validate the received message in a MailSlurp inbox.

Common failure patterns by SMTP port

587 misconfigured as implicit TLS

If you treat 587 as implicit TLS instead of STARTTLS, the connection can fail before authentication. Configure the client to connect first, issue STARTTLS, then authenticate.

465 used with STARTTLS assumptions

Port 465 generally expects TLS from connection start. If your client waits for a plain SMTP banner before TLS, the handshake can fail.

25 blocked in cloud environments

Many cloud providers restrict or throttle outbound 25 traffic for abuse prevention. Use a submission endpoint instead of trying to force application traffic through 25.

2525 copied from another provider

Port 2525 is not guaranteed. Use it only when your provider explicitly supports it and your SMTP client can use the documented TLS mode.

SMTP accepted the message but no customer received it

SMTP acceptance means the sending server accepted responsibility for the message at that step. It does not prove inbox placement, rendering, link behavior, or user visibility. Capture the received message in Email Sandbox, inspect it with the Email header analyzer, and run an Email deliverability test when sender posture or inbox placement matters.

SMTP port troubleshooting matrix

Symptom Likely cause First check
Connection times out Firewall, cloud egress policy, wrong host, blocked port Test host and port reachability from the same environment
Must issue STARTTLS first Client authenticated before TLS upgrade Enable STARTTLS on 587
TLS handshake fails on 587 Client is using implicit TLS on a STARTTLS port Switch to STARTTLS mode
TLS handshake fails on 465 Client expects STARTTLS on an implicit TLS port Switch to implicit TLS mode
SMTP accepts the message but user never receives it Delivery, filtering, sender auth, or content issue Send to a MailSlurp inbox and run deliverability checks
Works locally but fails in production Different egress, DNS, secret, TLS, or provider policy Reproduce from staging or CI with the production-like config

Security checks to run with port selection

Port selection is only one part of email reliability. Before release, verify:

  • SMTP AUTH mechanism and credential behavior
  • TLS mode and certificate behavior
  • sender-domain alignment with SPF, DKIM, and DMARC
  • final message headers and return-path
  • inbox receipt and placement outcome
  • template variables, OTP codes, reset links, attachments, and unsubscribe or preference links where relevant

Recommended references:

MailSlurp validation workflow for SMTP ports

A working SMTP handshake is not enough. The message also needs to arrive, render correctly, pass important assertions, and avoid avoidable deliverability risk.

Use this workflow:

  1. Run the SMTP tester to validate host, port, TLS, and authentication behavior.
  2. Send the final rendered message to a MailSlurp inbox or Email Sandbox.
  3. Inspect headers, body, links, attachments, OTPs, and reset URLs.
  4. Check authentication with SPF, DKIM, and DMARC.
  5. Run Email deliverability testing when sender posture or inbox placement matters.
  6. Add Email integration testing so critical SMTP workflows stay covered in CI.

Use that workflow before provider migrations, credential rotations, domain-authentication changes, lifecycle campaign launches, or new transactional templates. It catches the difference between a connection that is technically accepted and an email experience that customers can actually use.

FAQ

What is an SMTP port?

An SMTP port is the network endpoint used for SMTP submission or relay. The port tells your client where to connect, but the TLS mode, authentication, and provider policy determine whether the setup actually works.

What SMTP port number should I enter in my app?

For most application sending, enter port 587 and enable STARTTLS. Use port 465 only when your provider explicitly documents implicit TLS.

Port 587 with STARTTLS is the most common recommendation for authenticated application submission.

Is port 587 better than port 465?

For most application sending, start with 587 because it is the standard message submission port with STARTTLS. Use 465 when your provider requires implicit TLS.

Is port 465 still valid?

Yes. Port 465 is still used by many providers for implicit TLS submission. It is valid when the provider documents it.

Should applications use port 25?

Usually no. Port 25 is mainly for server-to-server relay and is commonly blocked for application egress.

Is port 2525 safe to use?

Port 2525 can be safe when your provider supports it and documents the TLS mode. Treat it as a fallback, then verify the connection, authentication, and inbox receipt.

Why does SMTP work locally but fail in production?

Production often has different firewall rules, secret values, DNS records, TLS libraries, provider policies, and egress restrictions. Test from the same environment path that will send user-facing email.

Does choosing the right SMTP port guarantee delivery?

No. Correct port selection proves the connection path is plausible. You still need authentication checks, message inspection, spam checks, and inbox placement validation.

Can MailSlurp test my SMTP port?

Yes. Use the SMTP tester for host, port, TLS, authentication, and transcript diagnostics. Then send a real message to MailSlurp so your team can assert the inbox outcome before customers rely on it.

Next steps