Enviar correo desde un hosting que bloquea SMTP saliente
Un sistema que confirma una compra, avisa un resultado de sorteo o
recupera una contraseña necesita enviar correo de verdad, no una
promesa de "ya debería haber llegado". El primer intento casi siempre
es el mismo: configurar Gmail, Resend o SendGrid por SMTP con
nodemailer y seguir con lo demás. En un hosting compartido,
ese primer intento puede fallar en silencio durante días antes de que
alguien note que ningún correo salió.
El problema: los puertos SMTP salientes bloqueados
Muchos proveedores de hosting compartido bloquean por completo el
tráfico saliente en los puertos 587 y 465 —los que usa
SMTP con TLS— como medida general contra spam desde cuentas
comprometidas. La política es razonable a nivel de proveedor, pero
tumba por igual a Gmail, Resend, SendGrid y Brevo si tu aplicación
intenta conectarse directo a sus servidores SMTP. Y la falla no siempre
es ruidosa: dependiendo de la librería, un error de conexión SMTP puede
quedar atrapado en un try/catch genérico y no llegar a
ningún log visible.
La salida: la API HTTPS del proveedor, no su SMTP
Casi todos los proveedores serios de correo transaccional —Resend y Brevo entre ellos— ofrecen una API sobre HTTPS además del SMTP tradicional. El puerto 443 casi nunca está bloqueado en un hosting compartido, porque bloquearlo rompería cualquier llamada saliente a cualquier servicio externo, no solo correo. Cambiar de "conectarse por SMTP" a "hacer un POST a la API del proveedor" resuelve el bloqueo sin negociar nada con el hosting ni pagar por un plan superior.
La alternativa local: el sendmail del propio cPanel
Cuando el volumen de correo es bajo y no quieres depender de un
proveedor externo, la mayoría de cPanel trae su propio servicio de
correo funcionando en localhost, con SMTP normalmente
abierto en el puerto 25 y a veces también en el 587 solo para
conexiones locales. Es una opción válida para avisos internos o
volumen bajo, aunque entrega peor —sin la reputación de dominio que
trae un proveedor especializado, es más fácil que el correo termine en
spam del lado del destinatario.
Cómo detectarlo antes de que sea un problema en producción
La forma más simple de no descubrir este bloqueo el día del lanzamiento es probarlo apenas se aprovisiona el hosting: un intento de conexión SMTP directa a un puerto 587 externo desde una terminal en el propio servidor, antes de escribir una sola línea de código de envío de correo. Si el puerto no responde, ya sabes desde el primer día que el sistema va a necesitar la vía de API HTTPS, y lo diseñas así desde el principio en vez de descubrirlo con un cliente esperando la confirmación de su compra que nunca llegó.