Activas un catch-all de dominio para no perder oportunidades cuando alguien escribe saels@ en lugar de sales@. Tiene sentido. Pero el servidor empieza a aceptar destinatarios antes desconocidos, incluidas las pruebas de ataques de recolección de direcciones. Pueden aparecer notificaciones a remitentes falsificados, bucles de respuesta automática y problemas de entrega al reenviar. No son consecuencias inevitables, pero conviene diseñar la arquitectura antes de activar la función.
Muchas guías terminan en «activa el catch-all y envíalo a la bandeja». Aquí empieza el trabajo operativo. Esta guía aborda buzones de cuarentena, rutas con expresiones regulares en Postfix, prevención de bucles y fallos de autenticación durante el reenvío. Consulta primero la guía de configuración del reenvío de correo si necesitas las bases; aquí nos centramos en el catch-all de dominio.
¿Qué es un catch-all de dominio?
Un catch-all es una regla del MTA que acepta correo destinado a direcciones del dominio que no coinciden con ningún destinatario conocido, incluidos buzones, alias y grupos. En lugar de responder 550 User Unknown, puede responder 250 OK y dirigir el mensaje a un destino de respaldo. La aceptación de un destinatario no equivale a la aceptación final del mensaje tras DATA. La regla actúa sobre el destinatario del sobre SMTP; por sí sola no invalida la autenticación.
Sobre y cabeceras: por qué importa la diferencia
Distinguir estas dos capas ayuda a investigar problemas de rutas, autenticación y notificaciones. No todos los problemas del catch-all nacen de esta diferencia. Una corrección de dos minutos una vez identificada la causa es un ejemplo, no un plazo prometido para el diagnóstico.
RFC 5321 define el sobre SMTP, incluidas las órdenes RCPT TO y MAIL FROM intercambiadas durante la conversación SMTP. RFC 5322 define las cabeceras del mensaje, como los campos To: y From: que muestra el cliente de correo.
El MTA puede dirigir un destinatario del sobre desconocido a una dirección de respaldo sin modificar las cabeceras. El To visible no determina necesariamente el destinatario del sobre. SPF comprueba la IP de conexión y el dominio de MAIL FROM o, cuando corresponda, HELO; DKIM verifica criptográficamente las partes firmadas de las cabeceras y el cuerpo; DMARC exige que SPF o DKIM pase y esté alineado con el From visible. El encaminamiento local del destinatario no rompe estas comprobaciones por sí solo. Un salto de reenvío externo puede afectar a SPF, y modificar partes firmadas puede invalidar DKIM.
El fallo asociado al reenvío
Reenviar el catch-all a Gmail u Outlook.com añade un salto que puede cambiar el resultado de la autenticación:
- Remitente original:
client@bank.com(IP: 1.2.3.4) - Tu servidor acepta
typo@yourdomain.comy reenvía ayou@gmail.com - Gmail recibe la conexión desde la IP de tu servidor; el sobre puede seguir usando bank.com
- SPF falla si esa IP no está autorizada por el registro SPF de bank.com
- Si bank.com publica
DMARC p=rejecty tampoco hay DKIM válido y alineado, el receptor puede rechazar el mensaje; el rechazo SMTP puede generar una notificación, aunque no siempre será visible para el usuario
El reenvío necesita sus propias comprobaciones. SRS (Sender Rewriting Scheme) reescribe el remitente del sobre: el registro SPF del dominio utilizado debe autorizar la IP del intermediario. No alinea por sí solo ese dominio con el From original; una firma DKIM válida y alineada que sobreviva al reenvío puede bastar para DMARC. El reenvío mediante alias de TrekMail descrito incorpora gestión de SRS en configuraciones compatibles; verifica las funciones y condiciones actuales. En el modelo Nano descrito, todos los mensajes salientes, incluidas las respuestas, requieren SMTP externo propio; el envío gestionado de los planes de pago depende de sus permisos y de la configuración compatible del cliente.
Tres riesgos de un catch-all de dominio
Conviene revisar tres riesgos antes de cambiar la configuración: notificaciones a remitentes falsificados, bucles de respuesta automática y fallos de autenticación al reenviar. Corregir uno sin comprobar los demás puede convertir una tarea prevista de cinco minutos en una semana de recuperación, como ejemplo de trabajo adicional, no como duración inevitable.
1. Backscatter: riesgo para la reputación
El backscatter puede aparecer cuando el servidor acepta un mensaje catch-all (250 OK) y posteriormente genera una notificación de no entrega (NDR) al rechazarlo. Si el MAIL FROM está falsificado, la notificación llega a alguien que no envió el mensaje. Estas respuestas no solicitadas pueden perjudicar la reputación y contribuir a la inclusión en listas de bloqueo; no existe un plazo inevitable para ello.
Rechaza durante SMTP los destinatarios que queden fuera de las reglas aceptadas, antes del 250 OK correspondiente. Para el tráfico aceptado, utiliza cuarentena y revisión cuando proceda, evitando NDR no solicitadas hacia direcciones posiblemente falsificadas. Esto no significa prohibir toda notificación legítima de no entrega ni descartar por defecto mensajes legítimos.
2. Bucles de respuesta automática (error de Exchange 5.4.14)
Un catch-all dirige el correo a un destinatario de respaldo que puede tener una respuesta de ausencia (OOF). Un mensaje a random@yourdomain.com con remitente falsificado podría provocar una respuesta, una devolución y, si la ruta la envía otra vez a random@yourdomain.com, una nueva aceptación. Este conjunto de reglas puede formar un bucle. Exchange podría devolver 550 5.4.14 Hop count exceeded - possible mail loop.
En sistemas que lo admitan, especialmente Exchange, aplica X-Auto-Response-Suppress: All al tráfico encaminado por comodines para limitar respuestas de ausencia y confirmaciones, incluidas las confirmaciones de lectura. No es un control universal: comprueba las reglas automáticas, Auto-Submitted y las rutas de devolución, y prueba el comportamiento real.
3. Ataques de recolección de direcciones (DHA)
Si todas las direcciones reciben 250 OK, un atacante puede probar miles de combinaciones como admin@, hr@, ceo@ e invoice@. Un catch-all global hace que se acepten estos destinatarios, pero no confirma cuáles corresponden a buzones reales. Aun así, puede aumentar el tráfico no deseado y la carga de revisión; los envíos dirigidos podrían prolongarse durante años, sin que esa duración sea inevitable.
Los comodines parciales de la estrategia 2 permiten limitar la cobertura, sin garantizar el bloqueo de la mayoría de los ataques.
Estrategia 1: buzón separado para revisión y cuarentena
Si necesitas un catch-all, un buzón separado permite revisar tráfico desconocido sin mezclarlo con la bandeja principal. No es un entorno aislado de seguridad: restringe los accesos, mantén los filtros y desactiva los reenvíos, respuestas de ausencia y otras acciones automáticas que no estén autorizadas. Comprueba estas opciones en el buzón y en las reglas del servidor; una cabecera de supresión no sustituye esos controles.
Lógica de implementación:
- Aceptar: el servidor acepta
*@domain.com - Etiquetar: identificar al destinatario como desconocido, sin correspondencia con un buzón, alias o grupo autorizado
- Aislar: dirigir a un buzón dedicado, por ejemplo
catchall_sink@domain.com - Limitar respuestas: en Exchange, evaluar si solicitar mediante Spam Confidence Level 9 el tratamiento de spam de alta probabilidad es apropiado y aplicar
X-Auto-Response-Suppress: Allcuando sea compatible
Una revisión semanal puede ser un punto de partida, pero debe adaptarse al volumen y a la urgencia de los mensajes. Mueve el correo legítimo a su destino correcto y aplica una política de retención al resto. Dimensiona la capacidad, el almacenamiento y la supervisión para que la cuarentena no se convierta en otro lugar donde se pierdan oportunidades.
Regla de transporte en Microsoft 365 / Exchange Online
En M365, este ejemplo requiere revisar los dominios aceptados, conectores, inventario de destinatarios y rutas con un administrador autorizado. El modo Internal Relay desactiva Directory Based Edge Blocking (DBEB), pero no implementa por sí solo un catch-all ni es apropiado si todos los destinatarios están en el servicio en la nube. Para los demás destinatarios se necesita un conector verificado hacia un servidor de correo propio autorizado. No cambies el modo a ciegas: verifica los destinos y la ausencia de bucles. La regla siguiente es un esquema que debe adaptarse; pertenecer a un grupo no sustituye un inventario completo de buzones, alias y otros destinatarios válidos:
| Condición | Valor | Motivo |
|---|---|---|
| Ubicación del remitente | Fuera de la organización | Limitar la regla al tráfico externo |
| Destinatario NO pertenece a | All Valid Users | Excluir los destinatarios válidos según el inventario revisado |
| Redirigir mensaje a | catchall_sink@domain.com | Enviar el tráfico desconocido al buzón separado |
| Establecer SCL en | 9 | Solicita el tratamiento de spam de alta probabilidad; el valor por sí solo no determina el veredicto, la acción ni las notificaciones. Verifica filtros, política y cliente |
| Establecer cabecera | X-Auto-Response-Suppress: All | Limitar respuestas automáticas en sistemas compatibles; comprobar los bucles mediante pruebas |
Planifica y prueba el orden de activación de la regla y cualquier cambio de Internal Relay. Comprueba antes los conectores, la validación de destinatarios y las rutas de destino para evitar una ventana de aceptación sin controles o bucles.
Estrategia 2: comodines parciales con PCRE en Postfix
Un comodín parcial acepta patrones concretos sin abrir todo el dominio. Define expresiones regulares para las direcciones esperadas y configura aparte la validación del resto. La ausencia de coincidencia en un mapa no implica por sí sola un rechazo SMTP; intervienen la clase del dominio, otros mapas y las restricciones de destinatario.
En Postfix puedes usar un mapa de alias virtuales PCRE (Perl Compatible Regular Expression). Antes de recargar, comprueba que el soporte PCRE esté instalado y prueba el mapa con coincidencias deseadas y no deseadas. El comentario del ejemplo no garantiza la validación de destinatarios ni que se cubran todas las erratas mencionadas.
# /etc/postfix/virtual_pcre
# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/ sales-team@yourdomain.com
# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/ support@yourdomain.com
# No wildcard below = hard 550 reject for everything elseAntes de adaptar /etc/postfix/main.cf, guarda una copia de la configuración y comprueba los mapas existentes. Esta asignación reemplaza el valor actual; integra el mapa sin perder otras rutas:
virtual_alias_maps = pcre:/etc/postfix/virtual_pcreDespués de validar patrones, destinatarios y rutas, un administrador autorizado puede recargar: postfix reload
Si necesitas más cobertura, añade patrones conservadores para direcciones comunes en lugar de un comodín global:
/^(info|contact|hello|team)@yourdomain\.com$/ info@yourdomain.comAsí puedes limitar las direcciones aceptadas a las necesarias, siempre que la validación del MTA esté configurada y comprobada.
Cuándo tiene sentido un catch-all de dominio
Un catch-all puede ser útil en situaciones delimitadas. Los usos temporales siguientes son habituales, aunque no son los únicos usos legítimos. La conveniencia de mantenerlo depende de los controles y de la necesidad operativa.
Usos legítimos:
- Direcciones de campañas breves: usar
promo-jan@,promo-feb@ypromo-mar@sin crear manualmente cada destinatario - Incorporación de clientes: recibir correo antes de terminar el alta formal de las direcciones
- Migración de un sistema anterior: cubrir direcciones activas todavía no inventariadas durante el cambio
En estos casos, revisa cuándo retirar el catch-all y crear buzones o alias explícitos para las direcciones conocidas. Si no sabes qué tipo de destinatario necesitas, consulta alias de correo de dominio frente a buzón; sus diferencias ayudan a elegir una estructura sostenible.
Uso poco aconsejable: activar un catch-all solo para evitar una supuesta tarifa de $6/usuario/mes por tres alias. Los alias no requieren automáticamente licencias propias: comprueba el modelo de tu proveedor. Resuelve el coste real en lugar de añadir una arquitectura que resulte difícil de mantener seis meses después.
TrekMail: elegir la arquitectura, no solo un atajo
La facturación por usuario puede influir en la elección de un catch-all. El modelo de TrekMail descrito usa planes de precio fijo y almacenamiento compartido a nivel de cuenta, sujeto también a los límites aplicables a cada buzón. No es una tarifa universal por dominio ni por buzón. Dentro de los límites del plan, puede reducir la necesidad de usar un catch-all como sustituto de alias explícitos. Comprueba precios, cuotas y funciones actuales.
| Precio por usuario | TrekMail: precio fijo según el plan | |
|---|---|---|
| Buzones sales@, support@, info@ | 3× la cuota mensual en el ejemplo de licencias separadas | Disponibles según las funciones y los límites del plan elegido |
| Catch-all como sustituto de alias | Puede evitar costes si el proveedor exige licencias separadas | Una opción operativa, no necesariamente una exigencia de costes |
| Reenvío a Gmail u Outlook | Puede afectar a SPF y DMARC según la ruta y DKIM | SRS gestionado en configuraciones compatibles, sin garantía de DMARC o entrega |
| Migración desde otro proveedor | Puede requerir sincronización IMAP | Verificar permisos, compatibilidad, carpetas, recuentos y copia final de cambios; no sustituye las copias de seguridad ni migra automáticamente contactos y calendarios |
El Starter descrito ($3.50/mes) permite crear direcciones explícitas dentro de sus límites. Verifica las condiciones actuales antes de contratar. Si necesitas un catch-all, revisa su disponibilidad en la configuración del dominio y combínalo con destinatarios definidos para las direcciones de uso habitual. Para empezar desde cero, la guía para configurar correo en tu dominio explica DNS, SPF/DKIM/DMARC y la creación de buzones.
Lista de comprobación antes de activar el catch-all
Antes de activarlo, revisa estos puntos y prueba la ruta completa. Los controles reducen riesgos, pero no eliminan el mantenimiento:
- Validación en el borde SMTP: rechazar durante la conexión las direcciones fuera de los patrones aceptados por el catch-all; evitar notificaciones posteriores no solicitadas a remitentes falsificados.
- Respuestas automáticas controladas: aplicar
X-Auto-Response-Suppress: Allcuando sea compatible y comprobar OOF, Auto-Submitted y rutas para prevenir bucles. - Cuarentena preparada: disponer de un buzón separado de las bandejas operativas, con capacidad, revisión y retención definidas.
- Clasificación de spam revisada: adaptar la política de cuarentena y revisar deliberadamente el correo legítimo, sin descartarlo por defecto.
- SPF y DMARC comprobados: si hay reenvío, revisar SRS, la autorización del dominio reescrito y al menos una vía válida y alineada de SPF o DKIM para DMARC.
- Patrones PCRE cuando proceda: preferir comodines parciales si cubren la necesidad y comprobar la validación del MTA para las demás direcciones.
- Notificaciones NDR controladas: evitar devoluciones no solicitadas a remitentes posiblemente falsificados; conservar el tratamiento apropiado del correo legítimo.
Conclusión
Un catch-all de dominio puede ser útil con rutas comprobadas, validación SMTP fuera de los patrones aceptados, cuarentena y control de respuestas automáticas. Activarlo sin revisar la arquitectura puede aumentar el riesgo de backscatter, bucles y fallos durante el reenvío incluso en cuestión de semanas, sin que esos problemas o ese plazo sean inevitables. Prueba y supervisa el comportamiento real.
Si el motivo es evitar tarifas por usuario, revisa primero las licencias necesarias para buzones y alias. El alojamiento de precio fijo de TrekMail descrito permite elegir direcciones explícitas dentro de los límites del plan, dejando el catch-all como una decisión operativa. Consulta la prueba gratuita y sus condiciones actuales antes de configurar el dominio.
