Correo “message deferred”: descifra por qué el correo está atascado (y arréglalo)

Qué significa realmente “message deferred” (y qué no significa)

En el mundo de los MTA (Postfix, Exim, Sendmail, Exchange’s SMTP transport, elige tu veneno), “deferred” significa “intentamos entregar, pero obtuvimos un fallo temporal, así que reintentaremos más tarde.” No es un rebote. No es un éxito. Es un estado con un reloj adjunto.

La mayoría de los diferimientos provienen de respuestas SMTP 4xx (temporales). Piensa: “421 Service not available”, “450 mailbox unavailable”, “451 local error”, “452 insufficient system storage”. Los MTA los tratan como “no entres en pánico todavía.” Encolan el mensaje y reintentan según un calendario. Si los reintentos siguen fallando y el mensaje excede su tiempo máximo en cola, entonces se convierte en un rebote (5xx) o en una eliminación silenciosa si tu configuración es… creativamente negligente.

Deferred es un síntoma, no un diagnóstico

“Deferred” te dice dónde está el mensaje: todavía en tu cola. No te dice por qué. El “por qué” siempre está en el estado detallado: una respuesta SMTP remota, una falla DNS, un error de TLS, un timeout, un problema de disco local, rechazo por política, límite de tasa, o la incapacidad de tu propio MTA para generar suficientes procesos de entrega.

Dos diferimientos que parecen idénticos pero no lo son

• Deferral remoto: Tu servidor se conectó hacia afuera, el servidor del destinatario dijo “intenta de nuevo más tarde.” Greylisting, throttling, outage temporal, colas de escaneo de contenido, sistemas de reputación, o “hoy no nos caes bien”.
• Deferral local: Tu servidor ni siquiera pudo intentar la entrega correctamente. Falló la resolución DNS, la ruta de red está rota, disco lleno, I/O de la cola lento, librerías TLS con problemas, o alcanzaste tus propios límites de concurrencia.

Uno de estos es “espera y reintenta.” El otro es “tienes un problema ahora mismo.” Si los tratas igual, harás lo incorrecto rápidamente.

Una cita para mantenerte honesto: La esperanza no es una estrategia. (General James N. Mattis)

Broma #1: Las colas de correo son como montones de ropa sucia—ignorarla no las hace más pequeñas, solo te hace evitar mirar el panel de control.

Cuadro de diagnóstico rápido: comprobaciones primera/segunda/tercera

Esta es la secuencia de triage de alta señal. Está diseñada para producción: mínimo cambio de contexto, máxima claridad. No empieces leyendo 20k líneas de logs. Empieza localizando el punto de estrangulamiento.

Primero: ¿La cola está creciendo, y cuál cola es?

• Si es la active queue que se hincha, tu MTA está intentando pero bloqueado (throttling remoto, red, TLS, políticas, concurrencia).
• Si es la deferred queue que se hincha, los intentos están fallando y posponiéndose (timeouts, 4xx, DNS, outages remotos).
• Si la maildrop / cola de submission está creciendo, el correo no está siendo aceptado en la cola principal (problemas de envío local, permisos, filtro de contenido caído, disco, servicio de limpieza).

Segundo: Escoge un mensaje y sigue su razón de fallo

Elige un mensaje diferido representativo (no un destinatario raro). Extrae la respuesta SMTP exacta o el error local. Esa línea suele contarte el 80% de la historia.

Tercero: Decide si es política remota vs tu infraestructura

Los problemas de política remota (greylisting, throttling, reputación, backlog del destinatario) requieren cambiar comportamiento: cadencia de reintentos, reputación de IP, moldeado de volumen, identidades DNS correctas, a veces enrutar a través de un relay.

Los problemas de infraestructura requieren arreglar sistemas: DNS, disco, CPU, red, TLS, límites de procesos, o una dependencia rota como un filtro de contenido.

Cuarto: Deja de empeorarlo

• No “vacíes toda la cola” repetidamente. Eso puede amplificar el throttling remoto y extender el dolor.
• No aumentes la concurrencia a ciegas. Puedes DDoSear al destinatario y que te bloquee más fuerte.
• No reinicies servicios como primer reflejo. Podrías borrar estado crucial y difuminar la evidencia.

Quinto: Estabiliza, luego arregla

Estabilizar significa reducir el crecimiento del backlog: limitar la tasa saliente, pausar remitentes no críticos, o enrutar a través de un relay más inteligente. Arreglar significa abordar la causa raíz: fiabilidad DNS, I/O de disco, TLS, cumplimiento de políticas, o problemas de negociación remota.

