Correo «421 demasiadas conexiones»: ajustar concurrencia sin retrasar el envío

Qué significa realmente “421 demasiadas conexiones”

SMTP 421 es un fallo temporal: “Servicio no disponible” en la jerga RFC. En la práctica, se usa como una válvula de presión: “No estoy aceptando esto ahora, inténtalo más tarde.” La cadena “demasiadas conexiones” es la pista de que excediste algún límite: a menudo sesiones concurrentes desde tu IP, a veces por cuenta, a veces por dominio de destino, a veces por un bucket de reputación entrante.

Dos realidades comunes que esconden el mismo error

• Limitación remota: Tu MTA abre demasiadas sesiones SMTP simultáneas hacia el mismo proveedor/dominio, y el remoto rechaza temporalmente nuevas sesiones con 421. Esto es común con grandes proveedores de buzones, pasarelas corporativas y relays compartidos de salida.
• Limitación local: Tu propio MTA (o un relay/intermediario/balanceador) limita conexiones—por ejemplo, Postfix smtpd_client_connection_count_limit para entrada, o servicios de políticas que te devuelven 421 a propósito.

La consecuencia operativa es la misma: reintentos. Los reintentos generan crecimiento de la cola. La cola creciente crea más presión de concurrencia a menos que la modeles. Ese es el bucle que estás aquí para romper.

Una cita útil para anotar: “La esperanza no es una estrategia.” — Gene Kranz. Si estás “esperando a que se despeje”, estás practicando una gestión de congestión sin control.

Broma #1: SMTP es el único protocolo donde “inténtalo más tarde” se considera una característica, no un bug.

Guía rápida de diagnóstico

Cuando suena el pager, no necesitas filosofía. Necesitas responder tres preguntas en orden:

1) ¿El 421 viene del servidor remoto o de nosotros?

Mira la transcripción SMTP en los logs. Si Postfix dice “host mx.remote.tld said: 421 …”, eso es limitación remota. Si tu propio smtpd emite 421 a clientes, eso es limitación local.

2) ¿Qué está saturando: conexiones, ancho de banda, CPU, disco o DNS?

Los límites de conexión suelen ser un síntoma. El verdadero cuello de botella podría ser:

• DNS lento que provoca sesiones SMTP de larga duración.
• Coste del handshake TLS y picos de CPU.
• Latencia de I/O en disco que causa contención en archivos de cola.
• Limitación específica del proveedor por IP/subred.

3) ¿Los reintentos están amplificando el problema?

Si tu política de reintentos es demasiado agresiva (o la concurrencia demasiado alta), generas una tormenta de reintentos: más sesiones → más 421 → más cola → más sesiones. Quieres un goteo controlado, no una manguera a presión apuntando a una puerta cerrada.

Acciones rápidas que suelen ser seguras

• Reduce la concurrencia por destino (no la global) para el proveedor/dominio afectado.
• Aumenta la reutilización de conexiones (mantén sesiones abiertas y envía más por sesión).
• Retrocede ligeramente la programación de reintentos para ese destino para no golpear sus límites.
• Confirma que latencia DNS/TLS y I/O de disco no sean los culpables ocultos.

Datos interesantes y contexto histórico (porque los sistemas tienen memoria)

1. SMTP nació antes de la web: SMTP se estandarizó a principios de los años 80, cuando “alto tráfico” significaba otra cosa.
2. 421 es deliberadamente vago: Es una clase de fallo temporal diseñada para “vuelve más tarde”, no para diagnóstico exacto.
3. Los fallos temporales son la columna vertebral de la fiabilidad del correo: El modelo store-and-forward asume que las redes fallan y los MTAs reintentan.
4. Los límites de conexión se normalizaron con el spam: Los proveedores empezaron a limitar por IP porque los spammers abusaban de la concurrencia ilimitada.
5. El diseño de Postfix es explícitamente modular: Múltiples demonios con límites de procesos controlados, para evitar el modo fallo de “un único mailer grande”.
6. El greylisting popularizó los temporales controlados: Muchos sistemas usaron fallos temporales para filtrar spam; los MTAs legítimos reintentan.
7. El ajuste “por destino” existe porque Internet es desigual: Algunos dominios aceptan alta paralelización; otros colapsan con dos conexiones.
8. TLS elevó el coste de la conexión: SMTP sobre TLS añade CPU y latencia; la reutilización de conexiones pasó a ser crítica.

