¿Qué puerto SMTP debería usar una aplicación para el correo?

Un puerto SMTP selecciona una función del protocolo y un modo de conexión

Un número de puerto no es simplemente una puerta intercambiable hacia el mismo servicio. Ayuda a identificar qué función SMTP ofrece el servidor y cómo empieza la conexión. El envío de mensajes (submission) es la primera entrega desde una aplicación o un agente de usuario a un servicio de envío. El relay es la transferencia de correo entre servidores de correo. Los estándares separan estas funciones porque el envío puede requerir autenticación, autorización del remitente y comprobaciones de la política de mensajes que no se aplican del mismo modo al relay público de correo. El puerto también puede indicar si el cliente empieza con comandos SMTP y luego se actualiza con STARTTLS o si empieza de inmediato con un handshake TLS. Trate el nombre de host, el puerto, el modo TLS y las instrucciones de autenticación del proveedor como una única configuración conjunta. Copiar un puerto de un proveedor distinto, o cambiar solo el puerto después de un error, puede convertir un problema de red en un fallo de TLS o de autenticación sin corregir la causa original.

El puerto 25 es principalmente para el relay entre servidores de correo

El puerto 25 es el puerto convencional de relay SMTP que se usa cuando un Message Transfer Agent entrega correo a otro. RFC 6409 mantiene el relay en el puerto 25 y separa el envío de mensajes nuevos al puerto 587. Por lo tanto, una aplicación no debería suponer que las conexiones directas a los servidores de correo de los destinatarios en el puerto 25 son la forma normal de enviar el correo de un producto. El relay directo requiere colas, enrutamiento DNS, gestión de rebotes, controles contra el abuso, gestión de la reputación y un comportamiento de reintentos conforme a los estándares. Las redes y los proveedores de hosting también pueden restringir el puerto 25 saliente. AWS, por ejemplo, documenta que limita de forma predeterminada el tráfico de correo de Amazon EC2 en el puerto 25. El puerto 25 puede seguir siendo una opción documentada en un proveedor o dentro de una infraestructura controlada, pero que esté disponible no lo convierte en la opción preferida para el envío. Úselo solo cuando el servicio responsable documente explícitamente ese endpoint, el modo de seguridad y el modelo operativo.

El puerto 587 es el puerto estándar de envío de mensajes

RFC 6409 reserva el puerto 587 para el envío de mensajes y describe un servicio de envío que puede rechazar correo no autorizado, exigir autenticación y aplicar políticas antes de aceptar un mensaje nuevo. Una sesión habitual en el puerto 587 empieza como SMTP, anuncia la extensión STARTTLS después de `EHLO`, actualiza la conexión a TLS, repite `EHLO`, se autentica y luego envía el mensaje. La palabra «habitual» importa: los mecanismos y requisitos exactos de autenticación provienen de la documentación actual del proveedor y de las capacidades del servidor. Un cliente seguro debería exigir la actualización TLS esperada y validar el certificado del servidor, en lugar de continuar en texto claro después de una negociación fallida. No confunda un saludo inicial del protocolo sin cifrar con una sesión autenticada sin protección; STARTTLS está diseñado para actualizar esa conexión antes de que se envíen las credenciales y los datos del mensaje. El puerto 587 identifica el servicio de envío, mientras que la aplicación efectiva de TLS depende de una política de cliente correcta.

El puerto 465 usa TLS implícito para el envío

El puerto 465 está registrado para el envío de mensajes mediante TLS implícito. Con TLS implícito, el cliente realiza el handshake TLS en cuanto se abre la conexión TCP y envía comandos SMTP solo dentro del canal protegido. Esto difiere del puerto 587 con STARTTLS, en el que el cliente primero recibe un saludo SMTP y luego solicita la actualización. RFC 8314 recomienda TLS implícito para el envío y, a la vez, describe una transición en la que proveedores y clientes pueden admitir tanto el puerto 465 con TLS implícito como el puerto 587 con STARTTLS. La RFC señala que clientes y servidores implementados correctamente pueden ofrecer una seguridad sustancialmente equivalente con cualquiera de los dos modos cuando TLS es obligatorio. La regla práctica no es declarar un puerto como universalmente correcto. Use exactamente el endpoint y el modo que admite el proveedor. Configurar STARTTLS contra un listener de TLS implícito, o TLS implícito contra un listener STARTTLS, suele fallar antes de la autenticación.

Los puertos alternativos de cada proveedor son contratos explícitos

Algunos proveedores ofrecen puertos alternativos para sortear restricciones de red, pero esos números no son estándares SMTP universales para todos los servicios. Amazon SES documenta actualmente STARTTLS en los puertos 25, 587 y 2587, y TLS Wrapper, su término para el TLS implícito, en los puertos 465 y 2465. SES exige conexiones cifradas y publica endpoints SMTP específicos por región. Esto ilustra por qué un puerto debe tomarse de la documentación del proveedor elegido y no de una lista genérica. El puerto 2587 no significa STARTTLS en todas partes, y el puerto 2465 no identifica un servicio de TLS implícito en hosts arbitrarios. Los puertos alternativos tampoco eluden la verificación del remitente, el alcance de las credenciales, las cuotas ni la política del proveedor. Registre la URL de la fuente y la fecha de verificación junto con la configuración de producción, para que un operador pueda distinguir un ajuste intencionado del proveedor de un número mágico sin explicación copiado en una variable de entorno años atrás.

Configure a la vez el nombre de host, el puerto, TLS y la autenticación