Datos interesantes y contexto (por qué existe el diferimiento)

1. SMTP fue diseñado para redes poco fiables. Los reintentos son una característica, no un parche—store-and-forward es la idea central.
2. 4xx vs 5xx es un contrato operacional. 4xx dice “intenta de nuevo más tarde”, 5xx dice “detente”. Muchos sistemas modernos abusan de 4xx para ralentizarte sin comprometerse a un rechazo.
3. El greylisting popularizó “defer como defensa.” Instrumentó los reintentos: MTAs legítimos reintentan; muchos bots de spam no lo hacían (o no esperaban).
4. Los tiempos de vida en cola varían según el MTA. Postfix suele predeterminar a días; eso significa que “message deferred” puede convertirse silenciosamente en una queja multi-día si no alertas sobre ello.
5. DNS es parte del transporte de correo, no metadatos opcionales. Si tu resolvedor está roto, tu correo está roto. “Message deferred” será felizmente tu única pista.
6. La preferencia MX no es balanceo de carga. Es prioridad/failover. Todavía hay gente que lo “optimiza” hacia un desastre.
7. TLS para SMTP es oportunista por defecto. Los fallos de STARTTLS pueden causar diferimientos si las políticas requieren cifrado o si aparecen bugs de negociación TLS tras una actualización del SO.
8. Los grandes proveedores moldean tráfico con 421s. Pueden diferirte por volumen, reputación o picos súbitos—aunque tu contenido esté bien.
9. Las colas de correo se almacenan en disco porque la RAM olvida. Cuando el almacenamiento es lento, el correo se vuelve lento. El directorio de la cola es una dependencia de rendimiento.

Los modos de fallo principales detrás de los diferimientos

1) Fallos temporales remotos (están ocupados, cautelosos o molestos)

Respuestas remotas comunes que disparan diferimientos:

• 421: service not available (mantenimiento, sobrecarga, throttling)
• 450/451: temporary mailbox o local error
• 452: insufficient system storage (sí, su problema de disco se convierte en tu problema de cola)
• 4.7.0 / 4.7.1: diferimientos relacionados con política/reputación (“try again later” mientras deciden si eres spam)

Si el servidor remoto te está diferiendo, tu mejor movimiento es respetarlo. Reintentos agresivos tienden a convertir “diferimiento temporal” en “bloqueo permanente.”

2) Fallos DNS (la dependencia silenciosa del correo)

Síntomas: líneas de log como “Host or domain name not found,” “temporary lookup failure,” o “no MX found.” Las causas raíz incluyen a menudo:

• Resolvedor local roto/sobrecargado
• Firewall que bloquea a DNS upstream
• Problemas de validación DNSSEC
• Configuración incorrecta de search domain que causa timeouts extraños

3) Problemas de ruta de red (no puedes alcanzarlos)

Timeouts de conexión, resets, problemas de enrutamiento, problemas de MTU, tablas NAT rotas—cosas clásicas de SRE con un mensaje de error con forma de correo. Si no puedes completar un handshake TCP al puerto 25 (o 587 a un relay), diferirás para siempre.

4) Problemas de negociación TLS/STARTTLS

Los fallos aparecen como “TLS handshake failed,” “no shared cipher,” “certificate verify failed,” o “lost connection after STARTTLS.” A menudo desencadenados por:

• Cambios en la política criptográfica del SO tras parches
• Política TLS saliente demasiado estricta para el mundo real
• Middleboxes rotos que hacen inspección TLS “útil”

5) Agotamiento de recursos locales (la cola no puede respirar)

Si tu disco está lleno, sin inodos, o dolorosamente lento, los mensajes se diferirán porque el MTA no puede actualizar archivos de la cola o generar entregas de forma fiable. La presión de CPU también puede causar timeouts y lentitud. Igual que alcanzar límites de procesos.

6) Filtros de contenido y milters (la cadena de dependencias que olvidaste)

Filtros de spam/virus, firmado DKIM, demonios de política, escáneres DLP—cuando se retrasan o caen, tu MTA puede aceptar correo pero diferir la entrega, o ralentizar todo hacia un backlog. Verás tempfails que parecen problemas remotos pero que en realidad son fallos IPC locales.

7) Límites de tasa y mala configuración de concurrencia

Postfix y Exim tienen perillas para concurrencia por dominio, tasa de conexión y paralelismo global. Demasiado bajo y eres lento; demasiado alto y te throttlean o bloquean. El valor “correcto” cambia según la forma de tráfico y la mezcla de destinatarios.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las comprobaciones básicas que ejecuto cuando alguien dice “el correo está atascado.” Cada tarea incluye un comando, salida de ejemplo, qué significa y qué decisión tomar.