Un modelo mental útil: concurrencia, sesiones y colas

Piensa en tu sistema de correo saliente como un muelle de carga:

• La cola es tu almacén.
• Las sesiones SMTP son camiones en las puertas de carga.
• La concurrencia es cuántas bahías abres a la vez.
• Los límites de conexión remotos son el almacén receptor diciendo “dejad de enviar camiones; no podemos descargar tantos”.

Cuando recibes 421 demasiadas conexiones, estás enviando más camiones de los que la otra parte quiere. Si respondes “abriendo más bahías” (aumentando la concurrencia global), solo generarás más camiones rechazados. Si respondes “cerrando todo el muelle” (throttling global), retrasarás todo, incluyendo correos que podrían haberse entregado rápido a otros dominios.

Así que quieres modelado dirigido:

• Limita la concurrencia por destino (dominio, MX o host relay).
• Mantén las sesiones eficientes (envía varios mensajes por conexión).
• Mantén la cola sana (evita estampidas; prioriza correo reciente si hace falta).

Broma #2: El correo es como el tráfico: añadir carriles (concurrencia) funciona hasta que todos deciden usar la misma salida (un gran proveedor).

Tareas prácticas (comandos + qué significa la salida + qué decides)

Estas tareas asumen Postfix en Linux. Ajusta rutas y nombres de servicio si estás en otra distro. Cada tarea te da: un comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Confirmar el texto exacto del 421 y si es remoto

cr0x@server:~$ sudo grep -R "421" /var/log/mail.log | tail -n 5
Jan 04 09:12:19 mx1 postfix/smtp[19822]: 9A1C12E3F4: to=<user@example.com>, relay=mx.example.com[203.0.113.20]:25, delay=12, delays=0.1/0.2/5.3/6.4, dsn=4.3.2, status=deferred (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)
Jan 04 09:12:20 mx1 postfix/smtp[19825]: 0B3E99F1A2: to=<user@example.com>, relay=mx.example.com[203.0.113.20]:25, delay=10, delays=0.1/0.2/4.5/5.2, dsn=4.3.2, status=deferred (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)

Significado: “host … said” indica que el servidor remoto devolvió 421. Tu Postfix se está comportando; te están limitando.

Decisión: Enfócate en la concurrencia por destino y la reutilización de conexiones, no en límites de entrada.

Task 2: Identificar qué destinos causan más diferidos

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /status=deferred/{print id, $0}' | head
9A1C12E3F4 (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)
0B3E99F1A2 (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)

Significado: Tu backlog contiene correo diferido con 421. No es aleatorio; se agrupa.

Decisión: Crea una política de limitación para ese dominio/proveedor en vez de ralentizar todo el envío saliente.

Task 3: Contar razones de diferido a escala (top N)

cr0x@server:~$ sudo postqueue -p | sed -n 's/.*status=deferred (//p' | sed 's/)$//' | sort | uniq -c | sort -nr | head
  418 host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later
   52 connect to mx.other.tld[198.51.100.10]:25: Connection timed out
   11 host mx.third.tld[192.0.2.55] said: 450 4.2.0 Mailbox busy

Significado: 421 domina. También hay timeouts, pero no son la noticia principal.

Decisión: Aborda el 421 primero; no te distraigas con ruidos menores a menos que sea otro incidente.

Task 4: Comprobar cuántos procesos cliente SMTP estás ejecutando

cr0x@server:~$ ps -eo pid,comm,args | grep -E "postfix/smtp" | grep -v grep | wc -l
74

Significado: Tienes 74 procesos activos de entrega saliente. Puede estar bien, o puede ser un problema si 60 de ellos están golpeando un proveedor.

Decisión: Si un destino está limitando, reduce el paralelismo para ese destino en lugar de recortar el número global a ciegas.

Task 5: Ver conexiones activas a puerto 25/587 y a quién van

cr0x@server:~$ sudo ss -ntp '( dport = :25 or dport = :587 )' | head -n 15
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port Process
ESTAB  0      0      10.0.0.10:53422     203.0.113.20:25   users:(("smtp",pid=19822,fd=12))
ESTAB  0      0      10.0.0.10:53426     203.0.113.20:25   users:(("smtp",pid=19825,fd=11))
ESTAB  0      0      10.0.0.10:53430     203.0.113.20:25   users:(("smtp",pid=19826,fd=13))

