¿Puedes responder lo siguiente:
¡Hola @Kalon! ¡Bienvenido!
Como n8n Cloud utiliza direcciones IP dinámicas para el tráfico de salida, si tu proveedor SMTP externo está bloqueando las conexiones, puedes intentar añadir a la lista blanca los rangos de direcciones IP de salida de n8n Cloud.
Creo que esa es la causa más probable.
Sí, este es el comportamiento esperado en n8n Cloud en lugar de algo roto de tu lado. Cloud bloquea SMTP crudo saliente en los puertos 25, 465 y 587 en todos los niveles, por lo que el nodo Send Email simplemente se queda esperando hasta que la conexión agota el tiempo de espera, por eso obtienes un bloqueo sin nada útil en el registro. Las otras respuestas son correctas en que la solución es dejar de usar SMTP crudo y enviar a través de una API en su lugar. Los nodos Gmail o Microsoft Outlook funcionan porque van a través de la API del proveedor en https, no SMTP, y para cualquier cosa transaccional un proveedor como Resend, SendGrid o Mailgun a través del nodo HTTP Request (o su nodo dedicado) es el camino limpio. Si realmente necesitas SMTP crudo, el alojamiento propio es el único lugar donde controlas los puertos salientes.
Una cosa que vale la pena resolver mientras cambias esto, ya que ya notaste que falla silenciosamente: el correo electrónico sigue siendo un fallo silencioso incluso después de que cambies. Una llamada de API puede volver aceptada y el nodo se pone verde, pero el mensaje aún nunca llega porque el dominio de envío no está verificado, o se archiva como spam, o el proveedor suprimió esa dirección. Así que una vez que esté conectado, envía un mensaje real a una bandeja de entrada que controles y verifica los registros de entrega del proveedor, no solo que el nodo haya terminado en verde. ¿Estás enviando correo transaccional como restablecimientos y recibos, o más bien una notificación para ti mismo? Eso cambia cuál es la ruta menos problemática.
@Kalon no deberíamos bloquear los puertos SMTP salientes, sospecho que el servicio de correo está bloqueando la conexión en lugar de que esto sea por el lado de la nube. Podría ser la configuración de SSL/TLS.
Bienvenido, Kalon 
En tus tres puntos:
n8n Cloud no documenta públicamente el bloqueo o limitación de velocidad del SMTP saliente en los puertos 465/587, y funciona perfectamente para muchos usuarios de Cloud — así que un bloqueo real de puerto es poco probable. Un cuelgue silencioso casi siempre es o bien una discordancia de puerto/SSL (465 necesita SSL/TLS ACTIVADO; 587 lo necesita DESACTIVADO para STARTTLS — si lo confundes, la conexión simplemente se queda ahí hasta que expire el tiempo) o el proveedor rechazándote (Gmail/Outlook normalmente requieren una contraseña de aplicación, y bloquean IPs de envío desconocidas). No puedo hablar sobre los límites de infraestructura interna de n8n — si sospechas un bloqueo real, el soporte puede confirmarlo.
No tengo conocimiento de restricciones SMTP específicas por nivel — el comportamiento es el mismo en todas las cuentas de Cloud que yo sepa.
La solución confiable en Cloud: salta el SMTP directo y envía a través de una API de correo transaccional sobre HTTPS — SendGrid, Brevo, Postmark, Resend o Mailgun (su nodo o el nodo HTTP Request). Eso evita completamente el dolor de puerto/TLS, proporciona mejor entregabilidad y simplemente funciona en Cloud. Si quieres quedarte con SMTP: prueba 587 con SSL desactivado, usa una contraseña de aplicación y abre la ejecución fallida — el error real (autenticación vs TLS vs tiempo de espera) normalmente está ahí incluso cuando parece silencioso.