El ticket llega con el mismo tono cada vez: “Correo rebotado — demasiados destinatarios.”
El asistente ejecutivo está furioso. El equipo de RR. HH. no puede contactar al personal. Un sistema de monitorización no está alertando porque su lista de notificación fue “optimiziada” a un único correo monstruoso.
Y en algún lugar en segundo plano, un atacante (o simplemente un empleado demasiado entusiasta) está intentando pulverizar tu dominio con correo saliente hasta que la reputación de tu IP parezca un incendio. Tu trabajo es detener el abuso sin romper los envíos masivos legítimos que tu negocio realmente necesita.
Qué significa realmente “demasiados destinatarios” (y por qué existe)
“Demasiados destinatarios” no es un único error. Es una familia de límites, aplicados en capas distintas por diferentes razones:
proteger servidores, proteger reputaciones, prevenir abusos, mantener las colas manejables y evitar que las personas envíen por accidente a todos los clientes dos veces.
Dependiendo de dónde te topes con el límite, verás distintos códigos SMTP y comportamientos distintos:
- Durante la transacción SMTP (fase RCPT TO): El servidor receptor rechaza destinatarios adicionales. Respuestas típicas:
452 4.5.3 Too many recipients,550 5.5.3 Too many recipients, o texto específico del proveedor. - Antes de SMTP (política de envío): Tu servicio de envío (Exchange, Postfix submission, gateway en la nube) rechaza el mensaje según la política, límites por remitente o topes por destinatario.
- Después de la aceptación (regla de transporte/política): El mensaje se acepta y luego se aplaza, cuarentena o rebota porque la expansión (listas de distribución) hace que exceda la política.
- Lado de la aplicación: Tu biblioteca de la app (o el proveedor de API) rechaza la petición porque excediste destinatarios por mensaje o límites de lote por solicitud.
Los límites no son opcionales. Sin ellos, los sistemas de correo se convierten en cañones baratos para spammers y en calefactores caros para tu CPU. Los topes de destinatarios son uno de los pocos controles que a la vez reducen abuso y previenen que el correo “legítimo” funda tu infraestructura.
Una cita que vale la pena tener en la pared:
La esperanza no es una estrategia.
— Gene Kranz
Broma #1: Los sistemas de correo son como los ascensores: si intentas meter 200 personas, igual solo bajarás.
Datos interesantes y contexto histórico (rápido y concreto)
- SMTP originalmente asumía pares amigables. La arquitectura temprana de correo trataba a la mayoría de participantes como cooperativos; las fuertes barreras anti-abuso llegaron después, cuando el spam se convirtió en un modelo de negocio.
- RFC 5321 establece expectativas, no tu política. Los estándares SMTP definen la mecánica de la conversación; los límites de destinatarios quedan explícitamente a las implementaciones y a la política local.
- Las listas de distribución cambiaron el radio de impacto. Una vez que la expansión de listas se volvió común, una sola dirección “Para:” podía significar miles de entregas descendentes, saturando colas y reputación.
- “Demasiados destinatarios” suele ser un 4xx, no un 5xx. Muchos sistemas difieren en vez de rechazar permanentemente para evitar perder correo legítimo durante picos de carga transitorios.
- Los límites de destinatarios son anti-abuso y anti-fallo de configuración. Un bug que recorre una tabla de contactos puede generar un solo mensaje con miles de comandos RCPT; los límites detienen la hemorragia temprano.
- Algunos proveedores cuentan destinatarios expandidos y otros no. El “50 destinatarios” de un sistema puede significar “50 comandos RCPT” mientras que otro quiere decir “50 después de la expansión de listas”. Esa diferencia arruina migraciones.
- Los grandes conteos de destinatarios afectan TLS y CPU. La transacción SMTP puede estar bien, pero las comprobaciones por destinatario, la firma DKIM y el escaneo de contenido aumentan el coste por cada dirección.
- La reputación es por identidad de envío, no por intención. Los ISP no distinguen si tu envío a 5.000 destinatarios fue un “aviso de seguridad” o un “ups”; ven volumen y quejas.
- Los MTAs clásicos fueron diseñados para store-and-forward. Por eso puedes “aceptar ahora, entregar después” en una cola. Es resiliencia—pero también donde se ocultan los atascos.
Un modelo práctico: dónde aparecen los límites de destinatarios
1) El remitente (aplicación o usuario)
Tu CRM, herramienta de monitorización, plataforma de RR. HH. e incluso un cron job pueden generar correo. Muchas de estas herramientas piensan que “correo” significa “una llamada API” y con gusto colocarán 2.000 destinatarios en un solo mensaje porque es fácil.
También es la forma en que te bloquean.
Los límites en la aplicación aparecen como errores antes de que el correo salga: “demasiados destinatarios por mensaje”, “tamaño de lote excedido”, “solicitud rechazada.”
Estos son los más fáciles de arreglar: cambia el comportamiento para fragmentar destinatarios, o pasa a un patrón de envío masivo que genere un destinatario por mensaje.
2) Envío y política saliente (donde los adultos ponen las reglas)
Los servidores de envío (SMTP autenticado, transporte de Exchange, gateway de correo en la nube) son el lugar correcto para aplicar límites por usuario y por app.
Si no impones límites aquí, dejas que cada portátil y cada contraseña comprometida decida la reputación de tu remitente.
Controles comunes:
- Límite de destinatarios por mensaje (tope rígido).
- Límite de tasa por remitente (mensajes por minuto).
- Límite de tasa de destinatarios por remitente (destinatarios por minuto) — mejor para patrones masivos.
- Políticas por dominio de destinatario (interno vs externo).
- Escaneo de contenido y DLP que pueden escalar mal con el número de destinatarios.
3) El MTA (Postfix/Exchange/etc.) y la cola
La mayoría de las interrupciones no provienen de “un gran correo.” Provienen de lo que ese correo hace a tu cola:
multiplica trabajo. Si tu sistema se descompone en entregas por destinatario, obtienes más entradas en la cola, más consultas DNS, más handshakes TLS, más reintentos.
Un límite de destinatarios puede estar protegiendo tu cola de un efecto de manada. O puede estar ocultando otro cuello de botella: DNS roto, puerto 25 bloqueado, un relay malo o un filtro de contenido que se cuelga bajo carga.
4) Receptores aguas abajo (la parte que no controlas)
Incluso si tu infraestructura acepta y encola el mensaje, los receptores pueden aplicar sus propios límites RCPT, topes por conexión, cuotas diarias o políticas anti-spam.
Tu “demasiados destinatarios” puede ser su “no aceptamos 100 comandos RCPT en una conexión.”
Guía de diagnóstico rápido: encuentra el cuello de botella pronto
Cuando “demasiados destinatarios” golpea producción, no empieces por cambiar límites. Empieza por encontrar qué límite y quién lo aplica.
Luego decide si debes subir el techo o bajar el comportamiento.
Primero: identifica el punto de aplicación (remitente, envío, MTA, aguas abajo)
- Mira el texto del rebote o rechazo. ¿Menciona tu servidor, tu gateway o un dominio remoto?
- Comprueba el código de respuesta SMTP. 4xx sugiere aplazamiento; 5xx sugiere política/rechazo permanente.
- Encuentra la entrada de registro que coincida con Message-ID o ID de cola. Esa es la verdad del terreno.
Segundo: mide el radio de impacto
- ¿Es un remitente? ¿Una aplicación? ¿Una subred? ¿O todo el mundo?
- ¿Solo destinatarios internos, o también externos?
- ¿Un mensaje enorme, o muchos mensajes medianos?
Tercero: decide el modo de respuesta
- Si el abuso es plausible: contener primero (limitar, bloquear, revocar credenciales), luego arreglar.
- Si es un envío masivo legítimo: usa patrones seguros (fragmentación, mensajes por destinatario, listas de correo diseñadas para masivo) en lugar de inflar topes globales.
- Si es un cuello de botella de rendimiento: arregla el rendimiento de la cola y el escaneo de políticas; subir límites solo aumenta el tamaño de la explosión.
Broma #2: Subir límites de destinatarios para solucionar un retraso es como comprar un cubo de basura más grande para apagar un incendio en la cocina.
Tareas prácticas: comandos, salidas y decisiones (12+)
Las tareas a continuación suponen un entorno MTA Linux (Postfix es común), con journals de systemd.
Incluso si ejecutas Exchange o un gateway en la nube, la misma lógica aplica: encuentra el componente que hace cumplir la regla, valida el límite configurado y confirma qué ocurre realmente bajo carga.
Task 1: Find the exact rejection in logs (Postfix via journal)
cr0x@server:~$ sudo journalctl -u postfix --since "1 hour ago" | grep -E "too many recipients|Recipient address rejected|5\.5\.3|4\.5\.3" | tail -n 20
Jan 04 10:12:09 mx1 postfix/smtpd[21455]: NOQUEUE: reject: RCPT from mailclient[10.20.3.44]: 452 4.5.3 Too many recipients; from=<alerts@corp.example> to=<dl-all@corp.example> proto=ESMTP helo=<host44>
Qué significa: El rechazo ocurrió durante RCPT SMTP, en mx1, en smtpd. Eso es una decisión de política entrante al MTA (envío o relay).
No es un receptor remoto.
Decisión: Confirma qué parámetro de Postfix o demonio de política está aplicando los topes de destinatarios para este servicio (puerto 25 vs 587), y luego decide si arreglar el comportamiento del remitente o ajustar la política para un remitente de confianza.
Task 2: Identify the client and whether it’s authenticated submission
cr0x@server:~$ sudo journalctl -u postfix --since "1 hour ago" | grep "sasl_username" | tail -n 10
Jan 04 10:12:09 mx1 postfix/smtpd[21455]: warning: unknown[10.20.3.44]: SASL LOGIN authentication failed: authentication failure
Qué significa: La misma IP cliente aparece, pero falla la autenticación. Eso es misconfiguración o abuso.
Decisión: Trátalo como sospechoso hasta que se demuestre lo contrario. Bloquea/limita esa IP, comprueba bloqueos de cuentas y verifica si la app debería estar enviando aquí en absoluto.
Task 3: Inspect Postfix recipient limit settings
cr0x@server:~$ sudo postconf | grep -E "smtpd_recipient_limit|default_recipient_limit|smtpd_client_recipient_rate_limit|smtpd_recipient_restrictions"
default_recipient_limit = 1000
smtpd_recipient_limit = 100
smtpd_client_recipient_rate_limit = 0
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
Qué significa: smtpd_recipient_limit=100 es un tope rígido durante el diálogo SMTP para este daemon.
default_recipient_limit afecta entregas internas y cierto comportamiento de cola; no es el mismo umbral.
Decisión: Si 100 destinatarios en una sola transacción SMTP es demasiado bajo para patrones masivos aprobados, considera excepciones en el servicio de envío solo, no en el puerto 25.
De lo contrario: arregla el remitente para fragmentar en conjuntos más pequeños.
Task 4: Check per-service overrides in master.cf (submission vs smtp)
cr0x@server:~$ sudo postconf -n | head
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
cr0x@server:~$ sudo grep -nE "^(smtp|submission|smtps)\s" /etc/postfix/master.cf
13:smtp inet n - y - - smtpd
26:submission inet n - y - - smtpd
cr0x@server:~$ sudo sed -n '13,40p' /etc/postfix/master.cf
smtp inet n - y - - smtpd
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_limit=500
Qué significa: Submission tiene un tope de destinatarios más alto (500) que el puerto 25. Buen patrón: más estricto para entradas no autenticadas, más flexible para usuarios/apps autenticados.
Decisión: Si el rechazo vino del servicio smtp (puerto 25) pero el remitente debería usar submission (587), arregla el enrutamiento y las credenciales en lugar de subir límites en el puerto 25.
Task 5: Confirm which port the client used (packet capture, short and surgical)
cr0x@server:~$ sudo timeout 15 tcpdump -ni any 'host 10.20.3.44 and (port 25 or port 587)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:12:09.112233 eth0 IP 10.20.3.44.51234 > 10.20.1.10.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
10:12:09.112300 eth0 IP 10.20.1.10.25 > 10.20.3.44.51234: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0
Qué significa: El cliente está contactando el puerto 25, no el 587. Eso es típico para MTAs, no para apps/usuarios.
Decisión: Mueve al cliente a submission (587) con auth y controles por remitente apropiados. Mantén puerto 25 estricto.
Task 6: Check queue size and whether limits are hiding a throughput problem
cr0x@server:~$ mailq | head -n 30
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
6F2A512345 3292 Thu Jan 4 10:10:01 alerts@corp.example
user1@external.example
user2@external.example
9C8B7128AA 8410 Thu Jan 4 10:10:05 hr@corp.example
dl-all@corp.example
-- 52 Kbytes in 2 Requests.
Qué significa: Hay mensajes en cola; no necesariamente es malo. Pero si la cola crece continuamente, los límites de destinatarios pueden ser un efecto secundario de la contrapresión.
Decisión: Si la cola está creciendo: investiga conectividad saliente, DNS, throttling remoto y filtros de contenido. No lo “soluciones” permitiendo lotes más grandes.
Task 7: Inspect a queued message for recipient count and headers
cr0x@server:~$ sudo postcat -q 9C8B7128AA | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size: 8410 8410
message_arrival_time: Thu Jan 4 10:10:05 2026
sender: hr@corp.example
named_attribute: rewrite_context=local
recipient: dl-all@corp.example
*** MESSAGE CONTENTS ***
Received: from hr-app (10.20.9.15) by mx1 with ESMTPA; Thu, 4 Jan 2026 10:10:05 +0000
To: dl-all@corp.example
Subject: Updated handbook policy
Qué significa: El sobre tiene un único destinatario: una lista de distribución. La explosión ocurrirá durante la expansión.
Decisión: Determina dónde ocurre la expansión de la lista (servicio de directorio, mapas de alias del MTA, gestor de listas). Establece límites sobre destinatarios expandidos y proporciona un mecanismo de masivo aprobado.
Task 8: Check alias/database expansion size (example: Postfix virtual aliases)
cr0x@server:~$ sudo postmap -q dl-all@corp.example /etc/postfix/virtual
user1@corp.example,user2@corp.example,user3@corp.example,user4@corp.example,user5@corp.example
Qué significa: La lista se expande localmente en múltiples destinatarios. Si este mapeo se vuelve enorme, golpearás límites o problemas de rendimiento.
Decisión: Para listas grandes, muévelo a un gestor de listas o a un grupo respaldado por directorio con envíos controlados; evita meter miles de direcciones en mapas planos.
Task 9: Validate DNS health (because “too many recipients” sometimes is just “too slow”)
cr0x@server:~$ dig +time=2 +tries=1 mx external.example
;; ANSWER SECTION:
external.example. 300 IN MX 10 mx.external.example.
cr0x@server:~$ dig +time=2 +tries=1 mx external.example a
;; ANSWER SECTION:
mx.external.example. 300 IN A 203.0.113.25
Qué significa: DNS resuelve rápidamente. Si esto fuera lento o con timeouts, tu MTA podría encolar y comenzar a aplazar, que la gente interpreta mal como “límites de destinatarios.”
Decisión: Si DNS está lento: arregla resolvers, caching y firewall. La presión en la cola a menudo se manifiesta como síntomas de política extraños.
Task 10: Test remote acceptance behavior with a controlled SMTP session
cr0x@server:~$ nc -v mx.external.example 25
Connection to mx.external.example 25 port [tcp/smtp] succeeded!
220 mx.external.example ESMTP
cr0x@server:~$ printf "EHLO mx1.corp.example\r\nMAIL FROM:<test@corp.example>\r\nRCPT TO:<a@external.example>\r\nRCPT TO:<b@external.example>\r\nDATA\r\nSubject: test\r\n\r\ntest\r\n.\r\nQUIT\r\n" | nc mx.external.example 25
220 mx.external.example ESMTP
250-mx.external.example
250 PIPELINING
250-SIZE 52428800
250 HELP
250 2.1.0 Ok
250 2.1.5 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
250 2.0.0 Accepted
221 2.0.0 Bye
Qué significa: El remoto acepta al menos un par de destinatarios. Para probar topes de destinatarios, añade muchas líneas RCPT (con cuidado, y nunca a escala en producción).
Decisión: Si el remoto rechaza después de N comandos RCPT, necesitas fragmentar destinatarios por mensaje o por conexión. Tu límite local puede estar bien; internet no está de acuerdo.
Task 11: Detect a single sender generating abnormal volume
cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | grep " from=<" | sed -n 's/.*from=<\([^>]*\)>.*/\1/p' | sort | uniq -c | sort -nr | head
842 alerts@corp.example
115 hr@corp.example
23 noreply@corp.example
Qué significa: Un remitente domina. Eso es o bien un incidente real (tormenta de monitorización, token comprometido) o una campaña planificada que olvidó usar el canal de masivo.
Decisión: Si no se espera, limita/bloquea ese remitente de inmediato. Luego inspecciona el sistema generador por bucles, reintentos o compromiso de credenciales.
Task 12: Verify outbound concurrency settings (Postfix), because “just raise recipient limit” is a trap
cr0x@server:~$ sudo postconf | grep -E "default_process_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|qmgr_message_active_limit"
default_process_limit = 100
qmgr_message_active_limit = 20000
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
Qué significa: Puedes lanzar hasta 20 entregas concurrentes por destino por defecto. Si aumentas el batching de destinatarios, puedes amplificar la concurrencia y disparar throttles aguas abajo.
Decisión: Ajusta concurrencia y retrasos por destino (especialmente grandes proveedores) en vez de aumentar destinatarios por mensaje. “Más rápido” a menudo significa “bloqueado más pronto.”
Task 13: Confirm whether a content filter is the real bottleneck
cr0x@server:~$ systemctl status rspamd | sed -n '1,12p'
● rspamd.service - Rspamd Mail Filter
Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2026-01-04 08:01:22 UTC; 2h 12min ago
Docs: man:rspamd(8)
cr0x@server:~$ sudo journalctl -u rspamd --since "30 min ago" | tail -n 5
Jan 04 10:11:58 mx1 rspamd[1322]: lua; task; slow task: 2.34 seconds: id: <20260104101158.12345@mail>
Qué significa: El filtrado es lento bajo la carga actual. Los envíos con muchos destinatarios multiplican los escaneos y operaciones de firma dependiendo de la arquitectura.
Decisión: Arregla el rendimiento del filtro, su escalado o reglas de bypass para canales masivos internos de confianza. No subas los límites de destinatarios para alimentar un filtro lento con más trabajo.
Task 14: Add a targeted temporary throttle to contain an incident (Postfix anvil)
cr0x@server:~$ sudo postconf -e "smtpd_client_message_rate_limit = 60"
cr0x@server:~$ sudo postconf -e "smtpd_client_recipient_rate_limit = 300"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf | grep -E "smtpd_client_message_rate_limit|smtpd_client_recipient_rate_limit"
smtpd_client_message_rate_limit = 60
smtpd_client_recipient_rate_limit = 300
Qué significa: Has establecido tasas por cliente. Esto no “arregla el correo masivo,” te compra tiempo y protege el resto del sistema.
Decisión: Úsalo como control de incidente. Luego mueve remitentes masivos legítimos a una ruta separada con límites más altos y mejor autenticación/monitorización.
Diseñar envíos masivos legítimos que no activen límites
Si necesitas enviar a cientos o miles de destinatarios, el diseño correcto es aburrido:
no envíes un mensaje con cientos de destinatarios RCPT y esperes que todo vaya bien.
Diseña pensando en la entregabilidad, la observabilidad y la contrapresión.
Patrón preferido: un destinatario por mensaje (con personalización)
Para envíos masivos externos, un destinatario por mensaje es típicamente lo más seguro:
- Los ISP y gateways pueden puntuar por destinatario (quejas, rebotes) sin penalizar a todos en el lote.
- Puedes limitar por dominio de destinatario y controlar el ritmo para evitar límites de tasa.
- Los rebotes se mapean claramente a un usuario. Soporte deja de adivinar.
- Se preserva la privacidad. Nadie recibe una lista sorpresa de clientes en CC.
Sí, son más mensajes. Por eso el envío masivo debe usar un canal ingenieril: IP/pool dedicada, cuotas claras y control explícito de tasas.
Patrón aceptable interno: expansión controlada de listas y autorización estricta del remitente
El correo interno tiene objetivos distintos. Puedes necesitar listas de distribución para:
anuncios generales, comunicaciones de incidentes, traspasos de turno. Está bien. Pero haz que la expansión sea un servicio gestionado, no un archivo de alias al azar.
Reglas para mantener el masivo interno sano:
- Permitir solo remitentes específicos para listas grandes. Todos los demás deben usar un proceso de solicitud o una lista moderada.
- Establecer topes por niveles: listas pequeñas (hasta 50) son abiertas; medianas (50–500) requieren autenticación; listas enormes requieren moderación o herramienta dedicada.
- Segmentar por función: “todo el personal” es para emergencias y avisos obligatorios, no para encuestas de almuerzo.
- Mantener la expansión visible: registra el conteo de destinatarios expandidos y quién la activó.
Fragmentación (cuando no puedes enviar un mensaje por destinatario)
Algunos sistemas (apps heredadas, ciertas herramientas de notificación) no pueden hacer un destinatario por mensaje, pero sí pueden enviar múltiples destinatarios.
Entonces la fragmentación es tu amiga:
- Mantén cada mensaje por debajo del tope más bajo conocido a lo largo de tu ruta (envío, gateway, dominios remotos).
- Espacia los fragmentos con control de tasa: destinatarios por minuto, no solo mensajes por minuto.
- Separa destinatarios internos y externos. Siempre. Políticas diferentes, consecuencias diferentes.
No confundas listas de distribución con correo masivo
Una lista de distribución es una conveniencia de direcciones. El correo masivo es una carga de entrega.
Si haces grandes campañas por una DL, fallarás de la manera menos predecible:
a veces funciona, hasta que no, y entonces obtienes montones de rebotes y un golpe a la reputación.
Detener el abuso sin daños colaterales
Los errores “demasiados destinatarios” pueden significar que tus controles funcionan. O pueden significar que tus controles están en el lugar equivocado.
La prevención de abuso debe ser en capas, no solo un tope único que castiga a todo el mundo.
Cómo se ve el abuso en el terreno de límites de destinatarios
- Un único host interno intenta enviar mensajes con cientos de comandos RCPT TO.
- Una cuenta comprometida envía rápidamente a muchos destinatarios externos, a menudo con asuntos similares.
- Los fallos se agrupan alrededor de errores de autenticación, nombres HELO inusuales o clientes desconocidos.
- Tu cola se llena de correo aplazado a muchos dominios, con reintentos repetidos.
Controles que funcionan (y no destruyen envíos legítimos)
- Separar envío para apps: credenciales distintas, límites distintos, registros distintos. Si se rompe, solo rompe esa ruta.
- Límites de tasa de destinatarios por remitente: cap recipients/minute por usuario/app, no solo destinatarios/mensaje.
- Topes por nivel de confianza: p. ej., 50 para usuarios generales, 500 para servicio app autenticado, 5.000 para sistema masivo dedicado con monitorización.
- Listas blancas de salida por propósito: alertas de monitorización a un conjunto pequeño; avisos de RR. HH. internos; marketing usa infraestructura masiva.
- Alertas sobre anomalías: “remitente excedió la línea base por 10x” vence a “la cola está en llamas” siempre.
La regla impopular: no dejes que los usuarios envíen masivos
Si una persona quiere enviar a 2.000 destinatarios, no debería hacerlo desde Outlook en el SMTP corporativo.
No porque las personas sean malas. Porque las personas están ocupadas, y la gente ocupada pulsa “enviar” dos veces.
Proporciona un mecanismo: una herramienta interna de comunicaciones, un proceso mediante ticket o una lista moderada con registros de auditoría.
Tu yo futuro te lo agradecerá cuando Legal pregunte “quién envió qué, cuándo, a quién.”
Tres mini-historias corporativas (anonimizadas, plausibles)
Mini-historia 1: El incidente causado por una suposición errónea
Una empresa mediana migró de un gateway de correo a otro. El plan del proyecto tenía los puntos habituales:
alineación SPF/DKIM, ajustes TLS, conectores. Alguien preguntó por límites de destinatarios. La respuesta fue un encogimiento de hombros:
“Nunca tuvimos un problema, así que los valores por defecto están bien.”
Dos semanas después, RR. HH. intentó enviar un recordatorio de inscripción a beneficios a una lista de personal.
Rebotó con “demasiados destinatarios.” El equipo escaló a TI, que miró el mensaje y vio un único destinatario: all-staff@corp.example.
“Eso no puede ser,” dijeron, y subieron el límite de destinatarios por mensaje en submission.
El error persistió. Porque el punto de aplicación no era submission; era la política de expansión del gateway.
El nuevo gateway contaba destinatarios expandidos. El anterior contaba solo los destinatarios del sobre. Mismo comportamiento del usuario, diferentes semánticas.
La solución fue aburrida: crear un canal interno sancionado de difusión con autorización explícita y un tamaño máximo definido, más una ruta separada para mensajes de RR. HH.
La lección real fue más nítida: “límite de destinatarios” necesita una definición. ¿Estás contando comandos RCPT, destinatarios en cabecera o destinatarios expandidos? Si no lo sabes, no estás configurando un sistema—estás adivinando uno.
Mini-historia 2: La optimización que salió mal
Un equipo de plataforma quiso reducir carga en su servicio de notificaciones. Enviaba muchas alertas similares a grandes grupos de guardia.
Alguien propuso: “En lugar de un correo por persona, enviemos un correo al grupo. Son menos mensajes y debería ser más rápido.”
En el pizarrón, parecía elegante.
En producción fue una caída lenta. El servicio de notificaciones comenzó a emitir correos con 300–800 destinatarios cada uno.
El servidor de envío los aceptó. Luego el MTA desparramó las entregas y las pasó al escaneo de contenido y la firma DKIM.
La CPU subió, la latencia aumentó, la cola de correo creció colmillos, y luego empezaron los rechazos “demasiados destinatarios” cuando el equipo intentó aumentar el rendimiento subiendo la concurrencia.
Mientras tanto, un destinatario se quejó y su proveedor de buzón empezó a fallar temporalmente. Como todos estaban agrupados, los reintentos afectaron a todo el conjunto.
Un solo throttle aguas abajo provocó reenvíos repetidos a cientos de personas, lo que pareció spam y disparó más throttles.
Revirtieron a un destinatario por mensaje con throttling consciente por dominio. Usó más entradas en la cola, pero se comportó de forma predecible y degradó con gracia.
La optimización era correcta solo en el sentido contable. En operaciones, aumentó el acoplamiento: un destinatario malo hacía sufrir a todos.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Una compañía de servicios financieros tenía una postura estricta: endpoints SMTP de envío separados para humanos, apps y sistemas masivos.
Todos se quejaban durante la incorporación. “¿Por qué no puedo usar el servidor de correo normal?” era un coro semanal.
Seguridad lo aprobaba. SRE lo toleraba. Se mantuvo.
Una mañana de lunes, una cuenta de servicio interna fue comprometida (phishing, predeciblemente mundano).
El atacante intentó enviar spam saliente a miles de destinatarios por mensaje, desde un host de app comprometido.
El intento golpeó primero el endpoint humano—credenciales equivocadas—luego probó el endpoint de apps.
El endpoint de apps permitía solo un tope bajo de destinatarios por mensaje y tenía límites estrictos de tasa por destinatario.
Los registros tenían un índice dedicado para envío de apps con líneas base por remitente. Las alertas saltaron en minutos:
“service-account-x recipients/minute exceeded threshold.” El throttle evitó daños masivos y la reputación de la IP se mantuvo intacta.
La limpieza fue sencilla: revocar credenciales, rotar tokens, añadir MFA donde fuera posible y revisar reglas de firewall de salida.
Lo mejor: RR. HH. y la rotación on-call nunca lo notaron. La aburrida separación de rutas mantuvo la explosión en una caja pequeña.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: “Demasiados destinatarios” en envíos a DL internos, aunque el correo muestra una sola dirección
Causa raíz: El sistema que aplica la regla cuenta destinatarios expandidos tras la expansión de la lista de distribución.
Solución: Gestiona listas grandes con autorización explícita de envío y un mecanismo de broadcast/bulk. Documenta si los límites cuentan RCPT vs expansión. No subas topes globales a lo loco.
2) Síntoma: Subir smtpd_recipient_limit no ayudó
Causa raíz: El límite se aplica en otro lugar: override del servicio de submission, demonio de política, gateway o receptor remoto.
Solución: Identifica el punto de aplicación mediante registros y respuesta SMTP. Revisa overrides por servicio (master.cf), servicios de política y respuestas remotas.
3) Síntoma: Envíos masivos legítimos funcionan a veces y fallan bajo carga
Causa raíz: Presión en la cola y timeouts. Filtrado de contenido lento, problemas de DNS o throttling remoto hacen las transacciones más lentas y disparan defensas de tasa/destinatarios.
Solución: Mejora el rendimiento: DNS, escalado de filtros, ajuste de concurrencia, pacing por destino. Mantén conteos de destinatarios modestos; fragmenta envíos.
4) Síntoma: El boletín de un equipo provoca rebotes y golpes de reputación
Causa raíz: Usar el submission corporativo como canal de marketing/masivo; no hay baja, mala higiene de listas, sin pacing por dominio.
Solución: Mueve marketing/masivo a un sistema dedicado con gestión de listas, manejo de quejas y una identidad de envío separada.
5) Síntoma: “Demasiados destinatarios” desde una única IP interna, con fallos de autenticación
Causa raíz: Host comprometido o app mal configurada golpeando el puerto 25; posible stuffing de credenciales o malware.
Solución: Contener: bloquear en firewall, activar límites por cliente, investigar el endpoint, rotar credenciales y exigir envío autenticado en 587 para apps.
6) Síntoma: Proveedores externos aceptan algunos destinatarios y rechazan otros a mitad de la transacción
Causa raíz: Topes remotos por conexión, o reglas anti-spam agresivas disparadas por alto conteo RCPT.
Solución: Reduce destinatarios por mensaje y/o abre nuevas conexiones por fragmento. Usa pacing por dominio y respeta aplazamientos 4xx.
Listas de verificación / plan paso a paso
Paso a paso: manejar un incidente “demasiados destinatarios” en producción
- Captura evidencia: texto del rebote, código SMTP, ventana temporal, remitente y destinatarios de muestra.
- Encuentra la línea de registro: coincide Message-ID o ID de cola; identifica servidor que aplica y servicio (25 vs 587).
- Clasifica: sospecha de abuso vs envío legítimo vs tormenta de CC accidental.
- Contén si es sospechoso: limita por cliente/remitente; bloquea IP ofensiva; revoca credenciales si hace falta.
- Revisa salud de la cola: si el backlog aumenta, investiga rendimiento antes de cambiar límites.
- Identifica punto de aplicación: política de submission, MTA, expansión de listas, gateway, receptor aguas abajo.
- Elige la solución correcta:
- Masivo legítimo: fragmentación, un destinatario por mensaje, ruta masiva dedicada.
- Broadcast interno: lista moderada y grupo de remitentes autorizados.
- Abuso: aplicar auth en submission, límites de tasa, alertas de anomalías, respuesta de endpoint.
- Implementa una excepción segura: solo si es necesario; delimítala a una cuenta de servicio y un listener de submission específico.
- Añade observabilidad: dashboards de destinatarios/minuto por remitente, principales emisores, razones de rechazo, profundidad de cola.
- Limpieza post-incidente: documenta definiciones (RCPT vs expansión), publica política de envíos masivos y capacita a los equipos.
Lista de verificación: qué estandarizar para que esto no siga ocurriendo
- Documenta límites de destinatarios por cada ruta: inbound 25, submission 587, relay de apps, relay masivo.
- Haz límites por niveles (humanos vs apps vs masivo), con credenciales separadas y registros independientes.
- Define “conteo de destinatarios” en tu entorno: RCPT del sobre, destinatarios en cabecera, destinatarios expandidos.
- Define gobernanza para listas grandes: propietario, propósito, autorización de remitente, reglas de moderación, tamaño máximo.
- Introduce un servicio de envíos masivos (interno) para broadcasts aprobados, con registros de auditoría y control de tasas.
- Establece límites de tasa en mensajes/minuto y destinatarios/minuto; alerta sobre anomalías.
- Operacionaliza higiene de listas: manejo de rebotes, eliminación de direcciones obsoletas, revisión de membresías de grupos.
- Ejecuta game days: simula una cuenta comprometida enviando a 1.000 destinatarios; verifica throttles y alertas.
Preguntas frecuentes
1) ¿“Demasiados destinatarios” siempre indica abuso?
No. A menudo es un caso legítimo de envío masivo chocando con un límite que se estableció por buenas razones. Trátalo como un desajuste de política hasta que los registros indiquen compromiso (fallos de auth, clientes inusuales, picos de volumen repentinos).
2) ¿Debería simplemente aumentar el límite de destinatarios?
No globalmente. Aumenta límites solo en una ruta dedicada y autenticada para remitentes confiables, y combínalo con límites de tasa de destinatarios. Si no, amplías el radio de impacto para el próximo compromiso.
3) ¿Por qué un mensaje a una lista de distribución cuenta como muchos destinatarios?
Porque la expansión convierte una dirección en muchas entregas. Algunos sistemas aplican límites después de la expansión. Eso suele ser correcto: refleja la carga real de entrega y el riesgo.
4) ¿Cuál es la forma más segura de enviar a 10.000 destinatarios externos?
Un destinatario por mensaje, con pacing por dominio de destinatario, usando un sistema masivo con manejo de feedback (rebotes/quejas). Los MTAs corporativos no están diseñados para campañas.
5) ¿Por qué veo 452 (4xx) en vez de 550 (5xx)?
4xx es un fallo temporal: el servidor dice “no ahora” (carga, throttling, límites de tasa). 5xx es un fallo permanente o de política. Operativamente, 4xx suele indicar contrapresión o control de tasa en lugar de una regla rígida.
6) ¿Cómo evito romper broadcasts internos legítimos?
Proporciona un mecanismo sancionado de difusión: listas grandes moderadas, remitentes autorizados específicos y un endpoint de submission separado para comunicaciones internas. Luego mantén límites conservadores en la submission genérica de usuarios.
7) Mi proveedor de app dice “necesitamos 1.000 destinatarios por mensaje.” ¿Qué hago?
Contradice. Pregunta qué problema solucionan al agrupar destinatarios. Si no pueden enviar un destinatario por mensaje, implementa fragmentación en tu lado o inserta un relay que expanda de forma segura mientras aplica límites y registros.
8) ¿Qué métricas debo alertar para detectar esto temprano?
Principales remitentes por destinatarios/minuto, tasa de rechazos por código, ritmo de crecimiento de la cola, entregas aplazadas por dominio destino y fallos de autenticación en endpoints de submission.
9) ¿Los límites de destinatarios pueden afectar al almacenamiento?
Sí. El gran fan-out aumenta entradas en la cola y churn en el spool. Si tu cola está en almacenamiento lento, verás latencia y aplazamientos que se hacen pasar por fallos de política. Mantén el spool en discos fiables y de baja latencia y monitoriza I/O wait.
10) ¿Cómo explico esto a stakeholders no técnicos?
Di: “Limitamos cuántas personas puede apuntar un solo correo a la vez para evitar spam y cortes de servicio. Para envíos grandes, usamos un proceso de difusión más seguro.”
Conclusión: siguientes pasos prácticos
“Demasiados destinatarios” es una función que se disfraza de incidente. Tu objetivo no es silenciarla. Tu objetivo es hacerla precisa:
bloquear abuso temprano, enrutar el masivo legítimo por un canal controlado y mantener la ruta de correo por defecto segura para el trabajo diario.
Siguientes pasos que realmente mueven la aguja:
- Anota tus límites por servicio y define qué significa “destinatario” en tu entorno.
- Divide la submission de correo por niveles de confianza (humanos, apps, masivo) con credenciales y registros separados.
- Implementa límites de tasa de destinatarios y alerta sobre remitentes anómalos antes de que la reputación sufra.
- Arregla patrones de envíos masivos (un destinatario por mensaje o fragmentación) en lugar de subir topes globales.
- Gobierna listas internas grandes con propietarios, moderación y un proceso aprobado de difusión.