Una configuración SMTP robusta es un conjunto: el nombre de host del proveedor, el puerto, el modo de seguridad del transporte, la política de validación de certificados, el mecanismo de autenticación, el nombre de usuario, el secreto, el tiempo de espera de conexión y la identidad de envío. El nombre de host importa porque el certificado TLS se valida contra él y porque los proveedores pueden exponer distintos endpoints regionales. El puerto y el modo TLS deben coincidir. La autenticación solo debería producirse una vez establecido el canal protegido previsto, y los secretos deberían permanecer en un gestor de secretos y no en el código fuente, los bundles del navegador, los registros ni la salida de diagnóstico. Separe las credenciales y la configuración por entorno para que una prueba local no pueda enviar por accidente a través de producción. Establezca tiempos de espera finitos para la conexión y los comandos, pero deje que una cola duradera de la aplicación controle los reintentos de los mensajes. Una opción de biblioteca llamada `secure` puede significar TLS implícito en un SDK y simplemente exigir STARTTLS en otro, así que verifique la definición de la biblioteca y pruebe el comportamiento negociado en lugar de fiarse del nombre de la opción.

Pruebe la conexión por capas sin exponer secretos

Empiece por la resolución DNS y la accesibilidad TCP desde la misma red de ejecución que la aplicación. Un tiempo de espera agotado antes de la conexión apunta al enrutamiento, al firewall, a la política de salida del proveedor, a un nombre de host equivocado o a un puerto cerrado. Después, pruebe el modo TLS esperado. Con TLS implícito, un cliente TLS debería recibir un certificado y luego un saludo SMTP. Con STARTTLS, un cliente compatible con SMTP debería recibir el saludo, emitir `EHLO`, ver que se anuncia STARTTLS, solicitar la actualización, validar el certificado y volver a emitir `EHLO` después de TLS. RFC 3207 exige que el cliente y el servidor descarten la información obtenida antes del handshake, y por eso importa el segundo `EHLO`. Solo entonces pruebe la autenticación con una cuenta controlada. Oculte los nombres de usuario, los tokens, las direcciones de los destinatarios, las transcripciones completas del servidor y el contenido de los mensajes antes de compartir registros. Una prueba de conectividad no necesita un envío de producción ni la dirección de un cliente real.

Clasifique los fallos según la etapa que realmente falló

Una conexión rechazada significa que el destino TCP declinó activamente la conexión; un tiempo de espera agotado significa que no llegó ninguna respuesta útil dentro del límite. Un error en el handshake TLS apunta a una discrepancia de modo, un problema de certificado, una incompatibilidad de protocolo, una interceptación o un endpoint equivocado. Un error de autenticación se produce más tarde y debería investigarse como un problema de configuración de credenciales, mecanismo, cuenta o autorización, no corregirse con cambios de puerto al azar. Los códigos de respuesta SMTP durante `MAIL FROM`, `RCPT TO` o `DATA` describen decisiones todavía posteriores sobre la política y el mensaje. Conserve la etapa, la marca de tiempo, el endpoint, el número de intentos, la respuesta numérica y una respuesta filtrada por privacidad. Una respuesta SMTP 4xx normalmente es transitoria y una 5xx normalmente es permanente para el comando intentado, pero los reintentos deben estar acotados y tener en cuenta a cada destinatario. Si el proveedor aceptó los datos del mensaje, no envíe a ciegas un duplicado porque una solicitud posterior de la aplicación haya agotado el tiempo de espera; concilie usando el identificador del proveedor y el historial de eventos.

Que el puerto funcione no significa entrega del mensaje ni llegada a la bandeja de entrada

Una conexión TCP exitosa solo demuestra que respondió un listener. Un handshake TLS exitoso demuestra una conexión protegida con el endpoint autenticado cuando la validación del certificado es correcta. La autenticación demuestra que el servidor aceptó la identidad de cliente presentada para esa sesión. Una respuesta SMTP `250` después de los datos del mensaje significa que el servidor que responde asumió la responsabilidad según el protocolo, no que una persona recibiera o leyera el mensaje. Un relay posterior puede fallar igualmente, y un sistema receptor puede aceptar el correo y clasificarlo fuera de la bandeja de entrada principal. Mantenga estos estados separados en los registros de la aplicación y en el monitoreo. La disponibilidad de la red, la negociación TLS, la autenticación, la aceptación por el proveedor, la aceptación por el servidor de destino, el rebote, la queja y la interacción son observaciones distintas. Esta separación evita que una prueba de puerto se presente erróneamente como una prueba de entrega y evita que un mensaje aceptado se reintente solo porque no se puede demostrar su llegada a la bandeja de entrada.

Elija de forma deliberada entre el envío SMTP y una API de correo

Use el envío SMTP cuando un sistema ya tenga un cliente SMTP maduro, cuando una plataforma requerida exponga SMTP como integración admitida o cuando sean específicamente necesarios controles de nivel de protocolo. Una API de correo electrónico HTTPS puede ser un mejor límite de aplicación cuando las solicitudes estructuradas, los tokens con alcance limitado, la idempotencia, los recursos por lotes y los registros de eventos legibles por máquina se ajustan a la carga de trabajo. El proveedor aún puede usar SMTP posteriormente para llegar a los sistemas de correo de los destinatarios, por lo que una API no elimina el transporte de correo. Traslada la responsabilidad del puerto, TLS, autenticación y reintentos para la transferencia hacia el proveedor fuera de la configuración SMTP de la aplicación.

Preguntas frecuentes

Fuentes

• RFC 6409: envío de mensajes para el correo (Message Submission) — RFC Editor
• RFC 8314: El texto sin cifrar se considera obsoleto: uso de Transport Layer Security (TLS) para envío y acceso de correo — RFC Editor
• RFC 3207: extensión del servicio SMTP para SMTP seguro sobre TLS — RFC Editor
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor
• Conexión a un endpoint SMTP de Amazon SES — Amazon Web Services