Task 1: Confirmar tamaño de la cola y qué cola está creciendo (Postfix)

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C12A1B8       4125 Mon Jan  4 09:01:22  alerts@example.com
(connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
                                         user@gmail.com

7D91B2F04C       2988 Mon Jan  4 09:02:10  noreply@example.com
(host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))
                                         ops@partner.tld

-- 2470 Kbytes in 312 Requests.

Significado: Ya tienes dos clases diferentes de diferimiento: timeout de red a Google, y un 421 de throttling/política desde partner.tld.

Decisión: Divide el problema. Investiga la conectividad/timeouts por separado del diferimiento por política del destinatario. Una solución no va a arreglar ambos.

Task 2: Resumir rápidamente las razones en la cola (estilo qshape/qgrep de Postfix)

cr0x@server:~$ postqueue -p | tail -n +2 | awk '/^[A-F0-9]/{id=$1} /connect to/{print id,$0} /said:/{print id,$0}' | head
3F2C12A1B8 (connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
7D91B2F04C (host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))
1AA09D0C11 (connect to mx.mail.yahoo.com[98.137.11.163]:25: Connection timed out)

Significado: Estás viendo un patrón: timeouts hacia proveedores grandes. Huele a firewall de salida, enrutamiento o bloqueo de tu rango IP por parte del proveedor.

Decisión: Deja de tocar las perillas de Postfix. Ve a probar la accesibilidad de red desde el host y verifica la reputación/ruteo de tu IP pública.

Task 3: Inspeccionar el estado detallado de un único mensaje (Postfix)

cr0x@server:~$ postcat -q 3F2C12A1B8 | sed -n '1,40p'
*** ENVELOPE RECORDS 3F2C12A1B8 ***
message_size:            4125            236               1               0            4125
message_arrival_time: Mon Jan  4 09:01:22 2026
create_time: Mon Jan  4 09:01:22 2026
named_attribute: log_ident=3F2C12A1B8
sender: alerts@example.com
recipient: user@gmail.com
*** MESSAGE CONTENTS 3F2C12A1B8 ***
Received: from app01.example.com (app01.example.com [10.10.10.21])
        by mx01.example.com (Postfix) with ESMTPS id 3F2C12A1B8
        for <user@gmail.com>; Mon,  4 Jan 2026 09:01:22 +0000 (UTC)
Subject: Alert: latency spike

Significado: Confirma remitente/destinatario y que no es un destino único problemático. También confirma que el mensaje tiene tamaño normal y no dispara comportamiento de mensajes grandes.

Decisión: Si solo fallan ciertos destinatarios, trátalo como política por dominio. Si fallan muchos dominios, trátalo como infraestructura.

Task 4: Seguir los logs en vivo para las razones de diferimiento

cr0x@server:~$ sudo journalctl -u postfix -f
Jan 04 09:06:11 mx01 postfix/smtp[22108]: 3F2C12A1B8: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=289, delays=0.1/0.01/289/0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
Jan 04 09:06:14 mx01 postfix/smtp[22110]: 7D91B2F04C: to=<ops@partner.tld>, relay=mx1.partner.tld[203.0.113.10]:25, delay=244, delays=0.1/0.02/30/214, dsn=4.7.0, status=deferred (host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))

Significado: El desglose delays= es oro. Aquí, la mayor parte del tiempo se gasta en las etapas tercera y cuarta (red/TCP y tiempo de respuesta SMTP remoto).

Decisión: Para timeouts, investiga red/firewall. Para 421 al final de DATA, sospecha backlog de escaneo de contenido o throttling: reduce concurrencia y la cadencia de reintentos por dominio.

Task 5: Validar conectividad TCP saliente al puerto 25

cr0x@server:~$ nc -vz gmail-smtp-in.l.google.com 25
nc: connect to gmail-smtp-in.l.google.com (142.250.102.26) port 25 (tcp) timed out: Operation now in progress

Significado: Esto no es un problema de política SMTP. Ni siquiera puedes abrir una sesión TCP.

Decisión: Revisa reglas de firewall de salida, bloqueos del proveedor upstream, capacidad NAT o enrutamiento. Si estás en una VPC en la nube, confirma que el puerto 25 no esté bloqueado por política.

Task 6: Confirmar enrutamiento y IP origen usada para el correo saliente

