# SMTP ports 25, 465, 587, and 2525: which one should you use? > Choose the right SMTP port for an app, mail client, or server. Understand relay versus submission, STARTTLS versus implicit TLS, authentication, and practical connection tests. - **Category:** Developer guide - **Published:** August 4, 2026 - **Reading time:** 15 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/smtp-ports-25-465-587-2525](https://emailbump.com/blog/smtp-ports-25-465-587-2525) Use SMTP port 587 with required STARTTLS for most applications and mail clients. Use port 465 when your provider supports implicit TLS and your library is configured to begin TLS immediately. Port 25 is primarily for server-to-server relay, not authenticated application submission. Port 2525 is a provider-specific fallback when documented; it is not the standards-defined message-submission port. > **The short answer** > > App or mail client: 587 + STARTTLS, or 465 + implicit TLS when your provider says so. Mail server delivering to another mail server: 25. Port 2525: only when the selected provider documents it and the standard ports are unavailable. ## SMTP port comparison ### SMTP ports at a glance ```text PORT ROLE TLS MODE TYPICAL AUTH 25 Server-to-server SMTP relay STARTTLS when available MTA policy, often no user AUTH 465 Message submission Implicit TLS at connect SMTP AUTH 587 Message submission STARTTLS, require success SMTP AUTH 2525 Provider-specific fallback Provider-defined SMTP AUTH For application email, use the host, port, TLS mode, and credentials as one provider-issued configuration. A port number alone does not make a connection safe. ``` ## Port 587: the normal application-submission choice RFC 6409 separates message submission from SMTP relay and reserves port 587 for submission. A client connects in cleartext protocol mode, requests STARTTLS, validates the server certificate, and authenticates before submitting mail. Configure the client to require TLS; opportunistic fallback to credentials over an unencrypted connection defeats the point. ### Typical port 587 configuration ```text SMTP_HOST=smtp.provider.example SMTP_PORT=587 SMTP_SECURE=false # no TLS handshake at TCP connect SMTP_REQUIRE_TLS=true # issue STARTTLS and fail if it cannot succeed SMTP_USERNAME=provider-issued-username SMTP_PASSWORD=provider-issued-secret ``` Library names are inconsistent. Some call implicit TLS secure and STARTTLS secure=false plus requireTLS=true. Others use starttls, tls_mode, or encryption. Read the provider and library documentation together; copying a Boolean from another library is a common source of handshake errors. ## Port 465: implicit TLS from the first byte On port 465, the TLS handshake begins immediately after the TCP connection. RFC 8314 registers the submissions service on 465 and recommends implicit TLS for mail submission, while also recognizing the broad deployment of STARTTLS on 587. Both can provide strong transport security when the client validates certificates and refuses to submit unless TLS succeeds. ### Typical port 465 configuration ```text SMTP_HOST=smtp.provider.example SMTP_PORT=465 SMTP_SECURE=true # TLS begins immediately SMTP_USERNAME=provider-issued-username SMTP_PASSWORD=provider-issued-secret Do not connect in cleartext and issue STARTTLS on 465. That is the wrong protocol mode. ``` ## Port 25: SMTP relay between mail servers Port 25 remains the default route for one mail transfer agent to deliver mail to another domain's MX server. That traffic differs from an application authenticating to its outbound provider. Cloud hosts and networks frequently restrict outbound 25 to reduce abuse, and changing an app to 25 usually creates a policy or connectivity problem rather than solving one. STARTTLS on port 25 is normally negotiated between independent mail servers. The security and authentication policy is not the same as authenticated submission. Do not put application credentials on an arbitrary recipient MX server, and do not assume that finding an MX record gives your product a supported email-sending service. ## Port 2525: useful fallback, not an Internet submission standard Several email providers accept authenticated submission on 2525 because some networks block the standard SMTP ports. That convention does not make 2525 a standards-assigned SMTP submission port. Use it only when your email provider explicitly documents the endpoint and TLS behavior. Prefer 587 or 465 when both your network and provider support them. ## STARTTLS and implicit TLS are not interchangeable ### Handshake difference ```text 587 + STARTTLS 465 + IMPLICIT TLS TCP connect TCP connect Server: 220 greeting TLS handshake starts immediately Client: EHLO Certificate validation Server advertises STARTTLS Encrypted SMTP greeting Client: STARTTLS Client: EHLO TLS handshake + certificate validation Client authenticates Client: EHLO again + authenticate Client submits message In either case: stop if TLS or certificate validation fails. ``` ## How to test an SMTP connection safely ### OpenSSL diagnostics ```bash # Port 587: connect, then negotiate STARTTLS openssl s_client -starttls smtp -connect smtp.provider.example:587 \ -servername smtp.provider.example -crlf # Port 465: TLS starts immediately openssl s_client -connect smtp.provider.example:465 \ -servername smtp.provider.example -crlf ``` These commands help inspect DNS resolution, reachability, the certificate chain, and the server greeting. Do not paste production credentials into a shared terminal recording or support ticket. A successful TLS socket also does not prove the account may send from a given domain; submission authentication, sender verification, quotas, and policy checks happen later. ## Diagnose common SMTP port errors - Connection timed out: check DNS, egress firewall rules, hosting restrictions, and whether the provider listens on that exact port. - Wrong version number or unexpected record: the client likely used implicit TLS against a STARTTLS endpoint, or the reverse. - STARTTLS not advertised: confirm you reached the provider's submission host, not an unrelated MX endpoint; do not silently downgrade. - Certificate name mismatch: use the provider's documented hostname and preserve SNI and certificate validation. - Authentication failed: verify username format, scoped credential, secret rotation, and whether SMTP access is enabled. - Relay denied: the server authenticated no permitted sender/account, or the From domain is not verified. - Accepted but not delivered: SMTP submission succeeded; now inspect message ID, provider events, bounces, suppression, and recipient-server response. ## Production SMTP configuration checklist - Copy hostname, port, TLS mode, and credentials from the same provider configuration page. - Require modern TLS and certificate validation; never accept any certificate in production. - Store credentials only in server-side secret storage and rotate them independently of user passwords. - Set connect, greeting, command, and overall timeouts; a hung SMTP socket should not hang a web request. - Pool connections within provider limits and reconnect cleanly after idle or protocol errors. - Treat a timeout after DATA as ambiguous because the provider might already have accepted the message. - Persist message intent and use an idempotency strategy instead of blind application retries. - Capture the provider message ID and delivery webhooks; SMTP 250 means accepted for processing, not delivered to the inbox. ## Frequently asked questions ## Is port 587 SSL or TLS? Port 587 normally uses STARTTLS: the SMTP connection begins, the client requests a TLS upgrade, and submission proceeds only after successful TLS negotiation. Configure the client to require that upgrade. SSL is an obsolete label that many dashboards still use imprecisely. ## Should I use SMTP port 465 or 587? Use either mode your provider documents and your client implements correctly. Port 587 uses STARTTLS; port 465 uses implicit TLS. Do not choose by port alone—certificate validation, required encryption, authentication, credentials, and provider support are all part of the configuration. ## Why is port 25 blocked? Many infrastructure providers restrict outbound port 25 to limit spam and compromised-host abuse. Applications normally do not need it: submit to an email provider on 587 or 465. If you operate an MTA that must relay on 25, follow the host's documented approval process and operate the required DNS, reputation, abuse, and security controls. ## Submit application email on a supported transport Use Email Bump's transactional API for explicit HTTP semantics or its authenticated SMTP endpoint for existing libraries, then follow delivery through message events. - Documented submission settings - TLS-protected authenticated sending - Delivery, bounce, and complaint events [Learn more](https://emailbump.com/docs/transactional-api) ## Continue the implementation - [REST email API](https://emailbump.com/blog/send-email-rest-api) — Compare HTTP submission, idempotency, retries, timeouts, and webhooks. - [Email API guide](https://emailbump.com/blog/email-api) — Choose between SMTP, transactional APIs, inbox APIs, and marketing automation. - [Bounce handling](https://emailbump.com/blog/email-bounce-handling-guide) — Interpret the recipient-server response after successful submission. - [Email deliverability checklist](https://emailbump.com/blog/email-deliverability-checklist) — Verify authentication, DNS, sender identity, and monitoring beyond the port. ## Sources - [RFC 6409: Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409) - [RFC 8314: TLS for Email Submission and Access](https://www.rfc-editor.org/rfc/rfc8314) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [IANA service name and port registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)