SMTP Port: Which SMTP Port Should I Use?

An SMTP port is the network port an email client, application, or mail server uses to submit or relay mail. For application sending, use your provider's documented submission settings: port 465 with implicit TLS or port 587 with STARTTLS. Both can provide a secure connection when TLS is required and the server certificate is verified.

Port 25 is primarily for transferring mail between servers. Port 2525 is an alternative offered by some providers. The port and encryption mode must match; changing only the number can leave a working application unable to send.

SMTP ports quick table

Port	Common role	TLS configuration	When to use it
465	Authenticated message submission	Implicit TLS: the handshake starts immediately	Your provider and client support submission over TLS
587	Authenticated message submission	STARTTLS: upgrade the SMTP connection before authentication or submission	Your provider documents STARTTLS submission
25	Server-to-server SMTP relay	STARTTLS and relay policy depend on the mail servers	You operate a mail server or a specifically configured relay
2525	Provider-specific alternative	Follow the provider's documented TLS mode	Your provider offers it and a standard submission port is unavailable

For Gmail, for example, the outgoing host is smtp.gmail.com, with 465 for implicit TLS or 587 for STARTTLS. Use the Gmail SMTP setup guide for its separate authentication requirements.

Choosing between port 465 and port 587

With implicit TLS on 465, the client negotiates encryption as soon as it connects. The SMTP conversation takes place inside that encrypted connection. Some settings screens call this "SSL" or "SSL/TLS" even though modern connections use TLS.

With STARTTLS on 587, the server first sends an SMTP greeting and the client requests its capabilities. The client then issues STARTTLS, negotiates TLS, and requests the capabilities again before authenticating. Configure the client to stop if TLS cannot be established, rather than continuing with unencrypted credentials or mail.

RFC 8314, section 3.3 recommends implicit TLS for submission and also describes support for STARTTLS on 587. It notes that properly implemented 465 and 587 connections have no significant security difference when both sides require successful TLS negotiation before submission. Port 587 is therefore not inherently more secure, and port 465 is not obsolete.

Choose the mode your provider supports and your client can enforce correctly. If both are documented, implicit TLS is a straightforward choice. An existing, correctly configured STARTTLS connection does not need to be replaced merely because the other port exists.

Submission and relay are different jobs

An application submitting a password-reset email hands it to a service authorized to send on its behalf. A mail server relaying that email transfers it toward the recipient's domain. RFC 6409 separates submission, normally on 587, from SMTP relay on 25; implicit TLS submission on 465 is specified separately in RFC 8314.

If your app just needs to send mail, use the provider's submission hostname rather than a recipient domain's MX server. A server that accepts inbound mail for its own domain is not automatically authorized to relay your application mail elsewhere.

If a connection times out, inspect your hosting and network egress rules. For example, Amazon EC2 restricts outbound port 25 by default. Use a supported submission endpoint for application mail. Try 2525 only if your email provider documents it; it is not a universal backup port and must still use the prescribed TLS and authentication settings.

Which email server port is for receiving mail?

An email client usually has separate incoming and outgoing server settings. SMTP is for sending. IMAP and POP are for accessing a mailbox; entering an IMAP port into the outgoing SMTP field will not work.

Client setting	Protocol	Common encrypted port
Outgoing mail	SMTP submission	465 with implicit TLS or 587 with STARTTLS
Incoming mail with folders and synchronization	IMAP	993 with implicit TLS
Incoming mail downloaded with POP	POP3	995 with implicit TLS

Use the incoming hostname your mailbox provider supplies, which may differ from its outgoing hostname. The email TLS guide explains how the encryption mode and certificate checks apply to these connections.

Once the connection works, try a send from the app. MailSlurp provides test inboxes where you can inspect the message that arrives and repeat the check after changing your settings.

Put the port and TLS mode into your application

Take the host, port, TLS mode, and authentication method from the same provider configuration. Avoid mixing a hostname from one service with a port or credential from another account.

In your SMTP library, enable immediate TLS for 465 or require a STARTTLS upgrade for 587. Read that library's option definitions: a setting named secure, SSL, or TLS may describe when encryption starts, not whether encryption will ever be used. Keep certificate and hostname validation enabled in either mode.

Use the full authentication identity the provider expects, store the credential in the application's secret store, and set a connection timeout. Gmail may require OAuth or an eligible account's app password; another provider may supply a dedicated SMTP credential. An HTTP API key is not automatically an SMTP password.

For complete library-specific examples, see Node.js SMTP, Python SMTP, Java SMTP, or PHP SMTP.

Troubleshoot the stage that fails

Run diagnostics from the same host, container, or network that sends the application mail. A connection from your laptop or an external tester follows a different network path and can succeed even when your application's egress is blocked.

Symptom	Check before changing credentials
DNS error	Confirm the submission hostname and the runtime's DNS resolution
Timeout or connection refused	Confirm the host, port, egress rules, and service availability
TLS error on 587 before an SMTP greeting	Check whether the client incorrectly attempted implicit TLS
Client waits for a greeting on 465	Check whether it should initiate TLS immediately
Must issue STARTTLS first	Require a STARTTLS upgrade before authentication on the documented endpoint
Certificate error	Check hostname, certificate chain, expiry, runtime trust store, and system clock
Authentication rejected	Check the account, permitted auth method, credential, and provider policy
Relay denied	Check the submission service, authorized sender, and relay permissions

These symptoms narrow the investigation; they do not uniquely identify a cause. Preserve the full SMTP error and the command that received it. Never fix a certificate error by disabling verification or allowing a plaintext fallback.

Verify receipt after fixing the connection

The SMTP tester helps inspect connectivity, STARTTLS negotiation, and authentication diagnostics. For a certificate-verified probe that runs from your own environment without sending a message, use the Python TLS check.

Then address one application test message to a fresh MailSlurp inbox and trigger the real workflow. Wait for that message and inspect its sender, recipient, content, and required links or attachments. If it does not arrive, trace the application's send job and provider events rather than repeatedly changing the port.

A final SMTP success response records acceptance at that stage; it does not prove inbox placement or that the recipient opened the email. Test the affected mailbox providers separately when you need placement evidence.

If the provider accepted the message but it is still waiting for onward delivery, continue with queued email troubleshooting. The next useful evidence is the queue's last attempt and response, not another port number.