Significado: Muchas conexiones al mismo IP sugieren que estás provocando límites por IP o por cliente.

Decisión: Limita la concurrencia a ese relay/destino y aumenta el rendimiento por conexión.

Task 6: Comprobar valores por defecto de concurrencia por destino en Postfix

cr0x@server:~$ sudo postconf | egrep "default_destination|smtp_destination|initial_destination"
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = $default_destination_concurrency_limit
initial_destination_concurrency = 5

Significado: Por defecto puedes llegar a 20 entregas concurrentes por destino (según versión/config). Eso es agresivo para algunos proveedores.

Decisión: Si el límite remoto es menor (a menudo lo es), necesitas un tope más bajo para ese destino.

Task 7: Inspeccionar uso de transport map (¿ya enrutas a través de un relay?)

cr0x@server:~$ sudo postconf | egrep "transport_maps|relayhost"
transport_maps =
relayhost =

Significado: Estás entregando directamente a los hosts MX de los destinatarios. Las políticas de limitación deben aplicarse por dominio/MX.

Decisión: Considera usar transport maps para destinos problemáticos y aplicar límites por transporte de forma limpia.

Task 8: Comprobar si Postfix está reutilizando conexiones SMTP

cr0x@server:~$ sudo postconf | egrep "smtp_connection_cache|smtp_destination_recipient_limit|smtp_extra_recipient_limit"
smtp_connection_cache_destinations =
smtp_destination_recipient_limit = 50
smtp_extra_recipient_limit = 1000

Significado: El caché de conexiones puede estar deshabilitado (vacío). Sin caching, pagas una nueva conexión por proceso de entrega, aumentando la presión de concurrencia.

Decisión: Habilita el caché de conexiones para el destino o relay limitado para enviar más mensajes por sesión.

Task 9: Comprobar comportamiento de reintentos y backoff (¿reintentas demasiado agresivo?)

cr0x@server:~$ sudo postconf | egrep "minimal_backoff_time|maximal_backoff_time|queue_run_delay"
queue_run_delay = 300s
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Significado: Los reintentos empiezan en 5 minutos y crecen hasta ~66 minutos. Si los has tuneado a valores menores, puedes crear una tormenta de reintentos.

Decisión: Para un destino que dice “demasiadas conexiones”, el backoff es tu amigo. No pongas minimal_backoff a 10 segundos y esperes respeto.

Task 10: Comprobar latencia DNS (un multiplicador de concurrencia engañoso)

cr0x@server:~$ time dig +tries=1 +timeout=2 mx example.com @127.0.0.53
;; ANSWER SECTION:
example.com.     1800 IN MX 10 mx.example.com.

real    0m0.018s
user    0m0.004s
sys     0m0.004s

Significado: El DNS es rápido aquí. Si esto toma cientos de milisegundos o falla, tus procesos SMTP quedan bloqueados esperando, incrementando la superposición y la concurrencia percibida.

Decisión: Si el DNS es lento, arregla el rendimiento del resolvedor/caching antes de tocar perillas de concurrencia.

Task 11: Comprobar coste y fallos de handshake TLS

cr0x@server:~$ sudo grep -E "TLS|SSL" /var/log/mail.log | tail -n 5
Jan 04 09:12:18 mx1 postfix/smtp[19822]: Trusted TLS connection established to mx.example.com[203.0.113.20]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
Jan 04 09:12:19 mx1 postfix/smtp[19825]: Trusted TLS connection established to mx.example.com[203.0.113.20]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

Significado: TLS funciona y es moderno. Si ves fallos repetidos de handshake o negociaciones lentas, las sesiones duran más y se amontonan.

Decisión: Si TLS está inestable, estabilízalo (cifras, SNI, cadena de certificados, problemas de MTU) antes de asumir que “demasiadas conexiones” es solo una política.

Task 12: Comprobar latencia de disco y salud del directorio de cola

cr0x@server:~$ iostat -xz 1 3
Linux 6.2.0 (mx1)  01/04/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.44    0.80    0.00   94.64

Device            r/s     w/s   rkB/s   wkB/s  %util  await
nvme0n1          3.00   55.00   120.0  2400.0   6.40   1.20

Significado: Await y util bajos. El disco no está estrangulando. Si await sube a decenas/centenas de ms, las operaciones de cola de Postfix se ralentizan y tu patrón de entrega se vuelve abrasivo—exactamente lo que dispara límites remotos.

