La cola está subiendo. No en un pico — subiendo. Ese ascenso lento y sostenido que dice “algo está roto, pero educadamente”.
Mientras tanto los usuarios reportan “correos retrasados”, marketing está a punto de lanzar una campaña y las invitaciones del calendario del CEO llegan tarde con estilo.
Una cola de correo que crece rara vez es el problema. Es el síntoma más visible de un cuello de botella: DNS, handshakes TLS, límites remotos,
latencia del disco local, un colapso del resolvedor, un problema de reputación o un cambio de configuración bienintencionado que convirtió tu MTA en un puente de un solo carril.
Así es como encuentras al culpable antes de que el correo se detenga — y antes de que te enteres del incidente por una captura de pantalla reenviada.
Cómo crecen las colas (y por qué siguen creciendo)
Un servidor SMTP es una cinta transportadora. El correo entrante llega; se intenta el correo saliente; los fallos se difieren; los reintentos ocurren más tarde.
Cuando las entregas fallan más rápido de lo que se recuperan —o cuando no puedes intentar entregas lo suficientemente rápido— la cola crece.
Una curva de crecimiento de la cola te dice la clase de problema:
- Crecimiento lineal: estás entregando algo de correo, pero el rendimiento es inferior a la tasa de entrada. Piensa en limitación remota, concurrencia demasiado baja o lentitud del almacenamiento.
- Aumento en escalón y luego meseta: una interrupción temporal o un fallo DNS/TLS. Se acumula y luego se vacía cuando se arregla.
- Crecimiento explosivo: fallos generalizados (resolvedor caído, salida bloqueada, disco lleno), o una tormenta de correo (bucle, app mal configurada, cuenta comprometida).
- “Diferido” domina: estás intentando entregas, pero los sistemas remotos rechazan o agotan el tiempo.
- “Activo” domina: el procesamiento local está atascado—a menudo disco, bloqueos, filtrado de contenido o un proceso hijo muerto.
La mayoría de los MTAs son conservadores por diseño: no bombardearán eternamente a servidores remotos y seguirán intentando durante horas o días.
Eso es bueno para la fiabilidad. También es la razón por la que puedes terminar con 600k mensajes esperando mientras el problema subyacente persiste silenciosamente.
Aquí está la verdad operativa: tu objetivo no es “vaciar la cola”. Tu objetivo es “restaurar el rendimiento estable” para que la cola se drene de forma natural.
Si te concentras primero en borrar mensajes, borrarás evidencia y mantendrás el cuello de botella.
Guía rápida de diagnóstico
Cuando la cola crece, no tienes tiempo para una excavación arqueológica placentera. Necesitas una secuencia cerrada que separe “rechazos remotos”
de “atascos locales” y de “red/DNS/TLS” en minutos.
Primero: clasifica el retraso (diferidos vs activos, edad del más antiguo, razón dominante)
- ¿La cola es mayoritariamente diferida? Eso suele ser red/DNS/TLS/política remota.
- ¿Es mayoritariamente activa? Eso suele ser contención de recursos locales (disco, CPU, filtro de contenido) o un proceso trabado.
- ¿Cuál es la edad del mensaje más antiguo? Si tiene días, tienes un modo de fallo persistente o una programación de reintentos demasiado larga para tu negocio.
Segundo: confirma la salud local (disco, latencia I/O, agotamiento de inodos, resolvedor)
- Verifica espacio en disco y uso de inodos donde vive la cola.
- Comprueba iowait y latencia de almacenamiento; las colas de correo generan muchas escrituras de archivos pequeños.
- Valida la velocidad y corrección de resolución DNS desde el host MTA.
Tercero: confirma la ruta de salida (egress puerto 25, handshakes TLS, límites remotos)
- Prueba conectividad TCP básica a destinos conocidos en el puerto 25.
- Verifica fallos y timeouts de TLS; estos pueden serializar intentos de entrega.
- Busca patrones como “421 Try again later”, “4.7.0 rate limited” o “temporarily deferred”.
Cuarto: confirma que no eres tú el problema (bucles, ráfagas, reintentos malos)
- Identifica los remitentes y destinatarios principales en la cola. Una sola app puede envenenar el pozo.
- Busca duplicados, respuestas automáticas o bucles de rebote.
- Revisa si los archivos de la cola están cambiando constantemente (alta tasa de escritura) sin progreso de entrega.
Quinto: ajusta con seguridad (aumenta la concurrencia solo después de arreglar el cuello de botella)
Subir la concurrencia antes de arreglar DNS o disco es como añadir carriles a una autopista que termina en un puente levadizo.
Solo conseguirás más coches esperando más rápido.
Hechos interesantes y contexto histórico
- SMTP precede a la mayoría del “correo empresarial”: RFC 821 (1982) estandarizó SMTP cuando Internet todavía era en su mayoría redes de investigación.
- “Store-and-forward” es la idea central: las redes tempranas eran poco fiables, por lo que el encolamiento y los reintentos se diseñaron desde el primer día.
- Las colas de correo dependen en gran medida del sistema de archivos: los MTAs clásicos almacenan cada mensaje como uno o varios archivos; esto hace que la latencia del disco sea un factor primario.
- DNS se volvió una dependencia crítica después: los registros MX y el enrutamiento basado en DNS desplazaron la entrega desde tablas estáticas hacia un sistema dependiente del resolvedor.
- La greylisting popularizó las diferencias: a principios de los 2000, muchos servidores usaban “intenta más tarde” para reducir spam, enseñando paciencia a los MTAs.
- TLS añadió CPU y complejidad de handshake: STARTTLS mejoró la privacidad, pero introdujo nuevos modos de fallo—timeouts, incompatibilidades de cifrado, intermediarios defectuosos.
- El antispam convirtió la entrega en política: los “defer 4xx” modernos a menudo reflejan puntuación de reputación, no infraestructura rota.
- Los IDs de cola se volvieron artefactos forenses: la capacidad de rastrear un solo mensaje a través de reintentos es una de las características operativas más útiles en los MTAs.
Una cita que vale la pena mantener en una nota adhesiva cerca de tu terminal:
idea parafraseada
de Richard Cook: “El éxito hace que los sistemas parezcan simples; el fallo revela la desordenada realidad de cómo el trabajo realmente ocurre.”
Tareas prácticas: comandos, salidas, decisiones
Las tareas a continuación asumen un servidor de correo Linux. La mayoría de ejemplos usan Postfix porque es común, pero el razonamiento se traduce a Exim y Sendmail.
Cada tarea incluye: comando, salida de ejemplo, qué significa y qué decisión debes tomar a continuación.
Tarea 1: Medir tamaño de la cola y división (Postfix)
cr0x@server:~$ mailq | tail -n 20
-- 5234 Kbytes in 412 Requests.
-- 18452 Kbytes in 1923 Requests.
-- 23686 Kbytes in 2335 Requests.
Significado: Postfix imprime totales por directorio de cola cerca del final; pueden aparecer varias líneas según la configuración y los grupos de colas.
La señal clave es el conteo de requests y si está subiendo con el tiempo.
Decisión: Si los requests están aumentando, no toques la concurrencia todavía. Pasa al análisis de razones (Tarea 3) y a la salud local (Tarea 5/6).
Tarea 2: Obtener un resumen estructurado de la cola (Postfix)
cr0x@server:~$ postqueue -p | head -n 20
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5* 1487 Thu Jan 3 10:21:52 alerts@example.com
user@remote.tld
F6G7H8I9J0 9210 Thu Jan 3 10:22:01 billing@example.com
finance@remote.tld
-- 23686 Kbytes in 2335 Requests.
Significado: Un asterisco típicamente indica que el mensaje está en la cola activa (en intento). Sin asterisco suele significar diferido.
Decisión: Si ves muchos mensajes activos pero poco progreso, sospecha un cuello de botella local o procesos de entrega trabados. Ve a Tarea 8 y Tarea 9.
Tarea 3: Extraer razones dominantes de diferimiento desde los logs
cr0x@server:~$ sudo grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 20
Jan 3 10:23:10 server postfix/smtp[21944]: A1B2C3D4E5: to=<user@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=120, delays=0.2/0.1/60/59, dsn=4.4.1, status=deferred (connect to mx.remote.tld[203.0.113.7]:25: Connection timed out)
Jan 3 10:23:12 server postfix/smtp[21947]: F6G7H8I9J0: to=<finance@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=90, delays=0.2/0.1/30/59, dsn=4.7.0, status=deferred (host mx.remote.tld[203.0.113.7] said: 421 4.7.0 Try again later)
Significado: La razón está entre paréntesis. Los timeouts gritan red/egress/DNS; 421/4.7.0 suele indicar limitación de tasa o reputación.
El desglose delays= es oro: te dice dónde se gastó el tiempo (antes del gestor de cola, DNS, conexión, transmisión).
Decisión: Si la razón dominante es timeout de conexión, prueba conectividad (Tarea 11). Si es 421/4.7.0, revisa patrones de envío y limitación remota (Tarea 14).
Tarea 4: Contar diferimientos por razón rápidamente
cr0x@server:~$ sudo grep "status=deferred" /var/log/mail.log | sed -n 's/.*status=deferred (//p' | sed 's/)$//' | sort | uniq -c | sort -nr | head
842 connect to mx.remote.tld[203.0.113.7]:25: Connection timed out
311 host mx.other.tld[198.51.100.9] said: 421 4.7.0 Try again later
97 TLS is required, but our TLS engine is unavailable
52 lost connection with mx.third.tld[192.0.2.10] while receiving the initial server greeting
Significado: Este es tu mapa de calor. Si una razón domina, tienes un cuello de botella al que puedes ponerle nombre.
Decisión: Arregla la razón principal primero. Los problemas de cola suelen distribuirse según Pareto: un problema causa la mayor parte del dolor.
Tarea 5: Comprobar espacio en disco donde Postfix guarda colas
cr0x@server:~$ df -h /var/spool/postfix
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 40G 38G 1.2G 97% /
Significado: 97% usado no es “aceptable”. Las colas de correo no fallan de forma elegante cuando el sistema de archivos se queda justo: el rendimiento colapsa, la limpieza falla y corres el riesgo de una parada total.
Decisión: Libera espacio inmediatamente o mueve los spools a un sistema de archivos más grande. Luego investiga por qué el volumen se llenó (logs, correo atascado, volcados core).
Tarea 6: Comprobar agotamiento de inodos (el asesino silencioso)
cr0x@server:~$ df -i /var/spool/postfix
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda2 2621440 2619000 2440 100% /
Significado: Puedes tener bytes libres y aún así estar muerto. Un spool de correo crea muchos archivos pequeños; el agotamiento de inodos impide la creación de archivos y rompe las entregas.
Decisión: Reduce el conteo de archivos (limpia logs antiguos, rota agresivamente, vacía la cola) y planifica un sistema de archivos con más inodos (o un diseño de almacenamiento distinto).
Tarea 7: Determinar si estás limitado por I/O (iowait y latencia)
cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 01/03/2026 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
12.31 0.00 5.01 48.22 0.00 34.46
Device r/s w/s rKB/s wKB/s avgrq-sz avgqu-sz await svctm %util
sda 4.00 220.00 120.0 9800.0 86.2 9.8 44.10 3.20 72.00
Significado: Alto iowait y alto await significan que tu disco no da abasto. Las colas de correo son sensibles al comportamiento de fsync en archivos pequeños.
Decisión: Deja de tunear Postfix primero. Arregla el almacenamiento: mueve el spool a disco/SSD más rápido, reduce I/O competidor o ajusta la política de almacenamiento de la VM.
Tarea 8: Comprobar salud del servicio Postfix y saturación de procesos
cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
Active: active (running) since Thu 2026-01-03 09:01:02 UTC; 1h 22min ago
Main PID: 1021 (master)
Tasks: 68 (limit: 18945)
Memory: 212.4M
CPU: 18min 12.301s
Significado: “Active (running)” es necesario pero no suficiente. La parte importante es si los procesos hijos están trabados o se están reiniciando constantemente.
Decisión: Si la CPU está alta y la cola no se drena, verifica si un filtro de contenido o un daemon de políticas está bloqueando. Si la CPU está baja pero la cola alta, sospecha I/O o diferimientos remotos.
Tarea 9: Buscar procesos smtp atascados y tiempo de ejecución largo
cr0x@server:~$ ps -eo pid,etime,cmd | grep -E "postfix/smtp|postfix/local" | head
21944 00:10:12 postfix/smtp -t unix -u -c
21947 00:09:58 postfix/smtp -t unix -u -c
21950 00:00:03 postfix/local -t unix -u
Significado: Muchos procesos smtp con tiempo transcurrido largo sugieren colgamientos en connect/TLS o tar-pitting remoto.
Decisión: Revisa el desglose de retrasos en logs (Tarea 3) y prueba TCP/TLS desde este host (Tarea 11, Tarea 12).
Tarea 10: Verificar velocidad y corrección de resolución DNS
cr0x@server:~$ dig +tries=1 +time=2 mx remote.tld
;; ANSWER SECTION:
remote.tld. 300 IN MX 10 mx.remote.tld.
remote.tld. 300 IN MX 20 mx2.remote.tld.
;; Query time: 1789 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Jan 03 10:25:55 UTC 2026
Significado: Casi 2 segundos para una consulta MX simple es malo. Multiplícalo por miles de entregas y obtendrás una cola.
Decisión: Arregla la latencia del resolvedor: revisa systemd-resolved/unbound, DNS ascendentes, pérdida de paquetes o dominios de búsqueda mal configurados.
Tarea 11: Probar conectividad saliente al puerto 25 (no adivines)
cr0x@server:~$ nc -vz -w 3 mx.remote.tld 25
Connection to mx.remote.tld (203.0.113.7) 25 port [tcp/smtp] succeeded!
Significado: TCP funciona. Si aún ves timeouts en Postfix, sospecha pérdida de paquetes intermitente, problemas con firewalls stateful o agotamiento de concurrencia.
Decisión: Si TCP falla, escala a red: ACLs de salida, bloqueos SMTP del proveedor, agotamiento de la tabla NAT o filtrado ascendente.
Tarea 12: Probar handshake STARTTLS con un MX remoto
cr0x@server:~$ openssl s_client -starttls smtp -connect mx.remote.tld:25 -servername mx.remote.tld -brief < /dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx.remote.tld
Verification: OK
250 SMTPUTF8
Significado: El handshake TLS está sano. Si los logs de Postfix muestran fallos TLS, sospecha problemas con el bundle CA local, incompatibilidad SNI o OpenSSL antiguo.
Decisión: Si el handshake cuelga, reduce temporalmente los timeouts DNS/TLS e investiga middleboxes que rompen STARTTLS.
Tarea 13: Identificar remitentes principales en la cola (quién te está inundando)
cr0x@server:~$ postqueue -p | awk 'NR%2==1{print $7}' | sed 's/[<>]//g' | sort | uniq -c | sort -nr | head
8123 noreply@app.internal
1432 alerts@example.com
611 billing@example.com
Significado: Un remitente generando la mayor parte del correo en cola suele indicar un cambio en la aplicación, una tormenta de reintentos o credenciales comprometidas.
Decisión: Limita la tasa o bloquea temporalmente al mayor infractor, y contacta al equipo responsable. Estabiliza el rendimiento antes de “arreglar el correo”.
Tarea 14: Identificar destinos principales (quién te está rechazando)
cr0x@server:~$ postqueue -p | awk 'NR%2==0{print $1}' | sed 's/[<>]//g' | awk -F@ '{print $2}' | sort | uniq -c | sort -nr | head
9321 remote.tld
2210 other.tld
809 bigmail.example
Significado: Si un dominio domina, puedes enfocarte: comprueba la alcanzabilidad de su MX, tu reputación, sus mensajes de defer y tu tasa de envío hacia ellos.
Decisión: Aplica límites de concurrencia por destino o reduce la velocidad hacia ese dominio, en lugar de castigar a todos los demás destinos.
Tarea 15: Inspeccionar un mensaje en cola específico (Postfix)
cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,30p'
*** ENVELOPE RECORDS ***
message_size: 1487 1487
message_arrival_time: Thu Jan 3 10:21:52 2026
sender: alerts@example.com
*** MESSAGE CONTENTS ***
Received: from app.internal (app.internal [10.0.10.5])
by server with ESMTP id A1B2C3D4E5
for <user@remote.tld>; Thu, 03 Jan 2026 10:21:52 +0000 (UTC)
Subject: Alert: backend latency
Significado: Confirma remitente, destinatario y la transferencia interna. Útil para detectar bucles de correo, suplantación o un inquilino específico que causa carga.
Decisión: Si detectas un bucle (cabeceras Received repetidas), deténlo en el origen y purga los mensajes afectados.
Tarea 16: Confirmar tamaño del directorio de cola y conteo de archivos
cr0x@server:~$ sudo du -sh /var/spool/postfix/deferred /var/spool/postfix/active
3.8G /var/spool/postfix/deferred
126M /var/spool/postfix/active
cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f | wc -l
198234
Significado: Si lo diferido domina, mayormente estás esperando condiciones remotas (o DNS/TLS/egress). El conteo de archivos importa para inodos y sobrecarga en traversales de directorio.
Decisión: Si el conteo de archivos es masivo y los inodos están apretados, prioriza drenar o relocalizar el spool; luego reduce el flujo de entrada (límite de tasa) para evitar una espiral.
Tarea 17: Observar la tasa de vaciado de la cola en tiempo real
cr0x@server:~$ watch -n 5 "postqueue -p | tail -n 1"
Every 5.0s: postqueue -p | tail -n 1
-- 23686 Kbytes in 2335 Requests.
Significado: Te importa la pendiente, no un número único. Si este número no baja tras aplicar una solución, no arreglaste el cuello de botella.
Decisión: Si baja de forma constante, deja de tocar cosas. Déjala drenar. Tu trabajo es evitar empeorarla.
Tarea 18: Comprobar si te están limitando o tarpitteando servidores remotos
cr0x@server:~$ sudo grep "said: 4" /var/log/mail.log | tail -n 20
Jan 3 10:24:01 server postfix/smtp[21947]: F6G7H8I9J0: to=<finance@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=90, dsn=4.7.0, status=deferred (host mx.remote.tld[203.0.113.7] said: 421 4.7.0 Try again later)
Significado: Un 4xx es un diferimiento temporal; el lado remoto te está pidiendo explícitamente que reduzcas la velocidad o regreses más tarde.
Decisión: Reduce la concurrencia por destino y la tasa de envío; si operas correo masivo, segmenta ese tráfico a un host/IP saliente dedicado.
Chiste #1: El correo es el único sistema donde “intenta más tarde” es tanto una característica del protocolo como una estrategia de apoyo emocional.
Cuellos de botella y modos de fallo comunes
1) Cuellos de botella de disco y sistema de archivos (el clásico)
Los spools de correo son fábricas de archivos pequeños. Obtienes operaciones de metadatos, fsyncs, búsquedas en directorio y mucho “escribe un poco, renombra, unlink”.
Si tu cola está en almacenamiento de red lento, discos de VM sobrecargados o un sistema de archivos casi lleno, las entregas se ralentizarán aunque la CPU esté inactiva.
Indicadores específicos de almacenamiento:
- Alto iowait, alto
await, rendimiento moderado. - Procesos del gestor de cola bloqueados en I/O; la cola “activa” crece y se mantiene alta.
- Escrituras de logs atrasadas; las marcas de tiempo en logs saltan.
Qué hacer:
- Mover el spool a SSD local cuando sea posible.
- Mantener
/varcon espacio holgado; 20% libre no es lujo, es cordura operativa. - Dejar de colocalizar spools de correo con sistemas que generan muchos logs, staging de backups o cualquier cosa que haga escrituras secuenciales grandes.
2) Lentitud del resolvedor DNS (muerte por mil consultas)
Cada entrega saliente implica DNS: búsqueda MX, A/AAAA, a veces TLSA, a veces comprobaciones SPF/DMARC dependiendo de tu configuración.
Si tu resolvedor es lento, efectivamente serializas las entregas.
Causas típicas:
- systemd-resolved reenviando a un upstream DNS inestable.
- Firewall que descarta fragmentos o respuestas UDP (problemas EDNS).
- Dominios de búsqueda que provocan churn de NXDOMAIN repetido.
- Mal comportamiento de IPv6: consultas AAAA exitosas, pero la conectividad v6 real está rota.
3) Bloqueos de salida de red y restricciones SMTP del proveedor
Muchas redes en la nube bloquean el puerto 25 saliente por defecto. Algunos firewalls corporativos “amablemente” interceptan SMTP e hacen no-se-sabe-qué.
Síntomas: timeouts de conexión, éxitos esporádicos o “No route to host.”
La solución casi nunca es “tunear Postfix.” Es: abrir el puerto, usar el relay correcto o enrutar el correo vía un smarthost aprobado.
4) Fallos en handshakes TLS y desajustes de políticas
STARTTLS es oportunista en muchas configuraciones, pero cada vez más obligatorio en algunos entornos. TLS introduce:
errores de verificación de certificados, timeouts de handshake, incompatibilidades de cifrado e incluso bugs en bibliotecas antiguas.
Vigila:
TLS is required, but our TLS engine is unavailableSSL_accept error,no shared cipher- Largos retrasos durante la fase de conexión/handshake en los logs.
5) Límites de tasa remotos y deferimientos por reputación
El lado remoto puede estar sano. Simplemente no les caes bien en este momento.
Picos masivos, IPs emisoras nuevas, SPF/DKIM/DMARC desalineados o patrones inusuales de rebote pueden disparar la limitación.
Enfoque operativo:
- Separa flujos transaccionales y masivos (host/IP distinto si es posible).
- Implementa ritmo por dominio y límites de concurrencia.
- Evita tormentas de reintentos desde aplicaciones que tratan SMTP como una cola de mensajes (no lo es).
6) Filtrado de contenido y milters (la serialización oculta)
Escaneo antispam/AV es costoso. Si canalizas todo el correo a través de una única instancia de filtro, puedes crear un cuello de botella que parezca “SMTP lento”.
Además: cuando el filtro falla, los MTAs tienden a diferir—la cola crece—y el equipo de filtros dice “funciona en mi laptop.”
Trata a los filtros como cualquier otra dependencia: planifica capacidad, monitoriza y falla de forma segura (con política explícita).
7) Programación de reintentos y tiempo de vida de la cola mal configurados
Si reintentas demasiado agresivamente, amplificas las interrupciones y te limitan más. Si reintentas demasiado lentamente, acumulas backlog y fallas los SLAs del negocio.
El tiempo de vida de la cola también importa: mantener correo basura durante días desperdicia disco y atención.
Chiste #2: La cola de correo es como tu membresía del gimnasio—si la ignoras el tiempo suficiente, seguirá ahí, juzgándote en silencio.
Tres micro-historias corporativas desde las trincheras
Micro-historia 1: El incidente causado por una suposición equivocada
Una empresa mediana ejecutaba Postfix en un par de VMs detrás de un balanceador. Tenían una suposición “simple”:
el correo saliente no es infraestructura crítica, porque “siempre podemos reenviar”. Esa suposición se mantuvo hasta la semana de nómina.
La cola empezó a crecer lentamente tras un cambio de red. Los logs mostraban timeouts de conexión a un puñado de dominios, pero no a todos.
El ingeniero on-call asumió que los dominios remotos eran inestables y esperó a que se resolviera. Por la mañana, la cola diferida era masiva y el disco estaba casi lleno.
Entonces Postfix empezó a lanzar errores relacionados con la creación y limpieza de archivos.
El problema real fue vergonzosamente local: el puerto 25 saliente estaba bloqueado para uno de los gateways NAT durante el despliegue de reglas de firewall.
La mitad del tráfico tenía éxito; la otra mitad hacía timeout. El patrón de “éxito parcial” engañó a todos.
Como los reintentos eran conservadores, las fallas se acumularon silenciosamente.
La solución no fue heroica: corregir las reglas del firewall, drenar la cola y añadir una comprobación sintética que pruebe TCP/25 saliente desde cada nodo cada minuto.
La lección fue más valiosa que el incidente: nunca asumas que “algún correo funciona” significa “el correo está bien”.
Micro-historia 2: La optimización que salió mal
Otra organización tenía problemas reales de rendimiento. Marketing quería entregas más rápidas; ingeniería menos quejas.
Alguien aumentó la concurrencia y el paralelismo de Postfix en todos lados. La cola se drenó más rápido—durante aproximadamente una hora.
Luego comenzaron los diferimientos remotos: muchos 421 y 4.7.x “try again later”. Destinos importantes empezaron a tarpittear conexiones.
El MTA respondió manteniendo muchos procesos smtp abiertos, cada uno esperando un saludo o una respuesta lenta.
La CPU subió, pero peor aún, el uso de descriptores de archivo aumentó y la máquina empezó a comportarse de forma extraña.
Mientras tanto el filtro de contenido (un milter) ahora recibía ráfagas que nunca estuvo diseñado para manejar.
Empezó a agotar tiempos, lo que desencadenó más diferimientos, que crearon más reintentos, que aumentaron las ráfagas.
Así es como se construye un bucle de retroalimentación: toma un sistema ya bajo presión y “optimízalo” hasta autolesionarlo.
La recuperación requirió reducir la concurrencia, añadir límites por dominio y escalar la capa de filtros.
La solución a largo plazo fue de política: los cambios en el rendimiento del correo requieren pruebas de capacidad y un plan de reversión, no un “solo súbelo” de viernes por la tarde.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Una compañía de servicios financieros operaba una pequeña flota de MTAs salientes. Nada sofisticado—solo disciplina.
Mantenían spools de correo en SSDs locales, rotaban logs agresivamente, apuntaban resolvedores DNS a instancias conocidas y monitorizaban la distribución de edad de la cola.
Un día un resolvedor upstream comenzó a fallar intermitentemente. Muchos sistemas en la empresa tuvieron problemas, pero la flota de correo no se vino abajo.
Sus dashboards mostraron latencia en queries DNS subiendo, pero la cola permaneció estable.
¿Por qué? Tenían un resolvedor caché local en cada host de correo con timeouts sensatos y una cache caliente.
Además tenían alertas no solo en tamaño de cola, sino en “edad del mensaje diferido más antiguo” y “cardinalidad de razones de diferimiento.”
Esas alertas dispararon temprano, cuando la cola aún era manejable.
La solución fue un cambio controlado a los resolvedores upstream y una reducción temporal de la concurrencia saliente para evitar amplificar los timeouts DNS.
Sin llamada de crisis. Sin pánico ejecutivo. Solo operaciones aburridas haciendo lo que mejor hacen: prevenir el drama.
Errores comunes (síntoma → causa raíz → solución)
-
Síntoma: La cola crece, mayormente diferida, con “connect timed out”.
Causa raíz: TCP/25 saliente bloqueado, enrutamiento intermitente o agotamiento de la tabla NAT.
Solución: Valida TCP/25 connc; revisa firewall/política de egress; confirma capacidad NAT; considera un smarthost. -
Síntoma: La cola crece, “Try again later” (421/4.7.0) domina.
Causa raíz: Limitación de tasa remota o throttling por reputación; patrones de envío con ráfagas.
Solución: Raciona por dominio, segmenta tráfico, reduce concurrencia, corrige autenticación (SPF/DKIM/DMARC) y manejo de rebotes. -
Síntoma: Cola activa alta, CPU baja, iowait alto.
Causa raíz: Latencia de disco en el volumen del spool; almacenamiento sobresuscrito; sistema de archivos casi lleno.
Solución: Mueve el spool a almacenamiento más rápido; libera espacio/inodos; aísla de otros I/O; verifica coniostat. -
Síntoma: Fallos esporádicos, largos retrasos antes de conectar, tiempo de consulta DNS alto.
Causa raíz: Latencia del resolvedor, problemas EDNS/fragmentación, dominios de búsqueda mal configurados.
Solución: Arregla la ruta DNS; ejecuta un caché local; baja timeouts del resolvedor; verifica condig. -
Síntoma: Diferimientos relacionados con TLS aparecen de repente tras una actualización del SO o cambio de certificado.
Causa raíz: Mismatch en bundle CA, cambios en OpenSSL, política TLS aplicada sin soporte.
Solución: Re-prueba conopenssl s_client; verifica el almacén CA; ajusta la política TLS con cuidado, no emocionalmente. -
Síntoma: La cola es enorme, pero un solo remitente interno domina.
Causa raíz: Tormenta de reintentos de la app, lógica de colas mala o cuenta comprometida enviando spam.
Solución: Limita la tasa del remitente en el MTA; bloquea temporalmente; arregla comportamiento de la app; rota credenciales. -
Síntoma: La cola crece y los logs muestran “warning: database is locked” o similar para mapas.
Causa raíz: Mapas de lookup contencionados (ej., bases de datos locales), archivos de mapas montados en NFS o LDAP lento.
Solución: Mueve mapas localmente, cambia el backend de mapas, cachea lookups y aísla dependencias. -
Síntoma: La cola se drena extremadamente lento incluso después de arreglar la red.
Causa raíz: Programación de reintentos demasiado conservadora; pocos trabajadores smtp; límites por dominio demasiado estrictos.
Solución: Aumenta temporalmente concurrencia y tasa de entrega después de que el cuello de botella esté resuelto; vigila la tasa de errores y los diferimientos remotos.
Listas de verificación / plan paso a paso
Checklist A: Primeros 10 minutos (contención y señales)
- Captura la situación. Registra tamaño de cola, edad del mensaje más antiguo (si lo rastreas) y razones principales de diferimiento (Tarea 1–4).
- Confirma disco local e inodos. Si alguno es crítico, arréglalo primero (Tarea 5–6). Un disco lleno convierte un problema de entrega en pérdida de datos.
- Revisa latencia DNS y TCP/25 saliente. Valida desde el host MTA, no desde tu portátil (Tarea 10–12).
- Identifica remitente y dominios destino principales. Contén una avalancha temprano (Tarea 13–14).
- Comunica. Informa a las partes interesadas: “Las entregas salientes están retrasadas; la aceptación entrante sigue funcionando (o no). Próxima actualización en 30 minutos.”
Checklist B: Estabilizar el rendimiento (detener la hemorragia)
- Reduce la entrada si es necesario. Si una app inunda, throttléala en el MTA o firewall. Sí, te van a regañar; hazlo de todas formas.
- Arregla la razón principal de diferimiento. No persigas diez problemas pequeños cuando uno domina (Tarea 4).
- Prefiere tuning por destino sobre tuning global. Si un dominio te limita, no castigues a todos los demás.
- Asegura que el I/O del spool esté sano. Mueve colas a almacenamiento rápido si hace falta; las colas no son buen lugar para “ahorrar costos”.
- Verifica la tasa de vaciado. Observa la pendiente (Tarea 17). Si mejora, deja de manipular.
Checklist C: Recuperación y limpieza (después de que la cola empiece a drenar)
- Confirma comportamiento de rebotes. Asegúrate de no generar backscatter o bucles de rebote.
- Valida la política de reintentos. Asegura que no retendrás mensajes días que el negocio ya no considera relevantes.
- Controles post-incidente. Añade alertas sobre edad de la cola y razones de diferimiento, no solo sobre tamaño de cola.
- Haz una pequeña prueba de carga. Si cambiaste concurrencia o moviste spools, verifica que no creaste un nuevo cuello de botella.
- Documenta las “top 3” causas y comprobaciones. El tú-futuro no es tan listo a las 03:00.
Preguntas frecuentes
1) ¿Debería simplemente vaciar la cola?
Solo después de haber arreglado el cuello de botella subyacente. Vaciar una sistema roto aumenta la carga sobre la parte rota y puede empeorar los diferimientos o provocar throttling remoto.
El flush es una herramienta de recuperación, no de diagnóstico.
2) ¿Cuándo está bien borrar correo en cola?
Cuando es claramente abusivo (oleada de spam), claramente obsoleto (expiración aprobada por el negocio) o cuando disco/inodos están en riesgo de dejar el servidor inoperativo.
Borra con intención: identifica por remitente, destino o edad. No purgues al azar y esperes suerte.
3) ¿Por qué la cola está mayormente diferida y no activa?
Diferido significa que se hicieron intentos y fallaron temporalmente. Eso suele ser política remota, DNS/TLS/egress o dependencias de filtrado de contenido que rechazaron el correo.
Una cola activa dominante apunta más a procesamiento local o limitaciones de I/O.
4) ¿Cómo sé si DNS es el cuello de botella?
Mide el tiempo de consultas desde el host de correo con dig. Si búsquedas MX tardan cientos de milisegundos o segundos, eso basta para limitar el rendimiento.
También correlaciona con el desglose de retrasos en logs donde el tiempo antes de conectar aumenta.
5) ¿Un disco casi lleno puede causar retrasos antes de llenarse realmente?
Sí. Muchos sistemas de archivos se vuelven más lentos cuando el espacio es ajustado, y los spools de correo amplifican operaciones de metadatos.
Además: “casi lleno” es cómo terminas “repentinamente lleno” durante un backlog.
6) ¿Por qué los servidores remotos nos piden “intenta más tarde”?
Porque se están protegiendo: límites de tasa, controles de reputación, greylisting o protección por sobrecarga.
Trata los 4xx como una señal de ritmo, no como un insulto personal.
7) ¿Aumentar la concurrencia siempre es malo?
No. Solo que se usa mal con frecuencia. Aumenta la concurrencia solo cuando los recursos locales y la red están sanos y cuando los diferimientos remotos no son el modo de fallo dominante.
Prefiere ajustes dirigidos (por dominio) sobre un “subirlo todo” global.
8) ¿Qué métricas debería alertar además del tamaño de la cola?
Alerta sobre edad del mensaje más antiguo, ratio diferido-a-activo, conteos de razones principales de diferimiento, latencia de consultas DNS desde el MTA, margen de disco/inodos en el volumen del spool
y tasas de éxito de TCP/25 saliente.
9) ¿Cómo sé si un filtro de contenido nos está ralentizando?
Busca timeouts o diferimientos que mencionen el milter/servicio de políticas, altos conteos de conexiones al filtro o latencia creciente en la parte “antes del gestor de cola” del desglose de retrasos.
Si el filtro serializa trabajo, la cola crece aunque la conectividad remota esté bien.
10) ¿Por qué la cola sigue creciendo incluso después de “arreglar la red”?
Porque el rendimiento de entrega sigue por debajo de la tasa de llegada, o porque las programaciones de reintentos hacen que no vuelvas a intentar muchos mensajes diferidos de inmediato.
Observa la pendiente; ajusta la concurrencia con cautela una vez resuelto el fallo primario.
Próximos pasos que deberías tomar realmente
Si tu cola de correo sigue creciendo, no la trates como una masa misteriosa que necesita “tuneo”. Trátala como un backlog con causa.
Nombra la razón dominante de diferimiento. Verifica disco local y DNS. Prueba conectividad saliente. Identifica el remitente y el destino principales.
Luego realiza un cambio a la vez y observa la pendiente.
Pasos prácticos para el próximo día hábil:
- Añade alertas sobre edad del mensaje diferido más antiguo y razones principales de diferimiento, no solo tamaño de cola.
- Mueve o provisiona el spool de correo en un almacenamiento que confíes para I/O de archivos pequeños. Si eso suena caro, valora el coste de la interrupción.
- Ejecuta un resolvedor DNS caché local en hosts de correo (o usa resolvedores conocidos) y mide la latencia de consultas de forma continua.
- Implementa ritmo por destino y separa correo masivo del transaccional si envías volumen.
- Escribe una hoja de ruta de una página con la Guía rápida de diagnóstico y los cinco comandos principales que ejecutarás bajo estrés.