Puerto SMTP 25 bloqueado: "Connection timed out" en AWS, Azure, GCP o VPS

Qué significa

Para entregar un email, tu servidor se conecta al servidor de correo del destinatario por el puerto 25. Si esa conexión nunca obtiene respuesta, probablemente tu red o tu proveedor de hosting está bloqueando el puerto 25 saliente. Los mensajes se quedan en la cola y acaban devueltos al cabo de varios días.

El error suele tener este aspecto, según el software:

connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection timed out
Error: connect ETIMEDOUT 203.0.113.50:25
SMTP ERROR: Failed to connect to server: Connection timed out (110)

"Timed out" (ninguna respuesta) apunta a un bloqueo. "Connection refused" o una respuesta 5xx es otro problema, en el otro extremo.

Por qué ocurre

A los spammers les gusta alquilar servidores baratos, así que la mayoría de los proveedores bloquean por defecto el puerto 25 saliente. Las políticas cambian, así que consulta la documentación actual de tu proveedor. En el momento de escribir esto:

• Amazon EC2 y Lightsail restringen por defecto el puerto 25 saliente. Puedes pedir a AWS que quite el límite con su formulario de solicitud, explicando tu uso. La alternativa es Amazon SES por el puerto 587 o 465.
• Google Cloud (Compute Engine) bloquea las conexiones salientes al puerto 25 de direcciones externas. Google recomienda un servicio de correo por otro puerto.
• Microsoft Azure bloquea el puerto 25 saliente en la mayoría de los tipos de suscripción; solo algunos contratos empresariales pueden enviar directamente. Microsoft recomienda un relay autenticado.
• DigitalOcean bloquea SMTP en los Droplets por defecto; según usuarios de la comunidad, el bloqueo puede incluir los puertos 465 y 587.
• Las conexiones a internet domésticas y de oficina también suelen bloquear el puerto 25. Además, las IP residenciales están en listas de bloqueo, así que enviar directamente desde casa casi nunca funciona.

Cómo comprobarlo

Desde el propio servidor, prueba el puerto 25 hacia un gran servidor de correo y luego un puerto de envío (submission):

nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.gmail.com 587

Si el 587 conecta y el 25 se agota, el bloqueo está en tu red o en tu proveedor, no en Google. Revisa también tu propio cortafuegos (ufw status, iptables -L OUTPUT) y las reglas de salida de tu cortafuegos cloud o grupo de seguridad.

En Postfix, postqueue -p lista los mensajes atascados con el motivo. Cuando tengas una ruta que funcione, envía una prueba a la dirección única de la página de inicio de Delivmail para comprobar todo el camino.

Cómo solucionarlo

Opción 1: pedir al proveedor que desbloquee el puerto 25

Algunos proveedores (AWS, por ejemplo) aceptan la solicitud. Normalmente tienes que explicar qué envías, configurar un nombre de DNS inverso y mantener pocas quejas. Antes de hacerlo, lee la lista de comprobación para tu propio servidor de correo: una IP cloud nueva no tiene reputación.

Opción 2: usar un relay a través de un servicio de correo por el puerto 587

Es la solución habitual. Tu servidor envía a un servicio de email (tu proveedor de buzón o un servicio transaccional) por el puerto 587 con usuario y contraseña, y ese servicio entrega por el puerto 25 desde sus propias IP con buena reputación. Muchos servicios también aceptan el puerto 2525 o una API HTTP si el 587 también está bloqueado. Ejemplo de Postfix, en main.cf:

relayhost = [smtp.your-provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Y en /etc/postfix/sasl_passwd:

[smtp.your-provider.com]:587   username:password

chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
systemctl reload postfix

En una aplicación (nodemailer, PHPMailer…), usa el host del servicio con port: 587 y STARTTLS en lugar de una conexión directa.

Después, autentica el relay

El relay envía desde IP nuevas, así que añádelo al SPF y activa su firma DKIM para tu dominio; consulta autenticar tu dominio en las herramientas de envío. Si no, obtendrás un SPF fail: servidor no autorizado.

Comprueba que está solucionado

Vacía la cola (postqueue -f) y vigila el registro: deberías ver status=sent con tu host de relay. Haz una nueva prueba en Delivmail y confirma que SPF, DKIM y DMARC pasan para el relay; después reenvía a la dirección que falló.