term · smtp port

Which SMTP port should an application use for email?

Most applications should use the submission endpoint and port documented by their email provider. Port 587 is the standard message-submission port and usually starts in plain SMTP before a STARTTLS upgrade. Port 465 is message submission with implicit TLS, so the TLS handshake begins immediately. Port 25 is primarily for server-to-server SMTP relay, not routine authenticated application submission. A working configuration must match four things together: hostname, port, TLS mode, and authentication method.

An SMTP port selects a protocol role and connection mode

A port number is not merely an interchangeable door into the same service. It helps identify which SMTP role the server offers and how the connection begins. Message submission is the first handoff from an application or user agent to a submission service. Relay is the transfer of mail between mail servers. Standards separate those jobs because submission can require authentication, sender authorization, and message-policy checks that do not apply in the same way to public mail relay. The port can also indicate whether the client starts with SMTP commands and later upgrades with STARTTLS or begins with a TLS handshake immediately. Treat the provider's hostname, port, TLS mode, and authentication instructions as one configuration tuple. Copying a port from an unrelated provider, or changing only the port after an error, can turn a network problem into a TLS or authentication failure without fixing the original cause.

Port 25 is mainly for mail-server relay

Port 25 is the conventional SMTP relay port used when one Message Transfer Agent hands mail to another. RFC 6409 keeps relay on port 25 while separating new-message submission onto port 587. An application should therefore not assume that direct connections to recipient mail servers on port 25 are the normal way to send product email. Direct relay requires queueing, DNS routing, bounce handling, abuse controls, reputation management, and standards-compliant retry behavior. Networks and hosting providers may also restrict outbound port 25. AWS, for example, documents throttling of Amazon EC2 email traffic on port 25 by default. Port 25 can still be a documented option at a provider or inside controlled infrastructure, but its availability does not make it the preferred submission choice. Use it only when the responsible service explicitly documents that endpoint, security mode, and operational model.

Port 587 is the standard message-submission port

RFC 6409 reserves port 587 for message submission and describes a submission service that can reject unauthorized mail, require authentication, and enforce policy before accepting a new message. A common port 587 session begins as SMTP, advertises the STARTTLS extension after `EHLO`, upgrades the connection to TLS, repeats `EHLO`, authenticates, and then submits the message. The word common matters: the exact authentication mechanisms and requirements come from the provider's current documentation and server capabilities. A secure client should require the expected TLS upgrade and validate the server certificate instead of continuing in cleartext after a failed negotiation. Do not confuse an initial unencrypted protocol greeting with an unprotected authenticated session; STARTTLS is designed to upgrade that connection before credentials and message data are sent. Port 587 identifies the submission service, while successful TLS enforcement depends on correct client policy.

Port 465 uses implicit TLS for submission

Port 465 is registered for message submission over implicit TLS. With implicit TLS, the client performs the TLS handshake as soon as the TCP connection opens and sends SMTP commands only inside the protected channel. That differs from port 587 with STARTTLS, where the client first receives an SMTP greeting and then requests the upgrade. RFC 8314 recommends implicit TLS for submission while also describing a transition in which providers and clients can support both port 465 with implicit TLS and port 587 with STARTTLS. The RFC notes that correctly implemented clients and servers can provide substantially equivalent security with either mode when TLS is mandatory. The practical rule is not to declare one port universally correct. Use the exact endpoint and mode the provider supports. Configuring STARTTLS against an implicit-TLS listener, or implicit TLS against a STARTTLS listener, usually fails before authentication.

Provider-specific alternate ports are explicit contracts

Some providers offer alternate ports to work around network restrictions, but those numbers are not universal SMTP standards for every service. Amazon SES currently documents STARTTLS on ports 25, 587, and 2587, and TLS Wrapper, its term for implicit TLS, on ports 465 and 2465. SES requires encrypted connections and publishes region-specific SMTP endpoints. This illustrates why a port must be taken from the chosen provider's documentation rather than a generic list. Port 2587 does not mean STARTTLS everywhere, and port 2465 does not identify an implicit-TLS service on arbitrary hosts. Alternate ports also do not bypass sender verification, credential scope, quotas, or provider policy. Record the source URL and verification date with production configuration so an operator can distinguish an intentional provider setting from an unexplained magic number copied into an environment variable years earlier.

Configure hostname, port, TLS, and authentication together

A robust SMTP configuration is a bundle: the provider hostname, port, transport-security mode, certificate-validation policy, authentication mechanism, username, secret, connection timeout, and sending identity. The hostname matters because the TLS certificate is validated against it and because providers may expose different regional endpoints. The port and TLS mode must agree. Authentication should occur only after the intended protected channel exists, and secrets should stay in a secret manager rather than source code, browser bundles, logs, or diagnostic output. Separate credentials and configuration by environment so a local test cannot accidentally send through production. Set finite connection and command timeouts, but let a durable application queue control message retries. A library option named `secure` can mean implicit TLS in one SDK and merely require STARTTLS in another, so verify the library's definition and test the negotiated behavior rather than relying on the option name.