cr0x@server:~$ ip route get 142.250.102.26
142.250.102.26 via 198.51.100.1 dev eth0 src 198.51.100.23 uid 1000
    cache

Significado: Tu correo sale con la IP origen 198.51.100.23. Esa es la IP que los proveedores remotos ven, limitan o bloquean.

Decisión: Si los timeouts/diferimientos son específicos de proveedores, verifica si esta IP está en un rango problemático, o si tu ISP bloquea el 25. Si tienes múltiples IPs de salida, considera mover el SMTP saliente a una IP limpia.

Task 7: Verificar la fiabilidad de resolución DNS (A/MX) desde el host MTA

cr0x@server:~$ dig +time=2 +tries=1 mx partner.tld
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14152
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; ANSWER SECTION:
partner.tld.     300 IN MX 10 mx1.partner.tld.
partner.tld.     300 IN MX 20 mx2.partner.tld.

;; Query time: 21 msec
;; SERVER: 10.0.0.53#53(10.0.0.53)
;; WHEN: Mon Jan 04 09:08:44 UTC 2026
;; MSG SIZE  rcvd: 132

Significado: Aquí las respuestas DNS son rápidas y limpias. Si ves timeouts o SERVFAIL intermitentes, esa es una causa mayor de diferimiento.

Decisión: Si DNS está inestable, arregla los resolvedores primero (caching, reachabilidad upstream, problemas DNSSEC). Los MTA dependen de DNS por diseño.

Task 8: Comprobar identidad del hostname propio y reverse DNS (PTR)

cr0x@server:~$ hostname -f
mx01.example.com

cr0x@server:~$ dig +short -x 198.51.100.23
mx01.example.com.

Significado: Forward y reverse están alineados. Un rDNS desalineado no siempre causa diferimientos, pero es un ingrediente frecuente en “421 try again later” de receptores estrictos.

Decisión: Si el PTR falta o está mal, arréglalo. No discutas. Los receptores de correo no son una democracia.

Task 9: Probar la conversación SMTP y ver el comportamiento real del remoto

cr0x@server:~$ swaks --to ops@partner.tld --server mx1.partner.tld --timeout 20
=== Trying mx1.partner.tld:25...
=== Connected to mx1.partner.tld.
<--- 220 mx1.partner.tld ESMTP
---> EHLO mx01.example.com
<--- 250-mx1.partner.tld
<--- 250-STARTTLS
---> STARTTLS
<--- 220 2.0.0 Ready to start TLS
=== TLS started with cipher TLS_AES_256_GCM_SHA384
---> MAIL FROM:<test@example.com>
<--- 250 2.1.0 Ok
---> RCPT TO:<ops@partner.tld>
<--- 250 2.1.5 Ok
---> DATA
<--- 354 End data with <CR><LF>.<CR><LF>
---> .
<--- 421 4.7.0 Try again later

Significado: El remoto acepta el sobre pero difiere al final de DATA. Eso suele indicar backlog de escaneo de contenido, scoring de política, o shaping de tasa que se dispara después de ver cabeceras/cuerpo.

Decisión: Reduce el throughput hacia ese dominio, asegúrate de que DKIM/SPF/DMARC están bien alineados, y confirma que no estás enviando picos repentinos. Si es un partner, coordina con su equipo de correo.

Task 10: Comprobar espacio en disco e inodos locales (la cola vive en disco)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  900M  98% /var

cr0x@server:~$ df -i /var/spool/postfix
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       2621440 2619000   2440  100% /var

Significado: Te quedaste sin inodos. Eso es peor que quedarte sin espacio para las colas de correo, porque cada mensaje encolado usa múltiples archivos pequeños.

Decisión: Libera inodos inmediatamente: limpia archivos temporales no esenciales, rota logs, mueve caches grandes de apps, o amplía el sistema de ficheros. Hasta que lo hagas, el correo se comportará como “misteriosamente roto.” No es misterioso. Está lleno.

Task 11: Confirmar que los servicios de Postfix están arriba y no atascados

cr0x@server:~$ sudo postfix status
postfix/postfix-script: the Postfix mail system is running: PID: 1047

cr0x@server:~$ sudo postconf -n | egrep 'queue_directory|myhostname|myorigin|relayhost|default_process_limit'
queue_directory = /var/spool/postfix
myhostname = mx01.example.com
myorigin = /etc/mailname
relayhost =
default_process_limit = 100

Significado: Sanidad básica: Postfix está corriendo, el directorio de cola es estándar, el límite de procesos es 100.