Decisión: Si el disco es el cuello de botella, arregla el almacenamiento (aislamiento de I/O, medios más rápidos, tuning del sistema de ficheros) antes de “ajustar concurrencia”.

Task 13: Comprobar contadores de limitación de Postfix (anvil)

cr0x@server:~$ sudo postconf | egrep "smtpd_client_connection_count_limit|smtpd_client_connection_rate_limit|anvil_rate_time_unit"
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 0
anvil_rate_time_unit = 60s

Significado: Estos son controles de entrada, pero importan si actúas como relay para apps internas. Si tus apps reciben 421 de tu Postfix, estos ajustes son sospechosos.

Decisión: Si clientes internos alcanzan tus límites, escala horizontalmente o aplica pooling en el cliente; no subas estos valores sin estar seguro de que el relay puede manejarlo.

Task 14: Confirmar si el tráfico afectado está concentrado en un remitente/app

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 30
Grand Totals
------------
messages
  12450   received
  12110   delivered
  310     deferred  (2.4%)
...
Per-Sender Totals
-----------------
  8200   noreply@service.local
  2400   billing@service.local

Significado: Un remitente domina. Si “noreply@service.local” es un emisor masivo, sus picos pueden ahogar correo transaccional.

Decisión: Separa el tráfico por transportes (transaccional vs masivo), da prioridad al transaccional y aplica throttling más fuerte al masivo.

Task 15: Verificar tamaño de la cola y distribución por antigüedad

cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f | wc -l
1832

Significado: El conteo de diferidos es un proxy rápido para el problema. El riesgo real es la antigüedad: si el correo se queda demasiado, incumples SLA y confundes usuarios.

Decisión: Si el número de diferidos sube y las edades aumentan, necesitas throttling + priorización ahora, no después.

Task 16: Inspeccionar cabeceras de un mensaje atascado (ruteo, destinatario, transporte)

cr0x@server:~$ sudo postcat -q 9A1C12E3F4 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size: 4289
recipient: user@example.com
sender: noreply@service.local
*** MESSAGE CONTENTS ***
Received: by mx1 (Postfix, from userid 1001)
Date: Sat, 04 Jan 2026 09:11:58 +0000
Subject: Your login code

Significado: Esto muestra remitente, destinatario y metadatos básicos. Útil para confirmar si es correo transaccional que no debe retrasarse.

Decisión: Si es transaccional, enrútalo por un transporte de mayor prioridad con concurrencia segura y mejores controles de reputación.

Ajustar Postfix de forma correcta (sin retrasar correos)

Principio 1: No “arregles” un problema por destino con un throttle global

Los cambios globales como bajar default_destination_concurrency_limit pueden reducir los 421, claro. También ralentizan la entrega para todos, incluidos dominios que estaban felices. Así es como conviertes la política de un proveedor en un outage universal.

Principio 2: Haz menos conexiones pero mejores

Los límites remotos suelen basarse en conexiones concurrentes. Si reutilizas conexiones y envías múltiples destinatarios/mensajes por sesión, reduces el churn de conexiones y sigues moviendo volumen.

Perillas concretas que suelen importar

1) Límites de concurrencia por destino (la palanca grande)

En Postfix, puedes limitar la concurrencia por destino. Si entregas directamente, “destino” suele ser el dominio (y a veces el host MX, dependiendo de cómo Postfix agrupe entregas). El patrón más seguro en entornos corporativos es usar transport maps para crear “canales” explícitos para grandes proveedores.

Enfoque de ejemplo: enruta un dominio específico (o un conjunto de dominios) a través de un transporte nombrado, y aplica límites a ese transporte en master.cf.

cr0x@server:~$ sudo postconf -n | egrep "transport_maps"
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo tee /etc/postfix/transport > /dev/null
example.com      slowmx:
example.net      slowmx:

cr0x@server:~$ sudo postmap /etc/postfix/transport

Luego en /etc/postfix/master.cf, define el transporte con menor concurrencia. (Este es el patrón; ajusta valores a tu entorno.)

cr0x@server:~$ sudo postconf -M | grep -E "^slowmx"
slowmx/unix=slowmx unix - - n - - smtp

Significado: Un transporte dedicado te permite fijar concurrencia y comportamiento distinto para un subconjunto de correo. Ya no tratas todos los destinos por igual.

