Si gestionas correo en producción, un buzón catch‑all parece una red de seguridad ordenada: ningún correo se pierde, nada rebota, todo el mundo contento.
Luego la reputación de tu dominio cae en picado, el correo real de clientes empieza a ir a spam y tu mesa de ayuda queda sepultada bajo misterios de “entrega fallida” que en realidad no lo son.
Catch‑all es el equivalente en correo de decir en recepción “acepten todos los paquetes para ‘Cualquier Nombre’ y apílenlos en el vestíbulo”.
Te sentirás muy servicial hasta que aparezca el inspector de bomberos.
Qué hace realmente un buzón catch‑all
Un buzón catch‑all (a veces “accept-all” o “dirección por defecto”) es una regla de enrutamiento de correo que acepta mensajes para cualquier destinatario en tu dominio
—incluyendo destinatarios que no existen— y los entrega a un buzón (o tubería) que controlas.
En términos prácticos, tu servidor SMTP deja de decir “550 5.1.1 user unknown” y empieza a decir “250 ok” para casi todo.
Eso cambia la forma en que el resto del ecosistema de correo te trata.
Por qué los equipos habilitan catch‑all (las razones habituales)
- Miedo a perder correo: “¿Y si un cliente escribe saless@domain.com en vez de sales@domain.com?”
- Curita de migración: alias antiguos, departamentos antiguos, direcciones de aplicaciones antiguas.
- Hábito heredado: alguien lo configuró hace diez años y nadie quiere tocar el correo.
- Malentendido sobre la “entregabilidad”: piensan que menos rebotes = mejor reputación.
Qué te compra realmente el catch‑all
Te compra más correo aceptado. No más correo valioso.
También te compra algunas responsabilidades operacionales muy específicas: amplificación de spam, fallos silenciosos de políticas y un perfil de reputación que parece un dominio amigable con el spam.
Por qué el catch‑all arruina la entregabilidad (mecanismos, no sensaciones)
1) Te conviertes en un imán de spam, por diseño
Los spammers no necesitan adivinar direcciones cuando un dominio acepta todo. Pueden pulverizar direcciones aleatorias en tu dominio y tú lo aceptas.
Una vez que lo descubren (probándolo), tu dominio entra en un “bucket de alta aceptación” en sus herramientas.
No es personal; es economía.
Tu volumen entrante sube. Más importante: tu volumen malo sube: destinatarios inválidos, direcciones generadas por bots, ataques de diccionario y dominios remitentes falsificados.
Esto no se queda en “solo entrada”. Afecta la reputación de tu dominio de formas que se notan luego al enviar correo.
2) Rompes un bucle de retroalimentación importante: la validación de destinatarios
SMTP debería ser un momento de filtrado. Si el usuario no existe, lo correcto es rechazar en RCPT TO con un 5xx.
Catch‑all elimina eso. Aceptas el mensaje, generas carga de almacenamiento y luego te toca lidiar con él aguas abajo.
Ese manejo posterior a menudo se convierte en “marcar como spam” o “borrar”. Está bien para tu bandeja de entrada, pero significa que no rechazaste en la capa de protocolo
—el remitente recibió un 250 OK y considera la entrega como exitosa.
3) Creas “entregabilidad fantasma”: menos rebotes, peor reputación
Un malentendido ejecutivo común: “Los rebotes son malos, evitémoslos.” No.
Los rebotes innecesarios son malos. Los rebotes precisos son higiene.
Cuando aceptas correo a destinatarios inexistentes, los remitentes no aprenden que su lista está sucia. Siguen enviando.
Eventualmente, su sistema te marca como un sumidero de direcciones. Mientras tanto, tu filtrado entrante trabaja más, tus usuarios se quejan y tu pila de correo parece ruidosa.
4) Aumentas la probabilidad de backscatter (y molestas a otros operadores)
El backscatter ocurre cuando tu sistema acepta un correo y después genera un rebote al (falsificado) MAIL FROM.
Si aceptas spam a destinatarios aleatorios y luego decides “no puedo entregarlo”, pueden generarse informes de no entrega a terceros inocentes.
Muchos MTAs modernos intentan evitar esto, pero las configuraciones catch‑all frecuentemente van acompañadas de reglas de enrutamiento descuidadas y comportamientos de respuesta automática.
Las quejas por backscatter pueden machacar la reputación de tu IP o dominio.
5) Embarras la historia de aplicación de DMARC/SPF/DKIM
DMARC no es solo una casilla para marcar. Es una política más un canal de informes que te dice quién te está suplantando y cómo los receptores tratan tu correo.
Catch‑all hace que mucho correo basura entrante “se entregue exitosamente” internamente, lo que fomenta flujos de trabajo malos:
reenviar correo sospechoso, responder automáticamente o interactuar accidentalmente con intentos de suplantación.
También pierdes señal limpia en tus informes agregados de DMARC porque tu volumen de spam entrante aumenta y tu equipo empieza a ignorar los datos.
Operativamente: el panel se convierte en papel tapiz.
6) El almacenamiento y la fiabilidad empeoran (sí, en serio)
El correo es almacenamiento. El correo también es entrada de usuario sin límites.
Un buzón catch‑all es una vía clásica hacia:
- Desbordes de cuota de buzón (luego todo rebota, incluido el correo legítimo).
- Explosiones en indexado/búsqueda (los servidores IMAP no adoran millones de mensajes en una carpeta).
- Crecimiento de backups y dolor en restauraciones (ese único buzón se vuelve tu peor conjunto de datos).
- Confusión en la respuesta a incidentes (“¿por qué este buzón tiene 200 GB?”).
Chiste #1: Un buzón catch‑all es como /dev/null, excepto que es facturable y de vez en cuando envía respuestas enfadadas.
7) Aumentas la probabilidad de filtración accidental de datos
El correo mal dirigido a veces contiene facturas, contratos, credenciales o datos personales.
Con catch‑all, aceptas silenciosamente correos destinados a otras organizaciones también —incluyendo dominios con errores tipográficos.
Te acabas de convertir en un sumidero de datos por errores de otros.
8) Destruyes la capacidad de tomar decisiones de política precisas
Cuando todo se enruta a un solo lugar, todo parece igual. Eso arruina tu habilidad para:
- Diferenciar correo transaccional de correo humano
- Establecer límites de tasa y reglas de filtrado por alias
- Implementar políticas de retención específicas por buzón
- Aplicar principio de menor privilegio (quién puede leer qué)
El buzón catch‑all es un anti‑patrón porque es un cubo único para riesgos heterogéneos.
En términos de fiabilidad: colapsaste varios dominios de fallo en uno.
Datos interesantes y contexto histórico
El correo no empezó como un sistema de identidad global endurecido. Fue creciendo hasta convertirse en uno. Catch‑all tenía más sentido cuando todo era más pequeño, amistoso y funcionaba por honor.
Aquí algunos hechos cortos que explican cómo nos quedamos con él:
- SMTP temprano (años 80) asumía redes cooperativas. La verificación de destinatarios no era un problema en un campo hostil; ahora lo es.
- Comandos VRFY/EXPN ayudaban a confirmar destinatarios. Hoy están mayormente deshabilitados porque facilitan la recolección de directorios.
- “Aceptar y luego filtrar” era común históricamente porque el disco era más barato que el tiempo de ingeniería. Hoy, la reputación es la parte cara.
- El spam explotó en los años 90, y los “ataques de diccionario” (probar nombres comunes) se volvieron rutinarios; catch‑all es básicamente permiso para ese ataque.
- SPF apareció para limitar la suplantación autorizando IPs emisoras, pero es frágil con el reenvío, así que la gente se apoyó más en DKIM/DMARC después.
- DKIM hizo práctica la autenticación a nivel de contenido, pero no resolvió “¿este destinatario existe?” Catch‑all sigue rompiendo esa señal.
- DMARC introdujo alineamiento y políticas, y reportes. Esos informes son valiosos solo cuando no te ahogas en basura.
- Los proveedores de buzones modernos puntúan dominios e IPs usando señales de interacción y queja; aceptar mucha basura incrementa la probabilidad de malas interacciones.
- Plus‑addressing (usuario+etiqueta@dominio) se hizo popular como alternativa segura para “direcciones desconocidas” sin aceptar literalmente todo.
Guía rápida de diagnóstico
Cuando la entregabilidad o el spam entrante se pone feo y catch‑all está en la mezcla, no empieces debatiendo filosofía. Haga triage como operador.
Revisa primero el cuello de botella: comportamiento del protocolo, indicadores de reputación y salud del almacenamiento.
Primero: confirma que realmente estás aceptando destinatarios desconocidos
- Usa pruebas SMTP contra tus MX: ¿acepta RCPT TO para un usuario aleatorio?
- Revisa la configuración del MTA para transportes por defecto, mapas de destinatarios o “luser_relay”.
Segundo: cuantifica el daño (volumen, fuentes y modos de fallo)
- Muestra de logs: ¿cuántos destinatarios inexistentes distintos por hora?
- Top de IPs/ASNs que se conectan, top de nombres HELO, top de remitentes de sobre.
- Creación de colas y patrones de rebote (fallos temporales vs permanentes).
Tercero: verifica si el “catch‑all” está ocultando otro problema
- ¿Cuota de buzón llena? ¿Time-outs de IMAP? ¿Latencia de almacenamiento?
- ¿Reglas de alias/reenvío mal configuradas causando bucles?
- ¿El correo saliente ahora va a spam porque tu dominio parece desordenado?
Cuarto: decide la contención
- Inmediato: rechaza destinatarios desconocidos en tiempo SMTP.
- Corto plazo: añade aliases explícitos para errores tipográficos críticos o direcciones de negocio.
- Medio plazo: implementa manejo entrante estructurado y revisión de seguridad para correos mal dirigidos.
Tareas prácticas: comandos, salidas y decisiones
Abajo hay tareas concretas que puedes ejecutar en una pila MTA típica en Linux (ejemplos de Postfix, con algo de Exim/Dovecot/herramientas comunes).
Cada tarea incluye un comando, qué significa la salida y la decisión que debes tomar a partir de ello.
Tarea 1: Demuestra el comportamiento catch‑all con una sesión SMTP directa
cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
250 2.1.5 Ok
quit
221 2.0.0 Bye
Significado: Si obtienes “250 2.1.5 Ok” para un destinatario claramente aleatorio, estás aceptando destinatarios desconocidos (catch‑all o equivalente).
Decisión: Si esto no es explícitamente necesario para un flujo controlado, desactívalo. Si es necesario, ponlo tras una puerta (límites de tasa, MX separado o lista de destinatarios verificados).
Tarea 2: Busca en Postfix la configuración clásica de catch‑all (luser_relay)
cr0x@server:~$ postconf -n | egrep 'luser_relay|local_recipient_maps|virtual_alias_maps|virtual_mailbox_maps|recipient_delimiter'
luser_relay = catchall
local_recipient_maps =
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
Significado: luser_relay enruta destinatarios locales desconocidos a una dirección local. Un local_recipient_maps vacío también puede significar “acepta cualquier cosa”.
Decisión: Elimina luser_relay y restaura la validación de destinatarios vía local_recipient_maps o mapas de buzón virtual adecuados.
Tarea 3: Confirma si Postfix valida destinatarios en tiempo RCPT
cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_relay_restrictions|smtpd_delay_reject'
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
Significado: No hay nada aquí que rechace destinatarios desconocidos. Eso no es automáticamente incorrecto, pero es un hueco común.
Decisión: Añade un mecanismo de validación de destinatarios (por ejemplo, local_recipient_maps / virtual_mailbox_maps correctos y reject_unlisted_recipient donde corresponda).
Tarea 4: Encuentra patrones “accept-all” en los logs (destinatarios inexistentes)
cr0x@server:~$ sudo grep -R "to=<.*@example.net>" /var/log/mail.log | tail -n 5
Jan 4 09:14:31 mx1 postfix/qmgr[1123]: 9A2B13C4D: to=<xyqzqj@example.net>, relay=local, delay=0.2, status=sent (delivered to mailbox)
Jan 4 09:14:32 mx1 postfix/qmgr[1123]: 7D1E22F8A: to=<billingg@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:33 mx1 postfix/qmgr[1123]: 1F3D9C0AA: to=<hr-dept@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:35 mx1 postfix/qmgr[1123]: 4C0D22B19: to=<asdkjhasd@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:36 mx1 postfix/qmgr[1123]: 55B9CC1E0: to=<customer.service@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Significado: Destinatarios con aspecto aleatorio que aparecen como “delivered to mailbox” indican fuertemente que no hay validación de destinatarios.
Decisión: Si más que una fracción trivial de destinatarios son basura, desactiva el catch‑all y añade aliases explícitos para variantes legítimas.
Tarea 5: Identifica los nombres de destinatario más usados (para detectar ataques de diccionario)
cr0x@server:~$ sudo awk -F'to=<' '/postfix\/(qmgr|local)/ {for (i=1;i<=NF;i++) if ($i ~ /^to=</) {gsub(/^to=<|>,.*/,"",$i); print $i}}' /var/log/mail.log | \
cut -d@ -f1 | sort | uniq -c | sort -nr | head -n 10
418 info
377 admin
265 support
201 sales
188 contact
173 test
166 hr
144 billing
121 webmaster
110 noreply
Significado: Estos son los local parts más atacados. “admin/info/support” alto es comportamiento clásico de spam de diccionario.
Decisión: Asegúrate de que esos aliases de alto valor existan y se enrutuen a colas monitoreadas, pero rechaza destinatarios desconocidos fuera de tu lista conocida.
Tarea 6: Comprueba la profundidad de la cola (síntoma de catch‑all + oleada de spam)
cr0x@server:~$ mailq | tail -n 3
-- 1245 Kbytes in 812 Requests.
Significado: Una cola en crecimiento sugiere cuellos de botella aguas abajo (entrega, escaneo de contenido, I/O de disco) o abuso arriba.
Decisión: Si la cola crece durante oleadas de spam y los destinatarios son aleatorios, prioriza el rechazo de destinatarios en tiempo SMTP para dejar de alimentar la cola.
Tarea 7: Verifica si estás generando backscatter (rebotes salientes)
cr0x@server:~$ sudo grep -E "status=bounced|mailer-daemon|postmaster" /var/log/mail.log | tail -n 8
Jan 4 09:22:18 mx1 postfix/bounce[2219]: 6A1F2C9D3: sender non-delivery notification: 1B3C0D9AA
Jan 4 09:22:18 mx1 postfix/qmgr[1123]: 1B3C0D9AA: from=<>, size=3120, nrcpt=1 (queue active)
Jan 4 09:22:19 mx1 postfix/smtp[2281]: 1B3C0D9AA: to=<innocent@victim.tld>, relay=mx.victim.tld[203.0.113.8]:25, delay=1.2, status=sent (250 OK)
Significado: Tu servidor está enviando notificaciones de no entrega a terceros. Si el MAIL FROM original estaba falsificado (muy común en spam), esto es backscatter.
Decisión: Deja de aceptar correos que no puedes entregar. Rechaza en tiempo SMTP para destinatarios inválidos y considera deshabilitar rebotes fuera de banda por fallos de política de contenido.
Tarea 8: Inspecciona el tamaño del buzón y el recuento de mensajes (verificación de almacenamiento)
cr0x@server:~$ sudo doveadm mailbox status -u catchall@example.net messages vsize INBOX
messages=284112
vsize=19748377291
Significado: ~284k mensajes y ~19.7GB en una sola bandeja es donde el rendimiento IMAP empieza a costar incidentes.
Decisión: Si debes mantener un buzón sumidero, róotalo (carpetas diarias), aplica retención y mantenlo fuera de IMAP visible al usuario. Prefiere el rechazo.
Tarea 9: Revisa la capacidad del sistema de ficheros y la presión de inodos
cr0x@server:~$ df -h /var/vmail
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 500G 456G 19G 97% /var/vmail
Significado: Al 97% usado, estás a una oleada de fallos de entrega. Catch‑all convierte las oleadas en normales.
Decisión: Contén rechazando destinatarios desconocidos y podando el almacenamiento del catch‑all. Luego arregla la capacidad (ampliar, mover o aplicar cuotas/retención).
Tarea 10: Busca bucles de alias y rutas incorrectas (catch‑all puede crearlos)
cr0x@server:~$ sudo postmap -q catchall /etc/aliases
catchall@example.net
Significado: Aquí, catchall resuelve a una dirección en el mismo dominio. Eso no es automaticamente un bucle, pero es una trampa común si se combina con reglas de alias virtual.
Decisión: Asegura que el buzón sumidero sea una entrada de mapa de buzón concreta, no otro alias que pueda rebotar. Mejor: elimínalo.
Tarea 11: Valida el comportamiento del mapa de buzones virtuales (Postfix)
cr0x@server:~$ sudo postmap -q realuser@example.net /etc/postfix/vmailbox
realuser@example.net example.net/realuser/
Significado: Este destinatario existe como destino de buzón.
Decisión: Confirma que usuarios desconocidos devuelvan resultados vacíos y configura Postfix para rechazar destinatarios no listados en vez de enrutaros a un sumidero.
Tarea 12: Prueba el rechazo de destinatarios desconocidos tras cambios de configuración
cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
550 5.1.1 <this-user-should-not-exist-9f3a@example.net>: Recipient address rejected: User unknown in local recipient table
quit
221 2.0.0 Bye
Significado: Este es el comportamiento que deseas. Rechazar en RCPT con un 550 claro.
Decisión: Manténlo. Luego añade aliases explícitos para direcciones críticas de negocio que antes “capturaba” el catch‑all.
Tarea 13: Confirma que DKIM firma el correo saliente (porque vas a endurecer políticas)
cr0x@server:~$ sudo grep -R "DKIM-Signature" -n /var/log/mail.log | tail -n 3
Jan 4 09:40:01 mx1 opendkim[901]: 3F2AB19C0: DKIM-Signature field added (s=mail, d=example.net)
Jan 4 09:40:05 mx1 opendkim[901]: 8C1DA22A1: DKIM-Signature field added (s=mail, d=example.net)
Jan 4 09:40:07 mx1 opendkim[901]: 7A0BC11E2: DKIM-Signature field added (s=mail, d=example.net)
Significado: El correo saliente está siendo firmado con DKIM para tu dominio. Endurecer la política de destinatarios no arregla la autenticación saliente, pero elimina el caos del sistema.
Decisión: Si la firma DKIM no está presente, arréglala antes de aumentar la aplicación de DMARC; de lo contrario crearás un incidente de entregabilidad propio.
Tarea 14: Revisa la política DMARC de tu dominio (comprobación DNS rápida)
cr0x@server:~$ dig +short TXT _dmarc.example.net
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.net; ruf=mailto:dmarc-forensic@example.net; fo=1"
Significado: La política es p=none (solo monitorización). Eso es común, pero significa que los receptores no están obligados a poner en cuarentena/rechazar correo suplantado.
Decisión: Mantén la monitorización mientras arreglas el catch‑all. Una vez estable, pasa a p=quarantine y luego a p=reject con un despliegue escalonado.
Tarea 15: Detecta aplicación de cuotas de buzón (o la falta de ellas)
cr0x@server:~$ sudo doveadm quota get -u catchall@example.net
Quota name=User quota Type=STORAGE Value=0 Limit=0
Quota name=User quota Type=MESSAGE Value=0 Limit=0
Significado: Sin límites de cuota. Un buzón catch‑all sin cuotas es un incidente a cámara lenta.
Decisión: Si mantienes temporalmente un buzón sumidero, establece cuotas rígidas y alertas. Pero trátalo como estado de transición, no como destino.
Tarea 16: Limita la tasa de remitentes abusivos en el borde (mitigación mientras quitas catch‑all)
cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_message_rate_limit|smtpd_client_connection_rate_limit'
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 60
Significado: Límites básicos de tasa están configurados. Si faltan, dependes de la esperanza y de la CPU.
Decisión: Añade límites de tasa como escudo temporal. La solución permanente sigue siendo: dejar de aceptar destinatarios desconocidos.
Tres micro-historias corporativas (todas demasiado reales)
Micro-historia 1: El incidente causado por una suposición equivocada
Una empresa B2B mediana migró desde un proveedor de correo alojado a Postfix + Dovecot autogestionados porque “es solo correo”.
Durante el corte, alguien activó catch‑all en el dominio para evitar perder mensajes de buzones desmantelados.
La suposición era simple: aceptar todo ahora, limpiar después.
Dos semanas después, Ventas se quejó de que los prospectos “desaparecían”. No era así. Las secuencias salientes iban a spam en varios grandes destinatarios.
Mientras tanto, el buzón catch‑all recibía un goteo constante de spam y correos mal dirigidos… además de miles de sondas RCPT por día.
Nadie lo notó porque técnicamente “funcionaba”: el correo se aceptaba y entregaba a algún sitio.
El SRE de guardia encontró el buzón catch‑all con decenas de gigabytes y el servicio IMAP con timeouts intermitentes en horas pico.
Los tickets de soporte mostraban mensajes legítimos “perdidos”—en realidad no se perdieron; estaban enterrados bajo basura y un indexado lento.
La pila de correo era lo bastante sana para no generar alertas, lo bastante insalubre para costar ingresos.
Arreglarlo no fue glamuroso. Eliminaron el catch‑all, añadieron aliases explícitos para las direcciones mal tipeadas más frecuentes y rechazaron destinatarios desconocidos en tiempo SMTP.
El volumen de spam cayó inmediatamente. IMAP se estabilizó. La entregabilidad mejoró en las semanas siguientes al dejar de comportarse su dominio como un sumidero de aceptación.
Lección: “Lo limpiaremos después” no es un plan cuando internet puede escribir en tu almacenamiento.
Micro-historia 2: La optimización que salió mal
Una firma global de servicios quería reducir la carga del helpdesk por mensajes rebotados durante una reorganización.
Tenían docenas de direcciones de departamento antiguas que la gente seguía usando. En vez de mantener un mapa de aliases, alguien propuso una “simplificación inteligente”:
activar catch‑all y usar filtros para enrutar el correo según palabras clave.
Parecía ingenioso. También cambió su perfil de riesgo de la noche a la mañana.
De repente se aceptaba cualquier cadena de destinatario. Los filtros de spam se vieron superados. La CPU del gateway de correo subió.
El buzón catch‑all se convirtió en un vertedero, y—aquí viene lo que dolió—el enrutamiento por palabras clave creó falsos positivos.
Facturas legítimas acabaron en un buzón general porque contenían palabras que activaban una regla interna.
Algunos mensajes de proveedores se retrasaron porque el ordenamiento automático causó contención y reintentos.
Y como el sistema no rebotaba destinatarios desconocidos, los remitentes externos no corrigieron las direcciones; el problema nunca decayó de forma natural.
Lo revertieron y hicieron lo aburrido: mantener un mapa de aliases correcto, conservar una lista de redirecciones de corta vida y rechazar destinatarios desconocidos.
La “optimización” había reducido una clase de ruido (rebotes) creando una forma más grande y costosa de ruido (errores de entrega y carga de procesamiento).
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Una empresa SaaS gestionaba correo para varias marcas bajo una infraestructura común.
Tenían una regla estricta: no catch‑alls en dominios primarios. Cualquier excepción requería justificación por escrito y una expiración con tiempo límite.
La justificación normalmente fallaba porque “podríamos perder algo” no es un requisito de ingeniería; es ansiedad.
En su lugar, usaban alias estructurados:
el correo transaccional usaba subdominios dedicados, el correo humano usaba cuentas de rol con aliases explícitos, y cualquier dirección “legacy” obtenía un alias temporal con fecha de caducidad.
También integraron la validación de destinatarios con su directorio—si el usuario no existía, RCPT era rechazado.
Un día una campaña de spam dirigida los atacó: masiva sondas RCPT para variantes admin/info/support.
Sus gateways se mantuvieron tranquilos. Los destinatarios desconocidos fueron rechazados de inmediato. El volumen de spam siguió existiendo, pero no pudo expandirse hacia un crecimiento ilimitado de buzón.
Más importante: su monitorización estaba limpia: las rechazos eran visibles como rechazos, no como “entregado a un buzón que nadie lee”.
La revisión post‑incidente fue casi aburrida. Eso es el cumplido.
Su política “correcta pero poco emocionante” impidió que un mal día se convirtiera en una caída de entregabilidad que durara un trimestre.
Alternativas más seguras: mantener el correo fiable sin el catch‑all
Principio: rechaza destinatarios desconocidos y luego facilita los conocidos
No necesitas catch‑all para evitar perder correo legítimo. Necesitas tres cosas:
(1) aliases explícitos para lo que realmente quieres,
(2) manejo seguro para mensajes mal dirigidos,
(3) visibilidad sobre lo que la gente intentó enviar.
Alternativa 1: Mapas de aliases explícitos (con propiedad)
Mantén una lista controlada de direcciones de rol aceptadas: support@, sales@, billing@, security@, etc.
Añade errores tipográficos conocidos (billingg@) si realmente son de alto valor, pero trátalos como temporales.
La propiedad importa. Cada alias debería tener un equipo responsable y una expectativa de SLA, aunque sea “mejor esfuerzo”.
Alternativa 2: Plus‑addressing para usuarios y sistemas
Si necesitas flexibilidad (rastreo, direcciones por servicio), usa plus‑addressing:
usuario+etiqueta@example.net. Puedes aceptar etiquetas infinitas sin aceptar destinatarios infinitos.
Esto te da la sensación de “nunca perder correo” para direcciones legítimas mientras sigues rechazando destinatarios aleatorios.
Alternativa 3: Un sumidero controlado en un subdominio separado
Si tu negocio realmente necesita aceptar correo mal dirigido durante una migración, hazlo en un subdominio dedicado:
legacy.example.net o oldmail.example.net.
- MX separado y un límite de reputación independiente (en la medida de lo posible).
- Retención rígida (por ejemplo, 7–14 días).
- Control de acceso y auditoría estrictos.
- Límites de tasa y filtrado intensivo.
Mantén el radio de impacto contenido.
Alternativa 4: Verificación SMTP de destinatarios mediante integración con directorio
Si tienes un directorio real de usuarios (LDAP/AD) o una base de datos fuente de la verdad, integra la validación de destinatarios.
Para dominios virtuales, la fuente autoritativa es tu virtual_mailbox_maps o equivalente.
Aquí es donde aparece la higiene operacional: aprovisionamiento/desaprovisionamiento automatizado, sin cuentas obsoletas, sin aliases zombis.
Alternativa 5: Usa una dirección de ingestión para el sistema de tickets (no un catch‑all)
Muchos equipos habilitan catch‑all porque quieren “anything@dominio va a Soporte”.
No lo hagas. Crea un pequeño conjunto de direcciones de entrada (support@, help@, billing@) y enrútalas a un sistema de tickets.
Para todo lo demás: rechaza.
Alternativa 6: Monitorización de “destinatario desconocido” sin aceptar el correo
Una preocupación legítima es: “¿Cómo sabremos qué intentan enviar?”
Respuesta: registra y muestrea los rechazos.
Agrega conteos de rechazos RCPT y los local parts rechazados más frecuentes. Obtienes inteligencia sin almacenar la carga útil.
La carga útil es entrada no confiable; no la necesitas para arreglar la higiene de direcciones.
Requisito de cita (idea parafraseada): Werner Vogels frecuentemente enfatiza que debes diseñar para el fallo y automatizar la recuperación; el correo no es una excepción.
Errores comunes: síntoma → causa raíz → solución
Estos son los patrones que veo cuando catch‑all está involucrado. No son teóricos. Son la lista de “por qué suena mi pager”.
1) Síntoma: El volumen de spam entrante se duplica de repente
Causa raíz: Tu dominio es detectado como accept-all; los spammers aumentan las sondas RCPT.
Solución: Rechaza destinatarios desconocidos en RCPT. Añade límites de tasa. Mantén aliases explícitos para cuentas de rol.
2) Síntoma: El correo legítimo del cliente “desaparece”
Causa raíz: No desaparece; está enterrado en un buzón sumidero enorme o retrasado por indexado/locks de IMAP.
Solución: Quita el catch‑all. Si debes mantener un sumidero temporalmente, entrégalo a una tubería de procesamiento no IMAP con rotación y retención.
3) Síntoma: Tu correo saliente va más a spam
Causa raíz: Degradación de la reputación del dominio debido a patrones ruidosos, posible backscatter y señales operativas pobres.
Solución: Deja de aceptar todo, asegura DKIM correcto, publica una política DMARC sensata y estabiliza la higiene entrante.
4) Síntoma: Crecimiento de colas y alta carga en periodos “aleatorios”
Causa raíz: Oleadas de spam se aceptan y luego se amontonan en escaneo de contenido/AV/entrega IMAP, saturando CPU o disco.
Solución: Empuja el rechazo más temprano (chequeos RCPT), limita la tasa y verifica el rendimiento del disco. No almacenes lo que deberías rechazar.
5) Síntoma: Recibes quejas por rebote de spam que “enviaste”
Causa raíz: Backscatter por aceptar mensajes y luego rebotar a remitentes falsificados.
Solución: Rechaza destinatarios inválidos y fallos de política de contenido durante SMTP, evita generar NDRs a remitentes no autenticados/falsificados.
6) Síntoma: Un único buzón consume almacenamiento absurdo
Causa raíz: Catch‑all como sumidero sin límites, a menudo sin cuotas ni retención.
Solución: Elimina/rota agresivamente, establece cuotas y retenciones, y elimina la ruta catch‑all. Construye una canalización de monitorización de rechazos en su lugar.
7) Síntoma: El equipo de seguridad encuentra datos sensibles de terceros en tu bandeja
Causa raíz: Correo mal dirigido de otros dominios (errores tipográficos) fue aceptado silenciosamente.
Solución: Deja de aceptar todo. Añade un proceso para manejar correo mal dirigido (notificar al remitente, borrar de forma segura, documentar).
8) Síntoma: Equipos internos dependen de direcciones aleatorias “porque funciona”
Causa raíz: Catch‑all crea contratos internos malos; la gente deja de mantener direcciones correctas.
Solución: Elimina el catch‑all y fuerza diseño de interfaces explícitas: aliases definidos, propiedad y gestión de cambios.
Chiste #2: Catch‑all es una gran forma de lograr “cero rebotes” de la misma manera que apagar la monitorización logra “cero alertas”.
Listas de verificación / plan paso a paso
Paso a paso: Eliminar catch‑all sin romper el negocio
-
Inventaria lo que el catch‑all actualmente captura.
Extrae los destinatarios principales de los logs (Tarea 5) y lista los 50–200 local parts más frecuentes.
Decide cuáles son aliases legítimos, cuáles son errores tipográficos que vale la pena salvar y cuáles son basura. -
Crea aliases explícitos para destinatarios legítimos.
Mantén la lista corta y con propietarios. Enruta a equipos o sistemas de tickets, no a buzones personales por defecto. -
Implementa el rechazo de destinatarios.
Haz que los destinatarios desconocidos fallen en RCPT (Tarea 12). Esta es la solución real. -
Añade monitorización para destinatarios rechazados.
Alerta sobre picos. Muestrea local parts rechazados. Quieres visibilidad sin retención de carga útil. -
Aplica cuotas/retención en cualquier buzón sumidero restante.
Si mantienes uno temporalmente, trátalo como desecho peligroso. Pequeño, sellado y vaciado según programa. -
Comunica el cambio.
Informa a equipos internos: las direcciones desconocidas rebotarán ahora; aquí están las direcciones soportadas. Esto previene la “ruleta de correo”. -
Ejecuta un período de gracia de migración con aliases dirigidos.
Para direcciones antiguas, crea redirecciones explícitas que expiren. Pon la fecha de expiración en el ticket. -
Revisa la autenticación saliente.
Confirma la firma DKIM y el estado DMARC (Tareas 13–14). La eliminación del catch‑all suele coincidir con endurecimiento de políticas. -
Mide resultados.
Sigue el volumen de spam entrante, profundidad de colas, crecimiento de buzones y volumen de tickets sobre correo perdido.
Lista de verificación: Cómo se ve “bien” después del cambio
- Un RCPT TO aleatorio recibe un 550 en tiempo SMTP.
- Las direcciones de rol existen explícitamente y están monitoreadas.
- El volumen de spam entrante baja y se mantiene más bajo.
- La profundidad de la cola se correlaciona con carga real, no con oleadas aleatorias.
- No hay patrones de backscatter en los logs.
- El buzón catch‑all (si existe) es pequeño, rotado y con límite temporal.
- Los informes DMARC se revisan y son accionables (no papel tapiz).
Lista de verificación: Si insistes en mantener catch‑all (reglas de contención)
A veces el negocio insiste. Está bien. Entonces trátalo como una función peligrosa:
- Limítalo en el tiempo: fecha de expiración, propietario y plan de reversión.
- Sepáralo: idealmente en un subdominio y MX separados.
- Límites de tasa agresivos: conexiones y mensajes por remitente.
- No lo pongas en IMAP: entrega a una tubería de procesamiento, no a un buzón humano.
- Retención: borrar rápido. No estás construyendo un archivo.
- Revisión de seguridad: control de acceso, auditoría y manejo de incidentes para datos mal dirigidos.
Preguntas frecuentes
1) ¿Un buzón catch‑all siempre es malo?
En producción en tu dominio principal: sí, normalmente es un perjuicio neto. El uso aceptable raro es una ayuda de migración controlada y con tiempo limitado,
idealmente en un subdominio separado con retención y límites de tasa estrictos.
2) ¿Rechazar destinatarios desconocidos no ayuda a los spammers a enumerar usuarios válidos?
Puede, pero en la práctica los spammers ya prueban nombres comunes y cuentas de rol. Mitigas la enumeración con límites de tasa, tarpits y evitando exponer comandos de directorio (VRFY/EXPN).
Accept‑all es peor: garantiza aceptación e invita a abuso de mayor volumen.
3) Habilitamos catch‑all porque los clientes se equivocan al teclear direcciones. ¿Qué deberíamos hacer en su lugar?
Crea aliases explícitos para errores tipográficos de alto valor (billingg@, saless@) y cadúcalos después de corregir la fuente del error (web, PDFs, registros de proveedores).
Usa los logs para encontrar los errores reales en vez de adivinar.
4) ¿Deshabilitar catch‑all dañará la entregabilidad porque tendremos más rebotes?
Tendrás más rebotes precisos, lo cual es bueno. Obliga a los remitentes a mantener listas limpias y reduce el volumen de basura entrante.
La meta no es “cero rebotes”, es “rebotar solo lo que debe rebotar”.
5) ¿Plus‑addressing es un riesgo de seguridad?
No inherentemente. Puede aumentar la superficie de direcciones, pero sigue ligado a un buzón real y a un usuario.
Es mucho más seguro que aceptar cualquier local part aleatorio porque sigues rechazando usuarios desconocidos.
6) Estamos en Microsoft 365 / Google Workspace. ¿El catch‑all sigue importando?
Sí. Incluso las plataformas alojadas reflejan la misma realidad: si aceptas correo para destinatarios inexistentes, ingerirás más spam y crearás desorden operacional.
La plataforma puede absorber parte del dolor, pero tus usuarios y la reputación de tu dominio seguirán pagando.
7) ¿Cómo mantenemos visibilidad de correos mal dirigidos después de desactivar el catch‑all?
Registra los rechazos RCPT y agrega los local parts rechazados. Puedes alertar sobre picos y mantener un informe de “top destinatarios rechazados”.
Eso te da inteligencia sin almacenar cargas útiles no confiables.
8) ¿Y un “catch‑all” que solo atrapa ciertos patrones?
El enrutamiento basado en patrones puede estar bien si es determinista y estrecho (p. ej., user+tag), pero “cualquier cosa va a soporte” sigue siendo un catch‑all disfrazado.
Si el patrón permite nombres de destinatario arbitrarios, vuelves a aceptar entrada controlada por atacantes a escala.
9) Tenemos muchos dominios de marca y necesitamos recibir todo porque los socios adivinan direcciones. ¿Algún compromiso?
Usa cuentas de rol y un directorio bien publicitado de direcciones. Si debes aceptar destinatarios desconocidos, hazlo en un subdominio de entrada dedicado con retención,
luego exige que los remitentes corrijan la dirección tras un breve periodo de gracia. No lo conviertas en permanente.
10) ¿Cuánto tardará en recuperarse la entregabilidad tras quitar el catch‑all?
La reducción del volumen de spam es inmediata. Los efectos en reputación pueden tardar días o semanas dependiendo del volumen y de cómo los receptores puntúan tu dominio/IP.
Lo clave es consistencia: comportamiento estable, correo saliente autenticado y nada de backscatter.
Siguientes pasos
Si actualmente tienes un catch‑all en tu dominio principal, los siguientes pasos prácticos son sencillos:
- Ejecuta la prueba SMTP (Tarea 1) y confirma el comportamiento accept-all.
- Extrae los destinatarios principales de los logs (Tarea 5) y crea una lista corta de aliases con propietarios.
- Deshabilita el catch‑all / restaura la validación de destinatarios (Tareas 2–3), luego vuelve a probar (Tarea 12).
- Contén cualquier buzón sumidero temporal con cuotas y retención (Tareas 8 y 15).
- Vigila la profundidad de la cola, uso de disco y señales de backscatter (Tareas 6, 9, 7).
La fiabilidad del correo no se trata de heroísmos. Se trata de negarse a aceptar tonterías, temprano, de forma consistente y con logs en los que puedas confiar.
Catch‑all es lo opuesto. Quítalo y tu sistema de correo empezará a comportarse como un sistema de ingeniería de nuevo.