Decisión: Si Postfix está caído o inestable, arregla eso antes que nada. Si está funcionando pero difiriendo, pasa al verdadero cuello de botella: red, disco, DNS o política remota.

Task 12: Comprobar concurrencia de entrega y throttling por dominio (Postfix)

cr0x@server:~$ sudo postconf -n | egrep 'smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_connect_timeout|smtp_helo_timeout'
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_connect_timeout = 30s
smtp_helo_timeout = 300s

Significado: Una concurrencia de 20 por destino puede ser agresiva para algunos receptores, especialmente si tienes picos.

Decisión: Si ves muchos 421/4.7.0, baja la concurrencia por dominio y añade un pequeño rate delay. No “aprietes más.” Así es como te bloquean.

Task 13: Inspeccionar conexiones SMTP cliente activas y agotamiento local

cr0x@server:~$ sudo ss -tanp '( dport = :25 )' | head
State  Recv-Q Send-Q Local Address:Port    Peer Address:Port    Process
SYN-SENT 0     1     198.51.100.23:41220  142.250.102.26:25   users:(("smtp",pid=22108,fd=6))
SYN-SENT 0     1     198.51.100.23:41222  98.137.11.163:25    users:(("smtp",pid=22113,fd=6))
ESTAB    0     0     198.51.100.23:41210  203.0.113.10:25     users:(("smtp",pid=22110,fd=6))

Significado: Muchas entradas SYN-SENT significan que las conexiones salientes no se están completando. Eso es red upstream o filtrado remoto.

Decisión: Si los SYNs cuelgan hacia muchos destinos, prioriza comprobaciones de red/egress. Si ves muchos ESTAB pero respuestas lentas, prioriza throttling remoto o negociación TLS.

Task 14: Comprobar límites de file descriptors a nivel OS (la cola y smtp usan muchos ficheros)

cr0x@server:~$ sudo -u postfix sh -c 'ulimit -n'
1024

Significado: 1024 FDs para el usuario postfix puede ser demasiado bajo bajo alto volumen, especialmente con filtros de contenido y muchas entregas simultáneas.

Decisión: Si ves “too many open files” en logs o diferimientos aleatorios bajo carga, sube los límites vía overrides de systemd y límites OS. Luego verifica que el nuevo límite se aplica realmente a los procesos de Postfix.

Task 15: Vista de Exim (si ejecutas Exim)

cr0x@server:~$ sudo exim -bp | head
1tUQz7-0004cR-7p  2.1K Mon 04 Jan 2026 09:02:10  noreply@example.com
  ops@partner.tld

1tUQz8-0004cU-9B  4.0K Mon 04 Jan 2026 09:01:22  alerts@example.com
  user@gmail.com

cr0x@server:~$ sudo exim -Mvh 1tUQz8-0004cU-9B | egrep -i 'defer|retry|error|dsn' | head
-host_address 142.250.102.26
-error_message connect to 142.250.102.26 port 25: Connection timed out

Significado: La misma historia, otra herramienta: Exim almacena la razón en los headers/logs para esa entrada de cola.

Decisión: Si Exim muestra timeouts de red, ve a red. Si muestra 4xx explícitos, ve a entregabilidad/throttling.

Task 16: Validar que tu resolvedor no está fallando intermitentemente

cr0x@server:~$ for i in $(seq 1 5); do dig +time=1 +tries=1 mx gmail.com | grep 'Query time'; done
;; Query time: 19 msec
;; Query time: 21 msec
;; Query time: 1001 msec
;; Query time: 19 msec
;; Query time: 20 msec

Significado: Una consulta saltó a ~1s (límite de timeout). Bajo carga, eso se convierte en lentitud de entrega y diferimientos.

Decisión: Si ves jitter, arregla el caching DNS y la reachabilidad upstream, o ejecuta un resolvedor de caché local con timeouts sensatos. El correo penaliza DNS inestable de inmediato.

Errores comunes: síntoma → causa raíz → solución

1) “Todo está diferido hacia Gmail”

Síntoma: connect to gmail-smtp-in.l.google.com:25: Connection timed out

Causa raíz: Puerto 25 saliente bloqueado por ISP/nube, o firewall/NACL de egress, o enrutamiento/NAT agotado.

Solución: Confirma con nc -vz y ss. Elimina el bloqueo, o enruta el correo saliente a través de un relay en 587 con autenticación si el puerto 25 está bloqueado por política.

2) “Deferred (host said: 421 4.7.0 Try again later)” después de DATA

Síntoma: El remoto acepta RCPT y luego difiere tras el contenido del mensaje.