Test the connection in layers without exposing secrets

Start with DNS resolution and TCP reachability from the same runtime network as the application. A timeout before connection points toward routing, firewall, provider egress policy, a wrong hostname, or a closed port. Next test the expected TLS mode. For implicit TLS, a TLS client should receive a certificate and then an SMTP greeting. For STARTTLS, an SMTP-aware client should receive the greeting, issue `EHLO`, see STARTTLS advertised, request the upgrade, validate the certificate, and issue `EHLO` again after TLS. RFC 3207 requires the client and server to discard knowledge obtained before the handshake, which is why the second `EHLO` matters. Only then test authentication with a controlled account. Redact usernames, tokens, recipient addresses, full server transcripts, and message content before sharing logs. A connectivity probe does not need a production send or a real customer address.

Classify failures by the stage that actually failed

A refused connection means the TCP destination actively declined the connection; a timeout means no usable response arrived within the limit. A TLS handshake error points to a mode mismatch, certificate problem, protocol incompatibility, interception, or wrong endpoint. An authentication error occurs later and should be investigated as credential, mechanism, account, or authorization configuration rather than fixed by random port changes. SMTP reply codes during `MAIL FROM`, `RCPT TO`, or `DATA` describe still later policy and message decisions. Preserve the stage, timestamp, endpoint, attempt count, numeric reply, and a privacy-filtered response. A 4xx SMTP reply is normally transient and a 5xx reply is normally permanent for that attempted command, but retries must be bounded and recipient-aware. If the provider accepted message data, do not blindly submit a duplicate because a later application request timed out; reconcile using the provider identifier and event history.

Port success is not message delivery or inbox placement

A successful TCP connection proves only that a listener answered. A successful TLS handshake proves a protected connection to the authenticated endpoint when certificate validation succeeds. Authentication proves that the server accepted the presented client identity for that session. An SMTP `250` response after message data means the responding server accepted responsibility under the protocol, not that a person received or read the message. A later relay can still fail, and a receiving system can accept mail while classifying it outside the primary inbox. Keep these states separate in application records and monitoring. Network availability, TLS negotiation, authentication, provider acceptance, destination-server acceptance, bounce, complaint, and engagement are different observations. This separation prevents a port probe from being misreported as a delivery test and prevents an accepted message from being retried merely because inbox placement cannot be proven.

Choose SMTP submission or an email API deliberately

Use SMTP submission when a system already has a mature SMTP client, when a required platform exposes SMTP as its supported integration, or when protocol-level controls are specifically necessary. An HTTPS email API can be a better application boundary when structured requests, scoped tokens, idempotency, batch resources, and machine-readable event records fit the workload. The provider can still use SMTP downstream to reach recipient mail systems, so an API does not abolish mail transport. It moves the port, TLS, authentication, and retry responsibility for the provider-facing handoff out of application SMTP configuration.

Frequently asked questions

Should my application use SMTP port 587 or 465?

Use the port and TLS mode your provider documents. Port 587 normally uses STARTTLS, while port 465 uses implicit TLS. Both can protect submission when correctly implemented and required; the client configuration must match the server listener.

Why is SMTP port 25 blocked or timing out?

A hosting platform, ISP, firewall, or destination policy may restrict port 25 because it is used for mail-server relay and is frequently abused. Confirm the network policy and use the provider's documented submission endpoint rather than evading a restriction with an arbitrary port.

Can I switch from port 587 to 465 without changing anything else?

Usually not. Port 587 commonly begins with SMTP and upgrades through STARTTLS, while port 465 begins with an immediate TLS handshake. Change the port and the client's TLS mode together, following the provider and library documentation.

Is port 587 encrypted by default?

The port identifies message submission, but encryption still depends on STARTTLS negotiation and client policy. Configure the client to require a successful upgrade, validate the certificate, and refuse to send credentials or message data if protected submission cannot be established.

What does SMTP connection refused mean?

It means the TCP destination rejected the connection before SMTP negotiation. Common causes include the wrong host or port, a service that is not listening, a firewall rejection, or a provider endpoint unavailable from that network.

Does a successful SMTP port test prove email delivery?

No. It proves only the stages the test actually completed, such as TCP or TLS. Authentication, message acceptance, destination-server acceptance, bounce handling, mailbox classification, and recipient engagement require separate evidence and must be reported separately.

Sources

Continue learning

SMTP Mail Protocol: How Application Email MovesLearn how SMTP submission, relay, envelopes, response codes, TLS, retries, and message content shape an application email workflow.How to Evaluate an SMTP Relay ServiceEvaluate SMTP relay services by submission security, authentication, queues, retry behavior, limits, delivery events, suppression, isolation, and migration fit.Email API Implementation Guide for Product TeamsDesign a safe email API integration with verified domains, queued sends, stable identifiers, controlled retries, delivery events, suppression, and tenant isolation.How to Evaluate an Email Deliverability ServiceEvaluate email deliverability services by scope, evidence, authentication, feedback loops, suppressions, privacy, portability, and operational fit.