Cuatro puertos aparecen cada vez que una aplicación necesita enviar correo: 25, 465, 587 y 2525. Dos de ellos son estándares de envío, 587 y 465, y el consejo que más se repite sobre el 465 está desactualizado desde 2018. El puerto 25 no es para envío en absoluto, y el 2525 es una convención sin estándar que lo respalde.
La respuesta corta: usa 587 con STARTTLS. Usa 465 si tu cliente funciona mejor abriendo directamente una conexión TLS. Usa 2525 si algo en tu red bloquea el 587. No uses 25 para enviar correo desde una aplicación.
¿Qué hace realmente cada puerto?
Los puertos se diferencian en dos ejes: si están pensados para envío o para retransmisión, y en qué momento de la conexión comienza el cifrado.
- 25 es el puerto de retransmisión. Es la forma en que un servidor de correo entrega un mensaje a otro. Es anterior al envío autenticado y no presupone ninguno de los dos.
- 587 es el puerto de envío, definido para ese propósito por RFC 6409. La conexión se abre en texto plano y se actualiza a TLS con el comando
STARTTLSantes de enviar las credenciales. - 465 es el puerto de envío con TLS implícito. El handshake TLS ocurre primero y todo el diálogo SMTP transcurre dentro de él, por lo que nunca se envía nada en claro. Las bibliotecas suelen etiquetar esto como "SSL/TLS" o "SMTPS".
- 2525 no tiene ningún estándar que lo asigne a SMTP. Los proveedores lo ofrecen como alternativa al 587 en redes que bloquean el puerto estándar.
La diferencia entre 465 y 587 es cuándo comienza TLS, no cuán fuerte es. En el 465 la conexión está cifrada desde el primer byte. En el 587 se cifra un intercambio después, y un servidor correctamente configurado rechaza AUTH hasta que eso ocurra.
¿Está obsoleto el puerto 465?
No, y este es el consejo obsoleto sobre SMTP más repetido.
La historia es genuinamente confusa. El puerto 465 se asignó para SMTP sobre TLS en los primeros tiempos, luego se retiró en favor del enfoque STARTTLS en el 587, que es de donde viene el consejo de "465 is deprecated". Ese consejo fue correcto durante un período. Después RFC 8314, publicado en enero de 2018, recomendó TLS implícito para el envío de correo y restableció el 465 como el puerto para ello, bajo el nombre de servicio submissions.
Así que una página que te dice que el 465 es obsoleto describe el estado de las cosas antes de 2018. Tanto el 465 como el 587 son vigentes. Elige el que tu cliente soporte de forma más limpia, y prefiere el 465 si prefieres no depender de una actualización de texto plano a TLS.
¿Por qué está bloqueado el puerto 25 y cómo lo verifico?
El puerto 25 saliente está bloqueado por muchos ISP de consumo y por proveedores de cloud y hosting, porque un puerto de retransmisión sin autenticación en una máquina comprometida es la vía por la que se envía spam masivo. Si el bloqueo se puede levantar depende de quién lo estableció. Un ISP de consumo generalmente no lo levanta para una línea residencial, mientras que los proveedores de cloud varían: algunos aceptan una solicitud de eliminación, y al menos uno no ofrece excepción alguna. Consulta la política que publica tu propio proveedor en lugar de suponer en un sentido u otro.
Puedes confirmar un bloqueo abriendo una conexión a un servidor de correo conocido en el puerto 25 y comprobando si recibes un saludo 220 o un timeout. Una sesión manual es la forma más clara de verlo, y comprobar una conexión SMTP con una sesión telnet te guía paso a paso.
Si el puerto 25 está bloqueado, ese no es el problema que hay que resolver. Una aplicación debería enviar por el 587 o el 465 de todas formas.
¿Cuál es la diferencia entre envío y retransmisión?
El envío es un cliente de correo o una aplicación entregando un mensaje nuevo a un servidor en el que se ha autenticado. La retransmisión es un servidor pasando un mensaje existente hacia su destino.
La diferencia determina qué puerto y qué reglas aplican. El envío requiere autenticación, permite al servidor corregir y firmar el mensaje antes de salir, y ocurre en el 587 o el 465. La retransmisión ocurre en el 25, entre servidores, y es lo que evalúan los sistemas de spam y reputación del lado receptor.
Una aplicación que envía su propio correo siempre está haciendo envío. Si estás configurando algo y optas por el puerto 25, la configuración describe la mitad equivocada del sistema.
¿Qué puertos acepta Bird?
Tres, y el puerto 25 no está entre ellos a propósito:
| Puerto | Cifrado |
|---|---|
| 465 | TLS implícito (SMTPS) |
| 587 | STARTTLS |
| 2525 | STARTTLS |
En el 587 y el 2525, AUTH se rechaza hasta que STARTTLS se haya ejecutado, por lo que las credenciales nunca viajan en claro en ninguno de los tres. El puerto 25 no se ofrece para envío.
El host depende de la región de tu clave, que es el prefijo en la propia clave: una clave bk_eu1_... envía a través de eu1.smtp.bird.com, una clave bk_us1_... a través de us1.smtp.bird.com. La autenticación usa tu clave API habitual en lugar de una credencial SMTP separada: el nombre de usuario es la cadena literal bird y la contraseña es la clave.
El correo enviado por SMTP se trata exactamente igual que el correo enviado a través de la API de email API, con la misma verificación de dominio, firma DKIM, gestión de supresiones, seguimiento y eventos. Enviar email por SMTP contiene la referencia completa de conexión, dos sesiones anotadas, una en el 465 y otra compartida por el 587 y el 2525, y los valores por defecto de cada clave que configuran un envío.
¿Cómo encuentro el puerto que usa mi cliente?
Dónde mirar depende del software, pero el patrón es consistente:
- Los frameworks de aplicación lo colocan en la configuración de correo, normalmente junto al host, como un ajuste
portoMAIL_PORT. - Los sistemas de gestión de contenidos lo exponen en la página de ajustes de un plugin SMTP junto a un desplegable de cifrado. Ese desplegable es el ajuste que la gente configura mal: "SSL/TLS" significa 465 y "STARTTLS" significa 587 o 2525, y si los combinas mal produces una conexión que se cuelga o se rechaza en lugar de un error útil.
- Los dispositivos como impresoras y escáneres lo guardan en una pantalla de notificaciones o de escaneo a email.
Si el correo falla y sospechas del puerto, prueba la conexión directamente antes de cambiar el código de la aplicación. Una sesión manual te dice si el puerto es accesible, si TLS negocia correctamente y si la autenticación es aceptada, lo que separa un bloqueo de red de un problema de credenciales.
En resumen
Usa 587 con STARTTLS salvo que tengas una razón para no hacerlo.
Es el puerto de envío definido por RFC 6409, y todos los clientes y bibliotecas principales lo soportan.
El puerto 465 no está obsoleto.
Se retiró para SMTP sobre TLS en su momento, pero RFC 8314 lo reinstauró en 2018 como el puerto recomendado de envío con TLS implícito. Los consejos que lo llaman obsoleto son anteriores a eso.
El puerto 25 es para retransmisión entre servidores.
Los proveedores de hosting y los ISP de consumo bloquean el puerto 25 saliente para limitar el spam, y no es el puerto en el que una aplicación debería enviar.
El puerto 2525 es una alternativa sin estándar que lo respalde.
Ningún RFC lo asigna a SMTP. Los proveedores lo ofrecen porque algunas redes bloquean el 587, y por lo demás se comporta igual que el 587.