Causa raíz: Backlog de escaneo de contenido, shaping de tasa, o scoring de reputación activado por tus cabeceras/cuerpo, picos de volumen, o identidad inconsistente (PTR/HELO/SPF/DKIM).

Solución: Baja la concurrencia por dominio, añade delay de tasa, asegúrate de que el firmado DKIM sea estable, que SPF incluya tu IP de envío, y alinea rDNS y HELO. Si es un partner, coordina allowlisting y expectativas de volumen.

3) “Temporary lookup failure” / “Host not found”

Síntoma: DSNs o líneas de log relacionadas con DNS, a menudo intermitentes.

Causa raíz: Timeouts del resolvedor, DNSSEC roto, outage upstream, o /etc/resolv.conf mal configurado con servidores muertos.

Solución: Arregla la cadena de resolvedores; añade redundancia; acorta timeouts; asegura que el MTA apunte a resolvedores fiables.

4) La cola crece, el disco parece bien, pero las entregas avanzan lento

Síntoma: No hay errores obvios, solo correo lento y diferimientos crecientes.

Causa raíz: Latencia I/O de disco (no capacidad) o agotamiento de inodos, a menudo en /var compartido con logs y datos de apps.

Solución: Mide con iostat/pidstat (no mostrado aquí), mueve el spool a almacenamiento más rápido, separa el sistema de ficheros, expande inodos, y deja de co-ubicar “cola de correo” con “todo lo demás que escribe”.

5) “TLS handshake failed” y de repente todo difiere tras un parche

Síntoma: Errores de STARTTLS en algunos dominios, no en todos.

Causa raíz: Cambio en la política criptográfica (ciphers/protocolos), servidores pares desactualizados, o política TLS saliente demasiado estricta.

Solución: Decide tu política: TLS oportunista vs obligatorio. Si es obligatorio, puede que necesites excepciones por dominio. Si es oportunista, relaja restricciones locales que sean demasiado estrictas para la realidad SMTP.

6) “Vacío la cola y ahora está peor”

Síntoma: Más diferimientos, nuevos bloqueos, retrasos mayores.

Causa raíz: Un flush crea un pico. El throttling remoto se dispara; tu reputación IP sufre; tus tablas NAT/estado se estresan.

Solución: Limita. Moldea. Deja que los reintentos hagan su trabajo. Vacía la cola solo después de remover la causa raíz, y aun así, sube la presión gradualmente.

Tres mini-historias corporativas desde las trincheras del correo

Mini-historia #1: El incidente causado por una suposición equivocada

Una empresa mediana movió su aplicación principal de un entorno colo a una VPC en la nube. Mantuvieron la VM del servidor de correo “porque ya funciona”. El plan de migración incluía bases de datos, caches y la capa de app. El correo fue tratado como una tostadora: enchúfala y calienta pan.

El lunes, los correos transaccionales dejaron de llegar a dominios de consumidores grandes. La cola creció. Los logs mostraban connect to ...:25: Connection timed out. El equipo de la app asumió que Gmail estaba caído o “limitando”. El equipo de red asumió que el equipo de correo había misconfigurado Postfix. Todos estaban equivocados de forma coordinada.

La causa raíz fue aburrida: el proveedor en la nube bloqueaba el TCP/25 saliente por defecto para esa cuenta. El servidor de correo podía resolver DNS y conectar a servicios internos, así que la monitorización parecía bien. Solo el puerto que importa para la entrega SMTP se denegaba silenciosamente.

Pasan horas ajustando concurrencia e intervalos de reintento—efectivamente optimizando la radio del coche mientras faltaba el motor. Cuando alguien ejecutó nc -vz desde el host y observó que hacía timeout, el diagnóstico encajó. Encaminaron el correo saliente por un relay autenticado en el puerto 587 mientras esperaban excepciones de política.

La lección: no asumas que “la red está abierta” solo porque SSH funciona. SMTP depende de rutas de egress específicas, y los valores por defecto de la nube no son tus amigos.

Mini-historia #2: La optimización que salió mal

Una empresa global tuvo un pico legítimo de volumen: estados trimestrales, restablecimientos de contraseña y una campaña de marketing que nadie quiso admitir. Su clúster MTA estaba sano, pero los diferimientos subieron contra algunos grandes receptores con respuestas 421 4.7.0.

Un ingeniero vio que el límite de concurrencia por destino era “conservador” y lo aumentó. Luego lo aumentó otra vez. El throughput mejoró—por unos 20 minutos. Luego los receptores remotos empezaron a diferir antes, más a menudo y por más tiempo. Algunos receptores pasaron de 4xx a bloqueos duros. Los tiempos de entrega pasaron de minutos a horas.