Decisión: Si un proveedor te está limitando, aíslalo en su propio transporte y ajústalo independientemente.

2) Caché de conexiones (reutilización)

El caché de conexiones mantiene una sesión SMTP abierta para reutilizarla. Eso significa menos handshakes TCP, menos handshakes TLS, menos probabilidades de chocar con políticas de “máx conexiones”.

cr0x@server:~$ sudo postconf -e "smtp_connection_cache_destinations = example.com example.net"

Significado: Postfix cacheará conexiones para esos destinos cuando sea posible.

Decisión: Habilita caching para destinos limitados, especialmente cuando tu tráfico es en ráfagas (restablecimientos de contraseña, notificaciones, facturas).

3) Balancear límites de destinatarios por conexión

Los proveedores suelen aceptar una sesión con múltiples entregas pero rechazan sesiones paralelas múltiples. Haz que cada sesión haga más trabajo, con moderación.

cr0x@server:~$ sudo postconf -n | egrep "smtp_destination_recipient_limit"
smtp_destination_recipient_limit = 50

Significado: Hasta 50 destinatarios por destino por petición de entrega, dependiendo de la estructura de la cola y el batching. Muy alto puede causar transacciones grandes que fallen a mitad de sesión; muy bajo aumenta el conteo de sesiones.

Decisión: Si alcanzas límites de conexión y los mensajes son pequeños, aumentar modestamente el batching puede reducir sesiones. No lo pongas a 1000 y luego te sorprendas cuando un destinatario problemático ralentice todo el lote.

4) Haz que los reintentos sean menos tontos para el destino limitado

Si el remoto dice “demasiadas conexiones”, reintentar en 30 segundos es básicamente discutir con un firewall. Modela tus reintentos para que el sistema deje de estamparse solo.

cr0x@server:~$ sudo postconf -n | egrep "minimal_backoff_time|maximal_backoff_time"
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Significado: Esto es global. Los cambios globales afectan a todos los destinos.

Decisión: Prefiere control por transporte (cola/transporte separado) si necesitas comportamiento de reintentos especial para un proveedor; mantén el reintento global sano y aburrido.

Qué no hacer (a menos que te gusten los incidentes recurrentes)

• No aumentes la concurrencia global para “forzar” entrega. 421 no es un problema de ancho de banda; es un problema de coordinación.
• No desactives TLS para acelerar handshakes. Cambiarás un problema de colas por un incidente de seguridad y daño de reputación.
• No “arregles” añadiendo más MTAs detrás de la misma IP NAT. Los límites remotos suelen ser por IP origen. Solo paralelizarás los rechazos.

Cuando el remoto te está limitando

La limitación remota suele ser impulsada por políticas. La parte remota puede limitar:

• Sesiones concurrentes por IP remitente
• Mensajes por minuto/hora por IP o por cuenta autenticada
• Destinatarios por mensaje
• Conexiones por minuto (no solo concurrentes)
• Tasa por reputación, tasa de quejas, tasa de rebotes o categoría de contenido

Cómo distinguir “límite por política” de “sobrecarga remota”

Los límites por política tienden a ser consistentes y limpios: alcanzas un techo y el error se repite de forma predecible. La sobrecarga remota suele correlacionar con hora del día, ventanas de mantenimiento remotas o aumentos esporádicos de latencia/timeouts.

Busca estos patrones en tus logs:

• Muchos diferidos rápidos con 421 justo después de conectar: límite por política clásico.
• Largos retrasos luego 421: el remoto puede aceptar y luego descargar carga; puede ser su sistema bajo estrés o tu lentitud TLS/DNS provocando sesiones largas.
• Mezcla de 421 + timeouts: puede ser problemas de red o limitación remota más degradación.

Juego operativo: aislar, modelar y mantener el correo transaccional en movimiento

En sistemas reales, a menudo tienes dos clases de correo:

• Transaccional: códigos de un solo uso, MFA, recibos. Los usuarios notan en segundos.
• Masivo/engagement: newsletters, recordatorios, campañas. Los usuarios lo notan… eventualmente, tal vez.

Cuando te limitan, tu mejor movimiento es separar transportes y aplicar distintas estrategias de concurrencia y reintento. Lo transaccional obtiene el carril limpio: concurrencia estable, reutilización de conexiones, reintentos conservadores y buena higiene de reputación. Lo masivo recibe mayor throttling y programación.

Modos de fallo que parecen concurrencia (pero no lo son)

