iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Cuando una aplicación que corre en Kubernetes no logra enviar correo, el fallo suele estar en un tramo concreto del recorrido: el pod, la resolución DNS, la conexión TCP de salida, la negociación TLS o la autenticación y autorización en el servicio SMTP. La forma más rápida de localizarlo es recorrer esos tramos en ese orden y detenerse en el primero que falla, antes de cambiar configuración o escalar al equipo de red o al proveedor.
Separa primero los problemas de aplicación de los del clúster
La documentación oficial de Kubernetes trata por separado la depuración de aplicaciones y la del clúster, y pone los logs y el monitoreo como partes del proceso. Para un error de envío, eso significa que no basta con mirar el clúster: hay que revisar primero el workload (pods, reinicios, eventos, logs y configuración efectiva) y solo después la red y el proveedor.
El recorrido desde el pod hasta el servidor SMTP
Piensa el envío como cinco tramos encadenados. Cada uno tiene una evidencia característica de fallo, y el siguiente no tiene sentido comprobarlo si el anterior está roto.
| Tramo | Qué confirmar | Síntoma típico si falla |
|---|---|---|
| 1. Workload | Pod en ejecución, sin reinicios inesperados, configuración efectiva correcta | Reinicios, eventos de error, host o puerto distinto del esperado |
| 2. DNS | El hostname del relay se resuelve desde el namespace del pod | Error de resolución de nombre, o timeout antes de cualquier conexión |
| 3. TCP de salida | El pod alcanza IP y puerto del proveedor | Timeout sin banner SMTP, o rechazo de conexión |
| 4. TLS | El modo (STARTTLS o TLS implícito) coincide con el puerto | TCP conecta, pero el handshake falla o el certificado no valida |
| 5. SMTP y autorización | Usuario, token, permisos y dominio remitente aceptados | Código de respuesta SMTP de rechazo de autenticación o de remitente |
Paso 1: confirma el síntoma dentro del workload
Antes de tocar la red, fija qué ocurrió exactamente. Captura el texto literal del error SMTP y la hora en que aparece, porque los eventos de Kubernetes y los logs de la aplicación pueden tener ventanas de retención distintas.
#1 Best Overall
- Lista los pods del namespace y observa reinicios y estado:
kubectl get pods -n <namespace> - Revisa condiciones, eventos y configuración que consume el contenedor:
kubectl describe pod <pod> -n <namespace> - Lee los logs de todos los contenedores del pod:
kubectl logs <pod> -n <namespace> --all-containers - Ordena los eventos por tiempo para alinearlos con el error:
kubectl get events -n <namespace> --sort-by=.lastTimestamp - Clasifica el error en una de estas categorías: timeout, rechazo TCP, fallo de handshake TLS o respuesta SMTP. Cada categoría apunta a un tramo distinto.
Paso 2: comprueba DNS desde el mismo contexto de red
Resuelve el hostname exacto que la aplicación usa para el relay, no una versión abreviada. Kubernetes advierte que una consulta de nombre corto se limita al namespace del pod: si el relay vive en otro namespace, el nombre debe incluir el namespace explícitamente (por ejemplo, <servicio>.<namespace>).
Para la prueba, usa una herramienta que ya tenga la imagen del contenedor, como getent hosts o nslookup. Si ninguna está disponible, un pod de diagnóstico autorizado en el mismo namespace sirve igual.
kubectl exec -n <namespace> <pod> -- getent hosts <hostname-del-relay>Si la resolución falla, revisa el componente de DNS del clúster:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rank #2
kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns
kubectl get svc,endpoints -n kube-system kube-dnsSi CoreDNS está sano y el Service kube-dns tiene endpoints, el problema suele estar en el nombre configurado o en una política de red que bloquea el DNS, no en el proveedor de correo.
Paso 3: comprueba la conexión TCP de salida
Esta es la comprobación que más fallos mal atribuidos evita. Un timeout antes de recibir el banner SMTP apunta a conectividad o filtrado, y no a credenciales. AWS documenta por separado el diagnóstico de conexión TCP y el de negociación TLS, y SES recomienda confirmar primero TCP y después TLS.
Qué revisar cuando hay timeout
- NetworkPolicy y CNI: una política de egress del namespace puede bloquear el puerto sin que el pod lo note en sus logs.
- Firewall de egress y rutas: revisa reglas del nodo, del proveedor cloud y, si aplica, NAT o proxy de salida.
- Destino y puerto: confirma que el puerto configurado coincide con el que el proveedor documenta para ese servicio.
No presentes el puerto 25 como universal
No hay una regla común para el tráfico SMTP saliente. Google Cloud bloquea por defecto el egress a TCP 25 hacia direcciones externas en ciertos proyectos, pero excluye de ese bloqueo el SMTP con TLS en los puertos 465 y 587. AWS documenta límites por defecto de puerto 25 para instancias EC2. Si tu clúster corre en un proveedor cloud, la pregunta correcta es qué política aplica a tu proyecto, cuenta y destino, y no si el puerto 25 “funciona”.
Prueba TCP sin mezclarla con credenciales
Desde el pod, comprueba si el puerto abre antes de intentar autenticarte. Si la herramienta de red no está en la imagen, la comprobación se hace con openssl en un pod de diagnóstico:
openssl s_client -connect <host-del-relay>:465
openssl s_client -starttls smtp -connect <host-del-relay>:587 -crlfLa primera sirve para TLS desde el inicio (implícito); la segunda, para STARTTLS. Si el comando conecta y muestra un banner SMTP, la capa de red queda descartada para ese puerto.
Paso 4: valida el modo TLS del puerto
Hay dos modos habituales, y usar el modo equivocado para un puerto produce un fallo de handshake aunque la conexión TCP sea correcta:
- STARTTLS: la sesión empieza en texto plano y se actualiza a TLS con el comando STARTTLS.
- TLS Wrapper o implícito: la conexión negocia TLS desde el primer byte.
AWS SES documenta STARTTLS en los puertos habilitados para ese modo y TLS Wrapper en 465 y 2465. Los puertos y detalles son específicos de ese servicio, así que confírmalos en la documentación de tu proveedor. Si TCP conecta pero el handshake falla, compara en este orden: modo, puerto, hostname frente al certificado y configuración de la librería de correo de la aplicación.
Paso 5: interpreta la respuesta de autenticación y de remitente
Solo cuando la sesión llega a SMTP y TLS se negocia tiene sentido revisar credenciales y autorización. Las causas típicas son usuario o contraseña incorrectos, token caducado o revocado, permisos insuficientes y un dominio remitente que el proveedor no ha dado de alta. Los códigos de respuesta y sus causas dependen del servicio, así que no los trasladas de un relay a otro sin comprobarlo.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
| Proveedor o servicio | Puerto y modo documentados | Política de egress o límites por defecto | Respuestas SMTP documentadas |
|---|---|---|---|
| Google Cloud | SMTP con TLS en 465 y 587 excluido del bloqueo de TCP 25 (según la documentación citada) | Bloqueo por defecto de egress a TCP 25 externo en ciertos proyectos | Not stated en la documentación revisada |
| AWS EC2 | Not stated para el modo TLS en esta comparación | Límites por defecto de puerto 25 para instancias EC2 | Not stated en la documentación revisada |
| AWS SES | STARTTLS en los puertos habilitados para ese modo; TLS Wrapper en 465 y 2465 | Not stated en la documentación revisada | Not stated en la documentación revisada |
| Cloudflare Email Sending | Not stated en la documentación revisada | Not stated en la documentación revisada | 535 para fallos de autenticación (usuario, permiso o estado del token); 550 para un dominio remitente no incorporado al servicio |
Usa la tabla como mapa de preguntas, no como lista de valores universales. Si tu relay no aparece, las preguntas son las mismas: qué puerto y modo admite, qué política de egress aplica tu proveedor, qué autenticación exige, qué requisitos hay para habilitar el dominio remitente y dónde se observan los errores.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Por qué no conviene que un fallo de SMTP reinicie el pod
Kubernetes distingue tres sondas: startup, readiness y liveness. La readiness decide si un pod recibe tráfico de un Service, y la liveness puede provocar el reinicio del contenedor. La documentación resume el mecanismo así: “Based on the probe results, Kubernetes can restart unhealthy containers or stop sending traffic to containers that are not ready.”
Esa frase describe la función general de las sondas y no diagnostica por sí sola un error de correo. Como inferencia editorial a partir de esa función, una liveness que dependa de un SMTP externo intermitente puede reiniciar pods sanos y empeorar la disponibilidad de la aplicación. Si quieres vigilar el relay, lo más prudente es hacerlo con métricas y alertas, no con una liveness que falle por una dependencia externa.
Observabilidad: métricas y alertas para envíos
Kubernetes expone métricas de sus componentes en formato Prometheus. Prometheus Operator indica que los recursos de monitoreo inválidos pueden generar Events, y que un ServiceMonitor depende de sus selectores y de una referencia correcta al Service y al puerto. Si un ServiceMonitor no encuentra su objetivo, las métricas de la aplicación simplemente no aparecen; revisa los Events del namespace antes de asumir que el envío funciona.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Para el correo, la práctica razonable es graficar errores y latencia de envío y alertar por acumulación de fallos sostenida, no por un fallo puntual. Esto requiere que la aplicación exponga métricas de envío; no todas las librerías ni frameworks lo hacen por defecto, así que confirma qué expone tu aplicación antes de diseñar el panel.
Límites de esta guía
La documentación de Kubernetes citada corresponde a la versión 1.32 y su versión de guía de DNS muestra última modificación el 22 de mayo de 2024; compara los comandos y las rutas de configuración con la versión que tienes instalada. Las guías de los proveedores cambian con frecuencia en puertos, restricciones y requisitos de cuenta, así que valida la política de red y el modo SMTP en la documentación vigente antes de aplicar cambios en producción.
Esta guía no compara precios, cuotas ni disponibilidad regional de los servicios de correo, porque las fuentes consultadas no permiten esa comparación.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →
