El protocolo SMTP transporta tus emails desde un cliente o una aplicación hasta el servidor del destinatario, y cada conexión pasa por un puerto concreto. Para el envío desde un cliente de correo o un script, usa el puerto 587 con STARTTLS por defecto. El puerto 465 funciona en TLS implícito y sigue siendo una alternativa igual de válida. El puerto 25 sirve para la transferencia entre servidores y está bloqueado en la mayoría de proveedores de acceso y hostings cloud. El puerto 2525 saca del apuro cuando 587 está filtrado por una red externa. Comprobar cuál es el puerto correcto toma menos de 2 minutos con un solo comando.
Los 4 puertos SMTP y su uso real
Cada puerto corresponde a un rol concreto en la cadena de envío, fijado por las normas del protocolo. El puerto 25 es el puerto histórico del protocolo, reservado a la transferencia de servidor a servidor (MTA a MTA): un servidor de correo que reenvía un mensaje a otro servidor pasa por ahí, nunca un cliente de correo o una aplicación que envía un email. El puerto 587 se estandarizó en 2007 (RFC 4409, reemplazada desde entonces por la RFC 6409) específicamente para el envío autenticado, con cifrado activado tras la conexión mediante el comando STARTTLS. El puerto 465 tiene una historia más agitada. Asignado en los años 90 para SMTP sobre SSL, se consideró obsoleto durante casi 20 años en favor del 587, y después fue rehabilitado oficialmente. La RFC 8314, publicada por el IETF en enero de 2018, reincorpora el puerto 465 como puerto oficial de envío en TLS implícito y lo presenta como la dirección técnica recomendada a largo plazo, por delante del 587.
La RFC 8314 califica el uso de texto plano para el envío y el acceso a los mensajes como algo obsoleto, y recomienda cifrar desde la apertura de la conexión en lugar de activarlo durante el intercambio (IETF, enero de 2018).
El puerto 2525 no forma parte de ninguna estandarización del IETF. Sirve de respaldo cuando una red filtra el 587 y el 25, y la mayoría de routers de email comerciales lo soportan, aunque este puerto no está garantizado en todos los proveedores.
STARTTLS o TLS implícito: la diferencia concreta
STARTTLS abre la conexión en texto plano y después el cliente envía el comando STARTTLS para pasar a un canal cifrado antes de intercambiar credenciales y contenido del mensaje. El TLS implícito cifra desde el primer saludo TCP: ningún dato circula en claro, ni siquiera durante la negociación. La RFC 8314 justifica esta elección por el riesgo de interceptación durante la breve ventana en claro que precede al comando STARTTLS, una ventana que un interceptor activo en la red puede aprovechar para forzar una conexión sin cifrar. Un cliente mal configurado puede enviar una contraseña SMTP sin protección si el servidor no rechaza los intentos sin STARTTLS. Eso es todo lo que distingue a los dos mecanismos desde el punto de vista de la seguridad de la conexión.
Por qué el puerto 25 está bloqueado en salida
El bloqueo es intencionado: responde a una política contra el spam saliente. Los proveedores de acceso domésticos filtran las conexiones salientes en el 25 en sus routers para impedir que las máquinas comprometidas de su red reenvíen spam directamente a Internet. El razonamiento es idéntico en el lado cloud: según la documentación oficial de AWS, el tráfico saliente por el puerto 25 está bloqueado por defecto en todas las instancias EC2 y funciones Lambda, salvo solicitud explícita de desbloqueo validada mediante un ticket de soporte. Varios proveedores de hosting compartido aplican una restricción parecida en parte de su catálogo. El fallo es sistemático. Una aplicación alojada en un VPS o en una conexión doméstica que intenta enviar directamente por el puerto 25 falla sin importar la calidad de su configuración DNS o de su contenido. La solución no es esquivar este bloqueo, sino enviar el mensaje por el 587 o el 465, puertos que esas mismas redes dejan abiertos.
Qué puerto usar según tu proveedor
La siguiente tabla solo enumera los puertos aceptados para el envío. Para la dirección exacta del servidor de tu proveedor, consulta nuestra guía para encontrar el servidor SMTP de tu correo.
| Proveedor | Puertos aceptados | Observación |
|---|---|---|
| Gmail | 587, 465 | 587 recomendado por Google, autenticación obligatoria en ambos |
| Outlook / Microsoft 365 | 587 | 465 no soportado por el relay SMTP de Microsoft 365 |
| Yahoo | 587, 465 | La autenticación en 2 pasos exige una contraseña de aplicación |
| Movistar | 465 | Único puerto oficialmente recomendado para su servidor de correo; el 587 solo está disponible en el servicio empresarial, distinto de la cuenta particular |
| Vodafone | 465 | 587 no siempre disponible según el plan |
| Orange España | 465, 587 | 465 recomendado en primer lugar, 587 como respaldo si la red bloquea el SSL directo |
| MásMóvil | 587, 465 | 587 con STARTTLS funciona especialmente en iOS, 465 con SSL como alternativa |
| OVHcloud | 465, 587 | 465 en SSL directo, 587 con STARTTLS según el plan de correo |
| Ionos | 587, 465 | 587 con STARTTLS recomendado en primer lugar por el proveedor |
Comprobar si un puerto SMTP está abierto
Dos comandos bastan para verificar que un puerto responde antes de modificar una configuración a ciegas. Con OpenSSL instalado, ejecuta openssl s_client -connect smtp.ejemplo.com:587 -starttls smtp desde una terminal. Una respuesta que empiece por 220 seguida del nombre del servidor confirma que el puerto escucha y acepta la negociación STARTTLS. Sin OpenSSL, telnet sirve para una prueba básica: telnet smtp.ejemplo.com 587. Una salida que muestre 220 mail.ejemplo.com ESMTP ready significa que la conexión TCP se establece. Si la consola queda vacía varios segundos y después se cierra, el puerto está filtrado en algún punto entre tu máquina y el servidor, a menudo por un firewall local o un router doméstico. Esta prueba toma menos de 2 minutos y evita adivinar a ciegas qué elemento de la cadena bloquea realmente el envío.
Entender los errores de conexión SMTP
Tres mensajes aparecen con más frecuencia cuando un envío falla, y cada uno apunta a una causa distinta.
- Connection timed out: la conexión TCP nunca se completa. El puerto está bloqueado por un firewall, un router doméstico o una regla de seguridad cloud antes incluso de llegar al servidor de correo. Prueba otro puerto (587 si falla el 25, 2525 si también falla el 587) en lugar de modificar las credenciales.
- Connection refused: la máquina destino responde, pero nada escucha en ese puerto concreto. El servidor SMTP existe, pero el servicio no está configurado en ese número de puerto o corre en otra interfaz de red. Comprueba el puerto realmente abierto con el comando openssl visto antes de cambiar la configuración del cliente.
- Must issue a STARTTLS command first: el servidor exige cifrado y el cliente intenta enviar credenciales en claro. El parámetro que hay que corregir es la seguridad del lado cliente, STARTTLS en el 587 o SSL/TLS en el 465. El número de puerto sigue siendo correcto.
Un error de tiempo de espera o de rechazo casi siempre apunta al puerto o al firewall, nunca al contenido del email. Uno que mencione la autenticación o el cifrado apunta al parámetro de seguridad de la conexión, sea cual sea el puerto usado. Esta distinción evita reconfigurar SPF, DKIM, DMARC o el contenido del mensaje cuando el problema está una capa por debajo, a nivel de transporte.
Si tu propio servidor sigue filtrado pese a tener el puerto correctamente abierto en el lado cliente, pasar por un relay SMTP esquiva el bloqueo sin tocar tu infraestructura.
El puerto correcto abre la conexión. No garantiza nada sobre el resto del trayecto: los mensajes que salen con normalidad pero acaban en la carpeta de spam apuntan a la autenticación del dominio remitente y a la limpieza de la lista de contactos enviada.