DNS lento: el extensor silencioso de sesiones

Si las búsquedas DNS para registros MX o las comprobaciones de reverse DNS son lentas, cada intento de entrega dura más, lo que aumenta el número de intentos solapados. No incrementaste la concurrencia; el tiempo lo hizo.

Contención de disco: las operaciones de cola se vuelven en ráfagas

En discos sobrecargados, Postfix no puede mover archivos de cola eficientemente. Los procesos de entrega se programan en grupos. Los grupos crean picos. Los picos disparan limitaciones. Ves 421 y culpas al proveedor, pero tu almacenamiento es el que empuja.

Suposiciones rotas sobre reutilización de conexiones

Algunos gateways NAT, firewalls o middleboxes no soportan sesiones SMTP de larga duración. Si reinician conexiones inactivas agresivamente, el caching no funciona y vuelves al comportamiento de “tormenta de conexiones”.

Asimetría IPv6 vs IPv4

Los proveedores pueden aplicar límites distintos en rangos IPv6. Si tu MTA alterna entre familias, puedes ver comportamientos inconsistentes. A veces la “solución” es hacer el camino consistente, no necesariamente más rápido.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición errónea

La compañía tenía una arquitectura ordenada: los servidores de app enviaban correo a un relay interno, que entregaba directo a Internet. Funcionó durante años, sobre todo porque el tráfico era modesto y predecible.

Luego el negocio lanzó una “mejora de seguridad”: cada inicio de sesión requería un código por email. El equipo asumió que el correo se comportaría como sus APIs HTTP—escalar, aumentar la concurrencia y ver subir el throughput. Hicieron lo que hace la gente web: aumentaron el número de workers. Más procesos cliente SMTP, más intentos de entrega paralelos.

En una hora, los grandes proveedores de buzones empezaron a devolver 421 demasiadas conexiones. La cola se infló. Los usuarios pidieron más códigos porque no llegaban, lo que generó más correo, más reintentos. Bucle de retroalimentación clásico, ahora con ansiedad del cliente añadida.

La suposición errónea no fue “los proveedores son malos”. Fue creer que SMTP es un protocolo push donde el receptor no impone reglas. La concurrencia se negocia socialmente, no técnicamente.

La solución fue aburrida: separar transportes para los proveedores principales, limitar la concurrencia por destino a niveles que estuvieran por debajo de sus límites y habilitar caching de conexiones. Los códigos de login empezaron a llegar más rápido porque el sistema dejó de gastar esfuerzo en sesiones rechazadas.

Micro-historia 2: La optimización que salió mal

Otra organización quería métricas de entrega más rápidas. Alguien notó que el correo en cola a veces esperaba unos minutos, así que ajustaron Postfix para ejecutar la cola más frecuentemente y redujeron los backoffs. Las gráficas se vieron bien durante una semana.

Entonces incorporaron un nuevo cliente con una pasarela de correo corporativa estricta sobre conteos de conexión. El MTA empezó a recibir 421. Con backoff reducido, el MTA reintentó agresivamente. La pasarela interpretó eso como abuso y endureció aún más los límites.

La entrega pasó de “a veces retrasada” a “constantemente retrasada”. Peor aún, los reintentos agresivos aumentaron el churn de conexiones, elevando handshakes TLS y CPU, lo que ralentizó otras entregas. El monitoreo interno gritó “errores SMTP” mientras producto gritaba “bajas en registros de usuarios”.

La optimización falló porque trató fallos temporales como algo para arrollar. En el mundo SMTP, la retirada educada no es opcional; es cómo evitas autodenegación de servicio.

Revirtieron los ajustes globales de reintento, crearon un transporte separado para el dominio de ese cliente con concurrencia estricta (y backoff algo mayor), y el resto del sistema se recuperó de inmediato.

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

Un equipo tenía la costumbre: cada vez que añadían una nueva fuente de correo, la etiquetaban con un remitente de sobre único y registraban la identidad de envío en la presentación. No era sofisticado. Solo consistente. La mayoría de ingenieros lo consideraban “proceso extra”.

Durante un incidente 421, esa práctica se volvió oro. Determinaron rápidamente que el 90% del tráfico limitado provenía de un job de lote recién desplegado que enviaba correos de conciliación de cuentas. Se suponía que correría cada hora. Estaba corriendo cada cinco minutos por una mala configuración del scheduler.

