El correo catch-all es una regla que dirige mensajes para destinatarios desconocidos del dominio a un destino concreto. Ante ghost@yourdomain.com, un servidor puede rechazar ese destinatario con 550 sin cerrar necesariamente la conexión. Un catch-all puede responder 250 OK al destinatario; eso no es todavía aceptación final del contenido después de DATA.
En 2026, recuperar una errata sigue siendo útil, pero conviene controlar volumen, reputación y tratamiento de datos personales. Los problemas dependen del uso y de la configuración, no son inevitables.
Esta guía explica SMTP, cinco áreas de riesgo, autenticación del reenvío y opciones de configuración.
Qué es el correo catch-all
El correo catch-all, también llamado accept-all o comodín, asigna los destinatarios desconocidos de un dominio válido a una ruta de respaldo. En lugar de un error 550 por dirección inexistente, puede admitir el destinatario y entregar el mensaje al destino configurado si supera las demás comprobaciones.
Los paneles usan accept-all y catch-all para este comportamiento: los destinatarios sin coincidencia en RCPT TO reciben una ruta de respaldo. En TrekMail, revisa Dominios → Enrutamiento, llamado Conexión en interfaces anteriores, → Buzón catch-all y selecciona el destino permitido. Comprueba que el cambio se aplique y verifica la ruta real, sin presuponer una actualización instantánea.
Desde finales de los años 1990 hasta 2026, el tráfico automatizado ha cambiado las necesidades de control. Un catch-all puede ocultar qué direcciones existen ante un sondeo, pero admitir destinatarios inventados también puede aumentar procesamiento y almacenamiento.
Por qué se activa el catch-all y qué valorar
Dos motivos habituales son recuperar contactos mal dirigidos y evitar licencias adicionales. Ambos merecen atención, pero deben compararse con alias explícitos, necesidades de buzones y carga de recepción.
Recuperar errores de escritura
Una empresa puede temer perder un contacto por suport@ en lugar de support@. El catch-all puede recuperarlo, aunque también recibir tráfico inventado. Define quién revisa el destino y cuánto correo no deseado puede manejar sin ocultar mensajes útiles.
Para erratas conocidas, configura alias concretos. Si utilizas support@, puedes añadir suport@ al mismo destino. Eso limita la recepción arbitraria, pero sigue requiriendo filtros y controles.
El coste de las licencias
Una referencia histórica de Google Workspace y Microsoft 365 sitúa licencias en $6-30 por usuario y mes. support@, billing@, jobs@ y marketing@ con cuatro licencias independientes podrían sumar hasta $120/mes en ese ejemplo. Alias, buzones compartidos o licencias existentes pueden tener otras condiciones; no hacen obligatorio un catch-all.
Compara el coste completo, los permisos y los controles. El almacenamiento agrupado puede cambiar el cálculo sin eliminar riesgos por sí solo. Consulta los planes de TrekMail y sus condiciones actuales.
Cómo funciona en SMTP
En RCPT TO, el emisor indica el destinatario antes de transferir el contenido. El servidor puede admitirlo o rechazarlo; después pueden aplicarse otras comprobaciones. La seguridad no depende únicamente de esta respuesta, sino también de autenticación, filtros, rutas y aceptación final.
Rechazo de un destinatario desconocido
S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)
No hay destinatario válido llamado ghost y el servidor devuelve 550. El ejemplo simplifica el intercambio: no es obligatorio cerrar la conexión y ya se han transferido comandos SMTP. No se acepta contenido para ese destinatario, aunque puede haber otros destinatarios válidos en la transacción.
El flujo con catch-all
S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com
La ruta admite el destinatario desconocido. La recepción final del contenido es posterior y puede depender de filtros durante DATA. Si el servidor acepta el mensaje, debe gestionar su entrega, almacenamiento y posibles errores sin avisar a identidades falsificadas.
A gran escala, rechazar destinatarios desconocidos puede ahorrar análisis y almacenamiento. El catch-all puede aumentar la carga, pero no exige aceptar todo contenido antes de filtrarlo. Revisa límites y fases de filtrado con el proveedor.
Los 5 riesgos operativos
Admitir destinatarios inventados amplía la recepción y puede aumentar el tráfico no deseado. Es un cambio del servidor, no una promesa ligada a la propagación DNS. Evalúa las siguientes áreas antes de activarlo.
Riesgo 1: sondeos de directorio y volumen
Los ataques de recopilación de direcciones prueban millones de nombres posibles: admin, david, invoice, hr, webmaster, noreply. Buscan distinguir destinatarios que se aceptan de los que se rechazan.
Una respuesta 550 puede revelar una dirección inexistente, pero no obliga al atacante a detenerse. El catch-all dificulta distinguir direcciones creadas e inventadas. Aun así, una subida de 50 mensajes diarios a 50,000 es un escenario de carga que puede consumir cuotas y filtros y ocultar correo legítimo.
Riesgo 2: backscatter y reputación remitente
El backscatter aparece al enviar avisos posteriores a una identidad de sobre falsificada. Un ejemplo:
- Un atacante envía a
random-gibberish@yourdomain.comen un dominio con catch-all. - Falsifica MAIL FROM, que se refleja en
Return-Pathal entregarse, como una víctima:victim@gmail.com. Una cabecera aportada por el atacante no determina de forma fiable el remitente de sobre. - El servidor acepta definitivamente el mensaje después de admitir el destinatario.
- Un filtro posterior detecta correo no deseado y produce un fallo interno.
- Si el servidor genera un NDR al remitente de sobre, reflejado en
Return-Path, lo envía avictim@gmail.com. - La víctima recibe un aviso no solicitado por un mensaje que no envió.
Este tráfico puede perjudicar reputación y contribuir a listas como ips.backscatterer.org. No implica bloqueo inevitable ni spam automático para toda salida legítima. Rechaza durante SMTP cuando proceda o utiliza cuarentena segura sin respuestas a identidades falsificadas. Consulta cómo investigar la reputación del dominio.
Riesgo 3: responsabilidad de las rutas
Un mensaje para partnerships@company.com puede terminar en el buzón común. Si no hay responsable, puede permanecer sin revisar durante días. Asigna propietarios, acceso y un procedimiento de revisión según la urgencia del tráfico.
Con alias explícitos, puedes definir quién recibe cada dirección. Verifica el destino de partnerships@ y documenta responsabilidades; el alias por sí solo no garantiza una respuesta.
Riesgo 4: carga de soporte para proveedores gestionados
En agencias con 50+ dominios, conviene preparar respuesta a incidencias como:
- “El buzón está lleno y tarda en cargar”: revisa cuota, almacenamiento y volumen.
- “Recibo demasiado spam”: revisa filtros y destinatarios admitidos.
- “No encuentro el mensaje del cliente”: puede estar, por ejemplo, en la página 400 del buzón común.
- “Mis salidas van a spam”: investiga autenticación, reputación y posibles avisos indebidos.
Si comparas catch-all y alias, una reducción del 30-40% de incidencias puede ser un objetivo ilustrativo de planificación, no un resultado medido ni prometido. Registra el volumen real y el tiempo de revisión antes y después del cambio.
Riesgo 5: minimización y protección de datos
El artículo 5(1)(c) del GDPR exige minimización de datos para la finalidad aplicable. Un catch-all puede recoger información no necesaria, pero la valoración depende de propósito, base jurídica, acceso y conservación. Define qué recibes, por qué y cómo gestionas datos personales.
Localizar datos entre 500,000 mensajes puede complicar solicitudes de supresión. Si doctor@yourclinic.com dirige información sanitaria a un destino común, revisa roles, autorización, flujos y salvaguardas HIPAA cuando sean aplicables. El acceso de personal técnico no determina por sí solo una infracción; exige una evaluación real del tratamiento.
SPF, DKIM y DMARC con catch-all
La regla catch-all no rompe directamente estos protocolos. Los resultados dependen de quién envía, las identidades, las firmas y los cambios al reenviar. Separar autenticación, reputación y ruta ayuda a encontrar la causa.
| Protocolo | Qué comprueba | Aspectos a revisar |
|---|---|---|
| SPF | Autorización de IP para la identidad SMTP evaluada, normalmente MAIL FROM | Catch-all no cambia SPF; el reenvío con sobre original puede usar una IP no autorizada |
| DKIM | Firma criptográfica de las partes firmadas de cabeceras y contenido | Cambios en partes firmadas pueden afectar a la firma; no cualquier modificación la invalida |
| DMARC | Una comprobación SPF o DKIM exitosa y alineada con el dominio From visible | DKIM válido y alineado puede pasar DMARC aunque falle SPF al reenviar |
Al reenviar, revisa la IP intermediaria y las identidades reales. Los informes DMARC se envían para el dominio From original, no siempre para el dominio del reenviador. Google Postmaster Tools ofrece datos agregados elegibles para Gmail personal, no un registro completo del catch-all ni de todas las quejas de spam. Estas son denuncias de los usuarios, no fallos de autenticación.
El problema del reenvío
Reenviar todo a Gmail personal puede parecer cómodo, pero exige controlar remitentes, filtros, autenticación y acceso. Un destinatario desconocido no debe convertir el dominio en una vía de reenvío indiscriminado.
Por qué puede fallar la autenticación
El receptor ve una conexión desde tu IP intermediaria mientras la cabecera From: puede conservar bank@chase.com. SPF evalúa la identidad SMTP, no esa cabecera visible por sí sola. Comprueba el sobre y las firmas:
- SPF: con MAIL FROM del dominio original, la IP del intermediario debe estar autorizada por ese dominio para pasar.
- DKIM: un pie, asunto o adjunto modificado puede invalidar la firma si afecta a las partes firmadas; también hay otras causas de fallo.
- DMARC: basta SPF o DKIM exitoso y alineado. Si ninguno lo cumple, el receptor aplica sus políticas y las del dominio.
El resultado puede ser rechazo, demora, cuarentena, spam u otra acción; no siempre hay borrado silencioso. Para p=reject, comprueba el resultado real en registros y avisos. La guía de diagnóstico y configuración del reenvío explica las verificaciones.
SRS y ARC cuando necesitas reenviar
Durante migraciones o flujos antiguos, revisa dos tecnologías: SRS reescribe el sobre y ARC transmite resultados previos firmados. Su necesidad depende de la ruta; DKIM original válido y alineado puede permitir DMARC sin ambas.
SRS (Sender Rewriting Scheme)
SRS reescribe el remitente de sobre para que SPF evalúe el dominio usado por el intermediario, que puede ser tu dominio. Su registro SPF debe autorizar la IP real del reenvío.
Antes de SRS
Envelope From:alice@example.comDespués de SRS
Envelope From:SRS0=HASH=TT=example.com=alice@your-forwarder.comEl receptor evalúa SPF para
your-forwarder.com. Comprueba que la IP esté autorizada y que la evaluación se complete correctamente.
SRS no resuelve por sí solo la alineación DMARC. La cabecera From: conserva alice@example.com y el sobre utiliza your-forwarder.com, sin alineación entre esos dominios. Una DKIM original válida y alineada puede satisfacer DMARC; modificar partes firmadas puede impedirlo. Consulta reenvío mediante SRS.
ARC (Authenticated Received Chain)
ARC permite que los intermediarios transmitan resultados de autenticación anteriores mediante cabeceras firmadas. No convierte una declaración del servidor en prueba automática de confianza: hay que verificar la cadena y la identidad del sellador.
Un receptor puede valorar una cadena ARC válida de un intermediario en el que confía. RFC 8617 define el mecanismo; la decisión de entrega sigue dependiendo de las políticas del receptor.
Validez criptográfica, confianza en el sellador y reputación de envío son aspectos relacionados pero distintos. Recibir miles de mensajes no prueba por sí solo que un intermediario no sea confiable. Evita backscatter y reenvío abusivo y verifica decisiones reales sin prometer entrega por ARC.
Configurar el catch-all con controles
Si recuperas erratas, migras o mantienes compatibilidad, define alcance, responsables y filtros. Estas tres estrategias ofrecen criterios, no aislamiento o seguridad automáticos.
Estrategia A: destino de revisión separado
Usa una recepción controlada con permisos y revisión adecuados. Un buzón de cuarentena no es por sí solo una sandbox de seguridad.
- Crea
catchall-quarantine@yourdomain.comcon acceso limitado y sin Send As, reenvíos ni respuestas automáticas. - Dirige solo los destinatarios desconocidos del dominio autorizado a ese destino.
- En Microsoft 365, asignar SCL 9 solicita clasificar el mensaje como spam de alta probabilidad; la política determina spam, cuarentena y avisos. No lo apliques ciegamente a todo correo catch-all: verifica el efecto con el administrador.
- Define una revisión semanal como referencia y ajusta la frecuencia al tráfico y urgencia; no ignores correo legítimo pendiente.
En TrekMail, comprueba el destino dedicado y las vistas disponibles. Una vista filtrada no aísla almacenamiento ni permisos; revisa acceso, filtros, cuota y búsqueda de mensajes mal dirigidos.
Estrategia B: Microsoft 365, DBEB e Internal Relay
En dominios autoritativos, DBEB (Directory-Based Edge Blocking) puede rechazar destinatarios desconocidos según el directorio. Verifica la configuración real y que todas las direcciones válidas estén registradas.
Internal Relay Mode desactiva DBEB, pero no implementa por sí solo un catch-all. Requiere directorio, conectores, rutas y prevención de bucles compatibles con la topología. No cambies el tipo de dominio únicamente para admitir destinatarios desconocidos; un administrador autorizado debe revisar el diseño y el volumen.
Estrategia C: patrones limitados en Postfix
Para patrones parciales necesitas un mapa compatible, como PCRE o regexp, revisado y correctamente anclado. El ejemplo siguiente en un mapa hash ordinario es literal, no un comodín funcional:
# /etc/postfix/virtual
sales-*@yourdomain.com sales-bucket@yourdomain.com
Un patrón real revisado podría cubrir sales-q1@, sales-webinar@ y sales-2026@ sin admitir admin@ o hr@. El mapa hash mostrado no lo hace automáticamente. Verifica anclaje, dominio, expansión de alias y ausencia de bucles antes de usar otra implementación.
| Estrategia | Recepción no deseada | Administración | Usos a valorar |
|---|---|---|---|
| Catch-all completo → buzón activo | Puede aumentar volumen | Revisión y filtros continuos | Solo con controles adecuados al caso |
| Destino de revisión | Depende de filtros y acceso | Revisión según necesidad | Erratas y migraciones |
| Internal Relay + SCL=9 (M365) | No es una receta catch-all autónoma | Revisión de políticas y topología | Solo diseños Exchange justificados |
| Patrones parciales Postfix | Menos destinatarios arbitrarios | Mantenimiento del mapa compatible | Direcciones de campañas delimitadas |
| Sin catch-all y con alias explícitos | Puede seguir habiendo spam | Gestión de direcciones y filtros | Destinatarios conocidos |
Alias y rutas explícitas como alternativa
Los alias explícitos definen direcciones y responsables y limitan destinatarios arbitrarios. Pueden cubrir muchas necesidades sin catch-all, pero no eliminan spam, fallos de autenticación ni obligaciones de protección de datos.
Alias, buzones y catch-all: criterios de decisión
| Alias explícito | Buzón completo | Destino catch-all | |
|---|---|---|---|
| Almacenamiento | Normalmente usa el destino, no otro buzón | Sí, según servicio | Depende del destino y la retención |
| Exposición a spam | Dirección conocida, requiere filtros | Dirección conocida, requiere filtros | También destinatarios desconocidos |
| Autenticación | Revisar si se reenvía | Verificar entrada y salida | Revisar el reenvío y las identidades |
| Coste por usuario | Según plan y límites | $6-30/mes como referencia histórica de licencias | Incluye coste operativo y condiciones del servicio |
| Datos personales | Finalidad, acceso y conservación por definir | Finalidad, acceso y conservación por definir | Puede recoger información innecesaria |
| Responsabilidad | Asignar propietario y ruta | Asignar propietario y acceso | Asignar revisión y responsables |
Incluye filtrado, almacenamiento, soporte y seguimiento de reputación en la comparación. Su impacto depende del tráfico y del servicio. Para decidir entre alias y buzón, consulta qué son los alias, cómo configurarlos y cuándo usarlos.
Qué direcciones crear
Enumera las direcciones reales del negocio. Estas cinco son ejemplos, no un máximo suficiente para toda empresa:
hello@oinfo@: consultas generales al responsable designado.support@: soporte al helpdesk o buzón compartido.billing@: facturas y pagos a finanzas.jobs@ocareers@: selección a RR. HH. o una integración ATS autorizada.noreply@: salida transaccional; decide cómo gestionar respuestas legítimas, sin descartarlas ciegamente.
Cinco alias pueden cubrir este ejemplo, aunque otros negocios necesitan más. Ante helo@ en lugar de hello@, un rechazo 550 puede permitir que el emisor corrija la dirección, sin garantizar que lo haga. Evita que mensajes útiles permanezcan tres semanas sin revisar en un destino común.
El modelo de TrekMail para catch-all
Comprueba qué planes TrekMail admiten catch-all y sus destinos, límites y costes actuales. El modelo de cobro puede permitir más direcciones explícitas sin convertir el catch-all en necesario ni eliminar sus riesgos.
Ejemplo de licencias por usuario
Con una referencia histórica de $6-30/mes por buzón, support@, billing@ y jobs@ con tres licencias nuevas podrían sumar hasta $90/mes. Verifica precios y alternativas de alias o recursos compartidos antes de cambiar rutas para ahorrar.
Comparar el plan TrekMail
Revisa espacio agrupado por cuenta, dominios, buzones y límites. Como referencias históricas, Starter a $3.50/mes menciona 50 dominios y Pro a $10/mes menciona 100. Verifica las condiciones vigentes y el coste de direcciones adicionales; no presupongas capacidad ilimitada ni gratuidad universal.
Si necesitas catch-all por migración o compatibilidad, configura un destino separado con acceso y filtros adecuados. Separar buzones no garantiza aislamiento de cuota o recursos compartidos. Consulta la documentación del buzón catch-all de TrekMail y comprueba la configuración actual.
Revisa dos posibilidades según el plan vigente: reenvío de buzón a varios destinos con copia local opcional, y destino catch-all externo cuando esté permitido. Pro y Agency se citan para esta segunda opción, pero verifica permisos, rutas y condiciones actuales. Un dominio aparcado también necesita proteger recepción y autenticación. Consulta cómo dirigir un dominio sin crear un buzón local.
Para comparar opciones, consulta una posible prueba gratuita de 14 días y sus requisitos actuales, incluida la tarjeta cuando corresponda. En el modelo Nano con SMTP propio, configura ese servicio para todas las salidas y respuestas.
Preguntas frecuentes
Estas preguntas ayudan a evaluar o retirar una configuración catch-all y a preparar las comprobaciones necesarias.
Qué es el correo catch-all
Es una regla de servidor que asigna destinatarios desconocidos del dominio a una ruta de respaldo. En lugar de rechazar el destinatario con 550, puede admitirlo y después aplicar filtros y aceptación final del mensaje. Accept-all y rutas comodín son nombres usados en algunas interfaces; revisa el comportamiento concreto.
Es seguro utilizar catch-all
Depende de finalidad, filtros, acceso, volumen, conservación y destino. Puede aumentar carga o riesgos de avisos indebidos, sin provocar por sí solo fallos de autenticación o infracciones. Usa un destino controlado, ajusta revisión a la urgencia y no apliques puntuaciones máximas ni ignores correo legítimo indiscriminadamente.
Afecta a la entregabilidad de salida
Puede afectarla indirectamente si se generan avisos a identidades falsificadas o se reenvía tráfico abusivo. Los fallos de autenticación requieren verificar el sobre, las firmas y el From original; los informes no se atribuyen siempre al reenviador. Investiga resultados concretos, no una degradación inevitable por activar catch-all.
Qué diferencia hay entre catch-all y alias
Un alias define una dirección y su ruta. El catch-all admite destinatarios desconocidos del dominio según las políticas y los dirige a un respaldo. Una lista de cinco alias puede cubrir un ejemplo sencillo, pero las necesidades reales determinan cuántos crear.
Puede utilizarse en Google Workspace o Microsoft 365
Revisa las funciones actuales y permisos de cada producto. En Google Workspace, prepara una regla entrante en Gmail → Enrutamiento para destinatarios inactivos o desconocidos que cambie el destinatario de sobre al destino elegido, sin incluir usuarios activos o grupos. En Microsoft 365, Internal Relay desactiva DBEB, pero no crea un catch-all por sí solo; necesita directorio, conectores y rutas compatibles y sin bucles. Un administrador autorizado debe validar la topología antes de cambiarla. Alias y buzones compartidos pueden evitar licencias adicionales según sus condiciones.
Cómo desactivar el catch-all
Primero identifica destinatarios legítimos y prepara alias o buzones. En cPanel/WHM, revisa Inicio → Correo → Dirección predeterminada y elige rechazo SMTP con error, no aceptación seguida de descarte silencioso. En Google Workspace, revisa Gmail → Enrutamiento, o Enrutamiento predeterminado si allí existe una regla antigua, y retira la regla tras comprobar rutas. En Microsoft 365, usa modo autoritativo solo si el directorio incluye todos los destinatarios válidos y los conectores están revisados. En TrekMail, revisa Dominios → dominio → Enrutamiento, Conexión en interfaces anteriores, → Buzón catch-all → Sin catch-all. Una ventana de 24-48 horas puede orientar el seguimiento, no es un plazo obligatorio de estabilización.
Qué utilizar en su lugar
Define alias y rutas para las direcciones realmente utilizadas; cinco o menos puede bastar para un caso sencillo, no para todos. Compara buzones compartidos, licencias y planes actuales. Elige según recepción, responsables y controles, no suponiendo que un modelo de precio elimina problemas de autenticación o reputación.