¿Por qué? Los receptores no estaban limitados en el sentido simple. Aplicaban políticas y shaping. Mayor concurrencia parecía comportamiento abusivo, aunque el contenido fuera correcto. El MTA se convirtió en un martillo muy educado, golpeando la misma uña hasta que el destinatario se enfadó y se levantó.

La solución fue lo contrario de “optimizar”: bajar la concurrencia por destino, introducir un pequeño rate delay y repartir tráfico entre pools de IP separados con patrones de volumen estables. También dejaron de volcar todo el backlog inmediatamente tras una ventana de mantenimiento.

La lección: en la entrega de correo, la fuerza bruta no es ingeniería de rendimiento. Es ingeniería de reputación, y la nota la tiene otro.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día

Una firma financiera ejecutaba correo saliente desde dos MTAs en modo active-active, frontalizados por una capa de relays. Nada sofisticado. Lo sofisticado era su disciplina: filesystem separado para /var/spool/postfix, alertas en uso de inodos y muestreo diario de razones de diferimiento (no solo contadores).

Una mañana, los diferimientos subieron, pero solo para un subconjunto de destinos. La cola aún no explotaba. Su alerta no era “cola > X”, era “la razón principal de diferimiento cambió.” Esa es una alerta madura: detecta un nuevo modo de fallo antes de que el volumen asuste.

La nueva razón fue fallo de negociación TLS hacia ciertos servidores antiguos justo después de un parche del SO. El equipo tenía un playbook preescrito: confirmar con una prueba SMTP dirigida, revertir el cambio de política criptográfica solo para SMTP, y mantener el resto del set de parches de seguridad. Sin drama, sin llamada general.

Restauraron la entrega en menos de una hora, y nadie fuera del equipo de correo lo notó. Ese es el mejor resultado: ausencia de reuniones.

Lección: prácticas aburridas—spools separados, alertas de inodos, monitorización basada en razones—no se sienten heroicas. Lo son. Te evitan aprender lecciones duras en horario laboral.

Listas de comprobación / plan paso a paso (estabilizar, arreglar, prevenir)

Paso 1: Estabiliza el radio de impacto (15 minutos)

• Para los flushs repetidos de cola. Si alguien está vaciando cada cinco minutos, quítale el teclado con educación.
• Identifica las 1–3 razones principales de diferimiento a partir de logs y salida de cola. No persigas casos raros aun.
• Limita la salida hacia los dominios más afectados si están devolviendo 421/4.7.0.
• Confirma disco/inodos en el filesystem del spool y libera espacio si hace falta.
• Confirma resolución DNS estable y rápida desde el host MTA.

Paso 2: Arregla la causa raíz (30–120 minutos)

• Si hay timeouts: verifica puerto 25 saliente, enrutamiento, firewall, estado NAT y bloqueos de proveedor.
• Si hay throttling 421 remoto: ajusta concurrencia/tasa por destino, suaviza picos y verifica identidad del remitente (PTR/HELO/SPF/DKIM).
• Si hay fallos TLS: reproduce con una prueba dirigida a un remoto, luego ajusta tu política TLS SMTP para coincidir con la realidad operativa.
• Si hay cuello de botella de filtro de contenido: revisa salud de milters/servicios, colas y timeouts. Si está caído, decide si bypass temporal (aceptando riesgo) o escalar su capacidad.
• Si hay latencia I/O de disco: mueve el spool a almacenamiento más rápido o sepáralo de vecinos ruidosos. El correo no se impresiona por tu filesystem compartido.

Paso 3: Drena la cola de forma segura (horas, no minutos)

• Deja que los reintentos normales actúen salvo que tengas SLAs de entrega estrictos.
• Aumenta la concurrencia gradualmente solo si las respuestas remotas permanecen saludables (2xx) y tus recursos locales lo soportan.
• Prioriza clases de correo (restablecimientos de contraseña > newsletters). Si no puedes, al menos sepáralos por remitente o política de relay.

Paso 4: Prevén la recurrencia (esta semana)

• Alerta por razones de diferimiento, no solo por tamaño de cola.
• Rastrea rendimiento por dominio: qué destinos difieren, con qué frecuencia y cuánto tarda la recuperación.
• Separa el almacenamiento del spool y alerta sobre espacio e inodos y latencia, no solo “% de disco usado”.
• Documenta tu identidad de salida: PTR, nombre HELO, registros SPF, selectores DKIM, política DMARC.
• Mantén un fallback probado en un relay 587 con autenticación para entornos donde el puerto 25 es frágil o la IP de egress se estropea.