No tocaron Postfix al principio. Pausaron el job de lote, dejaron drenar la cola y luego reintrodujeron el tráfico con un transporte dedicado y concurrencia estricta por destino. El correo transaccional obtuvo su propio carril con caching de conexiones y límites estables.

Porque tenían atribución limpia, evitaron el desastre común: “afinar el servidor de correo hasta que el síntoma desaparezca”, mientras el problema real seguía generando presión. La cola se vació, las limitaciones cesaron y nadie tuvo que explicar a cumplimiento por qué deshabilitaron TLS en pánico.

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

1) Síntoma: “421 demasiadas conexiones” en todas partes

Causa raíz: Cambiaste la concurrencia global y ahora múltiples proveedores te limitan, o estás detrás de una IP compartida con reputación limitada.

Solución: Revierte cambios globales. Separa transportes por grupos de destinos importantes. Si usas un smarthost, asegúrate de no exceder los límites por cuenta de ese smarthost.

2) Síntoma: La cola crece, pero CPU y red parecen bien

Causa raíz: Te están rechazando rápido (diferidos 421 rápidos), así que no estás consumiendo recursos—solo generando reintentos.

Solución: Baja concurrencia por destino y habilita caching de conexiones; ajusta el batching para que cada sesión exitosa transporte más correo.

3) Síntoma: Picos de 421 solo en horas punta

Causa raíz: Envíos en ráfaga (cron jobs, campañas) colisionando con límites temporales del proveedor.

Solución: Modela el envío masivo; programa picos; implementa límites por transporte y prioriza tráfico transaccional.

4) Síntoma: Bajaste la concurrencia y ahora el correo llega lento a todos los dominios

Causa raíz: Aplicaste un throttle global en vez de aislar el destino que se quejó.

Solución: Restaura valores globales. Usa transport maps/master.cf para aplicar límites estrictos solo al dominio/proveedor afectado.

5) Síntoma: Muchas conexiones, pocos mensajes por conexión

Causa raíz: Caché de conexiones deshabilitado, o middleboxes que matan conexiones inactivas; también posible que la estructura de la cola impida batching.

Solución: Habilita caching para esos destinos, verifica timeouts de firewalls y asegúrate de que tu MTA pueda agrupar destinatarios apropiadamente.

6) Síntoma: 421 acompañado de timeouts y “lost connection”

Causa raíz: Problemas en la ruta de red, agujeros MTU, o inestabilidad remota; a veces te están tarpitteando por reputación.

Solución: Valida salud de red (pérdida de paquetes, retransmisiones), verifica estabilidad TLS y reduce concurrencia mientras investigas señales de reputación.

7) Síntoma: Apps internas reciben 421 al enviar al relay

Causa raíz: Tus propios límites de conexión entrante (anvil) están protegiendo del cliente ruidoso.

Solución: Arregla el cliente (pooling, menos envíos paralelos), o escala relays horizontalmente; sube límites solo si estás seguro de que el relay lo aguanta.

Listas de verificación / plan paso a paso

Paso a paso: arreglar 421 sin retrasar correo

1. Clasifica la fuente del 421. Confirma remoto vs local desde los logs. Si es remoto, sigue. Si es local, revisa smtpd_* y servicios de políticas.
2. Clasifica destinos por dolor. Cuenta las principales razones de diferido e identifica qué dominios/proveedores dominan.
3. Protege primero el correo transaccional. Si mezclas masivo y transaccional, sepáralos ahora. Mismo servidor está bien; mismo comportamiento de cola no lo está.
4. Crea un transporte dedicado para el(los) destino(s) limitados. Los transport maps te dan una palanca que puedes mover sin dañar colateralmente.
5. Reduce la concurrencia en ese transporte. Empieza conservador. Si el proveedor permite 2–5 sesiones concurrentes, prueba 2–3 y mide.
6. Habilita cache de conexiones para ese destino/transporte. Menos sesiones, más carga por sesión.
7. Valida latencia DNS y TLS. Búsquedas lentas y handshakes inflan la duración de sesión y la concurrencia percibida.
8. Observa la antigüedad de la cola, no solo el tamaño. Puedes tolerar una cola más grande si se drena de forma continua y el correo se mantiene joven.
9. Ajusta el batching con cuidado. Aumenta destinatarios por sesión modestamente si los mensajes son pequeños y las fallas raras.
10. Verifica que los reintentos se calmen. La meta es menos sesiones rechazadas y más entregas exitosas, no “menos líneas en el log”.
11. Tras estabilizar, documenta el límite. Anota el tope de concurrencia efectivo que funciona. El futuro tú lo olvidará.
12. Añade monitorización de diferidos por destino. Detecta el próximo throttle antes de que se convierta en montaña de cola.

