SMTP ports define how your client connects to a mail server for submission or relay.

Fast answer

  • Use 587 with STARTTLS for most application email submission.
  • Use 465 when your provider requires implicit TLS.
  • Avoid 25 for app submission unless explicitly required for server-to-server relay.
  • Use 2525 only as a provider-specific fallback.

Port reference table

PortTypical useEncryption modelRecommendation
25Server-to-server relayOptional/variesAvoid for app clients
465Message submissionImplicit TLSUse when provider documents it
587Message submissionSTARTTLSBest default for most apps
2525Alternate submissionUsually STARTTLSFallback when 587 blocked

Why port choice fails in production

Common failure patterns:

  1. Using implicit TLS settings on a STARTTLS port.
  2. Connecting to 25 from blocked cloud egress networks.
  3. Missing SMTP AUTH on submission ports.
  4. Mixing provider hostnames and port policies.

Troubleshooting map

SymptomLikely causeFirst check
Timeout on connectEgress or firewall blockOutbound network policy and host reachability
TLS handshake failureWrong TLS modePort + TLS mode pairing
auth errorCredential/auth mismatchUsername/password and auth method
rejectPolicy or sender issueSender identity, domain auth, recipient policy
  • Standardize on unless provider docs require otherwise.
  • Keep as explicit exception path.
  • Do not use for application submission in CI or production.
  • Document one approved port policy per environment.

Validation checklist before release

  1. Confirm host + port + TLS mode match provider docs.
  2. Validate auth credentials in staging.
  3. Send a controlled test email and inspect headers.
  4. Verify SPF/DKIM/DMARC alignment.
  5. Monitor bounces and deferrals after deployment.

Helpful routes:

Final take

SMTP ports are simple, but misconfiguration is expensive. Treat port selection as a policy decision, not an ad-hoc per-app choice.