Broma #2: La entrega de correo es un sistema distribuido donde el “problema temporal” del otro lado dura exactamente tanto como la paciencia de tu ejecutivo.

FAQ (lo que la gente pregunta a las 2 a.m.)

1) ¿Es malo “message deferred”?

No automáticamente. El diferimiento es cómo SMTP sobrevive fallos temporales. Se vuelve malo cuando la cola crece más rápido de lo que drena, o cuando la razón de diferimiento apunta a una falla local (DNS, disco, puerto 25 bloqueado).

2) ¿Cuánto tiempo va a estar un mensaje diferido en cola?

Depende de la configuración de tu MTA. Muchos sistemas reintentan durante días antes de rendirse. Operacionalmente, deberías alertar mucho antes de que “días” se convierta en una queja visible por parte del usuario.

3) ¿Por qué veo 421 “Try again later” aunque el destinatario esté arriba?

Porque “arriba” no es lo mismo que “dispuesto”. Los grandes receptores difieren para shaping de tráfico, reputación, detección de picos y capacidad de escaneo de contenido. Trata 421 como una señal de negociación, no como un crash de servidor.

4) ¿Debería vaciar la cola para arreglarlo?

Vacía después de arreglar la causa raíz, y aun así con cuidado. Vaciar durante un evento de throttling suele crear un pico que empeora el throttling o activa bloqueos.

5) ¿Cuál es la diferencia entre “deferred” y “bounced”?

Deferred significa fallo temporal (usualmente 4xx) y se reintentará. Bounced significa fallo permanente (5xx) y se devuelve al remitente (o se registra/descarta según política).

6) ¿Por qué importa tanto el DNS para la entrega de correo?

El enrutamiento SMTP depende de registros MX, además de búsquedas A/AAAA para esos hosts. Muchos receptores también comprueban la consistencia PTR/HELO. Si DNS es lento o falla, las entregas se paralizan y los diferimientos se acumulan.

7) ¿Pueden los problemas de disco realmente causar “message deferred”?

Sí. Las colas de correo son muchos archivos pequeños. Si te quedas sin espacio o inodos, o si el filesystem es lento, el MTA no puede actualizar el estado de la cola ni procesar entregas. Los logs pueden no gritar; simplemente diferirán.

8) ¿Por qué solo algunos dominios difieren mientras otros entregan?

Porque la política es por receptor. Un dominio puede hacer greylisting, otro puede throttlear, otro puede requerir alineación rDNS correcta, y otro puede estar caído. El correo no es una sola red; son miles de conjuntos de reglas independientes.

9) ¿DKIM/SPF/DMARC causan diferimientos o rebotes?

Ambos son posibles. La desalineación o falta de autenticación puede llevar a más diferimientos 4xx (política/reputación) antes de un rechazo total. Arreglar la autenticación suele reducir el ruido de “try again later” con el tiempo.

10) ¿Cuándo debo involucrar al equipo de correo del destinatario?

Cuando tengas un 4xx remoto consistente con un patrón estable (misma respuesta, misma etapa como final de DATA) y tu infraestructura esté limpia (puerto 25 funciona, DNS limpio, identidad consistente). Lleva evidencia: timestamps, transcripciones SMTP, IP de envío y Message-IDs de ejemplo.

Próximos pasos que deberías tomar esta semana

Si “message deferred” es un huésped recurrente en tus logs, deja de tratarlo como clima. Construye un sistema pequeño y repetible en torno a ello.

• Instrumenta las razones de diferimiento (top N por conteo, top N por destinatarios/dominios afectados). Una cola creciente llega tarde; un cambio en la razón llega temprano.
• Separa el filesystem del spool y alerta sobre inodos y síntomas de latencia, no solo “porcentaje de disco usado”.
• Fortalece la resolución DNS para los hosts MTA. Resolvedores recursivos fiables con timeouts sensatos no son opcionales.
• Configura shaping sensato por dominio para que no aprendas sobre throttling por una queja de cliente.
• Mantén un camino de fallback probado (un relay en 587) para cuando el puerto 25 esté bloqueado o tu IP de egress esté en problemas.

El objetivo no es eliminar los diferimientos. Eso es poco realista. El objetivo es reconocer cuándo un reintento normal se convierte en un incidente de producción—y arreglar el verdadero cuello de botella antes de que tu cola se transforme en una cápsula del tiempo.