Checklist operativa: qué monitorizar continuamente

• Tamaño de la cola de diferidos y distribución por antigüedad
• Principales razones de diferido (421 vs timeouts vs 5xx)
• Conexiones salientes por IP/dominio de destino
• Tasa de entrega SMTP (entregados/min) por transporte
• Latencia y tasa de errores del resolvedor DNS
• Latencia de I/O de disco en el filesystem del spool MTA
• Utilización CPU y tasa de handshakes TLS

Preguntas frecuentes

1) ¿421 es un fallo permanente?

No. Es un fallo temporal. Tu MTA debe diferir y reintentar. La cuestión es si tu comportamiento de reintento está controlado o es caótico.

2) ¿Por qué los proveedores limitan conexiones en vez de mensajes?

Las conexiones son caras: estado TCP, handshakes TLS y escaneo por sesión. Limitar sesiones concurrentes es una forma efectiva de proteger infraestructura contra picos y abuso.

3) ¿Debería simplemente bajar default_destination_concurrency_limit?

Solo si te gusta ralentizar el correo a destinos que no se quejaban. Usa ajuste por transporte o por destino para que el tope de un proveedor no sea tu tope global.

4) ¿Qué tan baja debería ser la concurrencia por destino?

Suficientemente baja para detener 421s, y lo bastante alta para cumplir objetivos de entrega. Empieza con 2–5 para proveedores estrictos, luego sube despacio mientras observas diferidos y antigüedad de cola.

5) ¿Habilitar cache de conexiones siempre ayuda?

A menudo sí—especialmente con TLS. Pero puede verse socavado por firewalls que matan sesiones inactivas. Si el caching no reduce nuevas conexiones, revisa timeouts de middleboxes.

6) ¿Por qué reducir concurrencia hizo que algunos correos llegaran más rápido?

Porque dejaste de desperdiciar intentos. Las sesiones exitosas entregan correo; las sesiones rechazadas generan reintentos y churn. Menos concurrencia puede significar más throughput útil.

7) ¿Y si el 421 ocurre cuando las apps se conectan a nuestro relay (entrada), no en salida?

Entonces son tus límites de relay los que limitan conexiones cliente (o un servicio de políticas). Investiga ajustes de anvil de Postfix, comportamiento del cliente y si una app abre cientos de sesiones SMTP paralelas.

8) ¿Puedo arreglar esto añadiendo más MTAs?

Solo si además añades más IPs origen y gestionas reputación responsablemente. Si todo sale por una única IP NAT, más MTAs solo significan más conexiones rechazadas por segundo.

9) ¿IPv6 cambia algo?

Sí. Algunos proveedores aplican políticas distintas a IPv6. Asegura que tu ruta saliente sea consistente y que reverse DNS y reputación estén configurados correctamente para la familia que uses.

10) ¿Cómo evito que el correo masivo deje sin servicio al transaccional?

Separa transportes (o incluso relays separados), aplica throttles estrictos al masivo y mantén el correo transaccional en una ruta prioritaria con límites previsibles y caching.

Conclusión: próximos pasos prácticos

“421 demasiadas conexiones” es control de congestión con gabardina. Tu trabajo es dejar de tratarlo como un misterio y empezar a modelar tráfico como un sistema adulto.

1. Confirma si el 421 es remoto o local mirando la redacción en los logs.
2. Identifica el(los) destino(s) principales que causan diferidos.
3. Separa el tráfico: transaccional vs masivo, y aísla grandes proveedores en transportes dedicados.
4. Baja la concurrencia por destino para el grupo limitado y habilita caching de conexiones.
5. Valida DNS, TLS e I/O de disco para no amplificar concurrencia por accidente.
6. Mide la antigüedad de la cola y entregas exitosas, no solo la ausencia de errores.

Haz eso, y dejarás de jugar al whack-a-mole con los 421. El correo no solo “se entregará eventualmente”. Se entregará a tiempo, con menos conexiones y sin tanto drama—que es el mayor cumplido que pueden recibir los sistemas en producción.