El hosting de correo catch-all permite dirigir a un destino los mensajes para destinatarios desconocidos de tu dominio. Es una regla del servidor de correo, no un registro DNS comodín. Puede recuperar erratas, pero no garantiza que todo mensaje se acepte o se entregue.
En la comprobación de destinatarios, el servidor puede sustituir 550 5.1.1 User Unknown por 250 OK al recibir RCPT TO. Los sondeos de directorio prueban nombres como admin@, invoice@, payroll@ y careers@. El catch-all dificulta distinguir direcciones creadas e inventadas por la respuesta, aunque puede aumentar la carga. El umbral histórico de Cisco de 25 destinatarios inválidos por hora es un ejemplo de política configurada por host remoto o IP, no un límite universal del dominio; un ataque intenso puede probar miles por minuto.
Los filtros, cuotas y políticas del proveedor pueden afectar al servicio durante un ataque, sin que la suspensión sea inevitable. Las ocho comprobaciones siguientes ayudan a preparar controles y a encontrar el correo legítimo entre tráfico no deseado.
Para entender la arquitectura, destinos de revisión, mapas de filtrado PCRE y prevención de bucles Exchange, empieza por el catch-all de dominio sin perder el control. Después aplica esta lista a tu configuración concreta.
Qué cambia el catch-all en SMTP
El catch-all modifica la validación del destinatario en el sobre SMTP. En vez de rechazar un destinatario desconocido antes de DATA con 550, puede asignarlo a un buzón de respaldo. Eso no obliga a trasladar todo el filtrado a después de la aceptación: se puede comprobar durante DATA y rechazar antes de aceptar definitivamente el mensaje.
Los mensajes que pasan las comprobaciones pueden generar colas, análisis y almacenamiento. Si después se envían avisos de no entrega a un MAIL FROM falsificado, se produce backscatter: notificaciones a terceros inocentes. Una retirada de listas de bloqueo puede tardar 2-4 semanas en un caso ilustrativo, pero no tiene plazo fijo ni afecta necesariamente a todo un rango de IP.
La decisión combina flexibilidad para destinatarios desconocidos con carga de procesamiento y controles. Conserva el rechazo SMTP cuando proceda y evita avisos posteriores a identidades falsificadas.
Las 8 comprobaciones para hosting catch-all
Revisa ocho aspectos: filtrado antes de la aceptación final, trazabilidad SMTP, protección frente al volumen, autenticación del reenvío, identidades de respuesta autorizadas, control de backscatter, exportación de datos y gestión del almacenamiento. Valóralos según el servicio y el tráfico reales.
1. Filtrado SMTP antes de la aceptación final
Pregunta qué controles se aplican a la conexión, los destinatarios y DATA. Un 250 OK a RCPT TO no es todavía aceptación definitiva. También puede haber filtros de contenido durante DATA que rechacen antes de asumir la responsabilidad del mensaje.
Este ejemplo muestra un rechazo durante SMTP:
postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
from=<probe@attacker.com>, to=<random123@yourdomain.com>Este otro muestra un resultado del filtro que necesita contexto:
amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
<probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2La línea de Amavis no demuestra por sí sola cuándo se aceptó o encoló el mensaje. Correlaciona registros y respuesta final de DATA. Pregunta al proveedor en qué fases filtra, si rechaza durante SMTP y cómo gestiona cuarentenas y avisos posteriores. Decir que tiene filtro antispam no permite deducir su arquitectura.
2. Acceso útil a registros SMTP
El catch-all elimina algunos rechazos por destinatario desconocido. Si un cliente escribió a billing@ y no recibió respuesta, el contador del panel no explica lo ocurrido. Necesitas trazas o registros que permitan relacionar conexión, identificación del mensaje, filtro y ruta.
Un ejemplo de datos para correlacionar:
Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
<client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5Google Workspace y Microsoft 365 ofrecen herramientas administrativas cuyo detalle y actualización dependen del producto y los permisos. Un retraso de 30-60 minutos es un ejemplo, no un plazo universal. Comprueba acceso autorizado, retención, privacidad y vías de soporte para investigar un mensaje concreto.
3. Límites de volumen que protejan tu operación
Los sondeos pueden generar miles de destinatarios inventados. La respuesta comodín oculta cuáles existen, pero el volumen puede consumir recursos y activar políticas del proveedor. Averigua cómo se limita el origen, qué controles preservan el tráfico legítimo y en qué circunstancias se restringe la cuenta.
Pregunta con un escenario concreto: “Si recibimos 10,000 mensajes en una hora por un ataque de directorio, ¿cómo limitan el origen y protegen nuestra cuenta?”.
| Proveedor | Ámbito a comprobar | Respuesta frente a DHA | Evaluación para catch-all |
|---|---|---|---|
| Google Workspace | ~60 mensajes/minuto de recepción como escenario histórico, no límite universal | Revisar cuotas y políticas actuales | Depende de configuración y necesidades |
| Microsoft 365 | Controles actuales de recepción y del tenant | HRDP es enrutamiento de salida, no un pool de entrada catch-all | Revisar rutas y políticas aplicables |
| Hosting cPanel compartido | Cuotas de cuenta y recursos del servidor | Depende del proveedor y los controles | No hay una respuesta universal |
| Postfix/Exim dedicado | Controles configurables de conexión y recursos | Puede limitar el origen si está bien configurado | Requiere ajuste y supervisión |
4. SRS, ARC y autenticación del reenvío
Si un servidor A recibe el catch-all y reenvía a Gmail u Outlook, revisa dos puntos de autenticación. Comprueba las identidades del sobre y los resultados de la ruta real.
SPF: el receptor ve la IP del intermediario. Con un registro como v=spf1 ... -all, conservar el MAIL FROM original puede hacer fallar SPF si esa IP no está autorizada.
DMARC: si no pasa SPF alineado ni DKIM válido y alineado, una política p=reject solicita rechazo. El resultado depende del receptor; no equivale siempre a borrado silencioso. Cambios en partes firmadas pueden afectar a DKIM, que también puede fallar por otros motivos.
Comprueba cómo aplica el servicio estos mecanismos:
- SRS (Sender Rewriting Scheme): reescribe Envelope-From; el SPF del dominio utilizado debe autorizar la IP del intermediario. No alinea automáticamente el From original. Consulta cómo funciona SRS y por qué puede fallar.
- ARC (Authenticated Received Chain): definido en RFC 8617, transmite resultados anteriores mediante una cadena firmada. El receptor debe validarla y confiar en un sellador verificado.
Estos códigos corresponden a causas diferentes, no demuestran conjuntamente que falten SRS y ARC:
550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
due to the domain's DMARC policy.El primer resultado indica una política de reenvío externo; el segundo requiere revisar DMARC y el contexto. DKIM alineado puede permitir DMARC sin SRS ni ARC. Confirma funciones documentadas y resultados reales, sin deducir ausencia de soporte por una mención omitida.
5. Alias e identidades de respuesta autorizadas
El catch-all permite recibir para billing@, support@ o project-2026@, pero no concede permiso para enviar con cualquier identidad. En Gmail, responder como billing@yourdomain.com desde una cuenta principal admin@yourdomain.com requiere configurar “Send As” y la verificación aplicable. Se verifica cada identidad configurada cuando corresponde, no cada mensaje.
Comprueba qué identidades autorizadas admite el cliente y qué SMTP y permisos requieren. Un trámite de soporte o una espera de 24 horas puede ser un ejemplo de fricción, pero no justifica enviar con direcciones sin verificar. Prepara los remitentes necesarios antes de usarlos.
6. Control de backscatter y avisos de no entrega
Si el servidor acepta un mensaje y después genera un NDR a un MAIL FROM falsificado por cuota, ruta o filtro, envía un aviso a un tercero inocente. Eso es backscatter y puede perjudicar la reputación o contribuir a listas como Backscatterer.org. No es automáticamente un open relay.
Pregunta cómo se rechaza durante SMTP o se mantiene una cuarentena segura sin avisos a identidades falsificadas. No borres automáticamente correo legítimo o ambiguo solo por una puntuación; define revisión y retención. La reputación del dominio remitente depende también de estas decisiones.
7. Acceso IMAP y exportación comprobable
Los buzones catch-all pueden acumular datos rápidamente. Antes de una migración, confirma cómo exportar y verificar el correo con acceso autorizado y herramientas compatibles. Prepara una copia de seguridad y una sincronización final de los mensajes que lleguen durante el cambio. IMAP es una opción estándar, pero una exportación adecuada del proveedor también puede servir; evalúa qué datos incluye cada método y planifica por separado los contactos y calendarios.
Comprueba al menos:
- Acceso IMAP por el puerto 993 con TLS, si se utiliza ese método.
- Exportación .eml o .mbox con verificación de contenido y carpetas.
- Lecturas masivas coordinadas con límites, permisos y capacidad del servicio.
POP3 no conserva una jerarquía de carpetas como IMAP; el borrado depende de DELE y de las opciones del cliente, no es obligatorio por defecto del protocolo. IMAP no garantiza por sí solo una migración sin pérdidas ni todos los metadatos. Compara carpetas, recuentos, exclusiones y resultados de la exportación.
8. Almacenamiento y comportamiento al alcanzar la cuota
Comprueba qué ocurre al llenarse el destino. Una respuesta temporal 452 4.2.2 Insufficient storage puede permitir reintentos, sujetos a la política y al plazo de la cola del emisor. No garantiza entrega posterior. Averigua si hay avisos, registros o cuarentena y evita pérdidas silenciosas por cuota.
Pregunta si el espacio se asigna por buzón o se comparte por cuenta, dominio u otro ámbito. Consumir el 80% de una cuota compartida durante un ataque es un escenario ilustrativo, no una proporción universal. Los límites individuales pueden reducir impacto, pero revisa también recursos compartidos y alertas.
Cómo valorar el modelo de TrekMail
TrekMail ofrece almacenamiento agrupado según cuenta y plan. Verifica cómo se facturan dominios y buzones y qué límites aplican; no presupongas buzones ilimitados o espacio separado por dominio. Configura jobs@, billing@, support@, archive@ y las direcciones necesarias, comparando también alias y recursos compartidos.
Una referencia histórica de $6-$12/mes por usuario puede motivar la búsqueda de alternativas para una dirección que recibe tres mensajes al mes. Pero alias, buzones compartidos y licencias existentes pueden evitar cuentas adicionales. Compara el diseño completo:
| Escenario | Ejemplo histórico de licencias por usuario | TrekMail: condiciones por verificar |
|---|---|---|
| Añadir jobs@ (5 mensajes/mes) | $72-$144/año si exige una licencia adicional en el ejemplo | Verificar inclusión y límites del plan |
| Añadir 10 buzones de proyecto | 10× la tarifa mensual si todos requieren licencia | Verificar capacidad y precio vigentes |
| Almacenamiento | Revisar cuotas y recursos compartidos aplicables | Comprobar el ámbito del almacenamiento agrupado |
| Necesidad de catch-all | No es obligatoria para ahorrar licencias | Depende de direcciones y requisitos reales |
Si necesitas catch-all para rutas antiguas, compatibilidad o contactos, verifica recepción, trazabilidad, IMAP y SRS disponibles actualmente. La referencia histórica Starter es $3.50/mes para 50 dominios con espacio agrupado. Comprueba una posible prueba de 14 días con tarjeta. La referencia gratuita menciona 10 dominios, 5GB agrupados y SMTP propio; confirma elegibilidad y condiciones Free/Nano sin tarjeta. Solo en el modelo Nano descrito necesitas SMTP externo propio para todas las salidas y respuestas; el SMTP gestionado de los planes de pago depende de los permisos vigentes y de la configuración de un cliente compatible.
Conclusión
El hosting catch-all es una herramienta, no una configuración que debas activar por defecto. Revisa filtrado, volumen, trazabilidad, reenvío y cuotas con el proveedor. La retirada de una lista de bloqueo puede llevar semanas, sin un plazo fijo. Planifica la respuesta a ataques y las comprobaciones de correo legítimo antes de depender de la regla.
Identifica cuándo se acepta definitivamente el mensaje, cómo se evita backscatter y cómo se preserva la autenticación. Resolver las consecuencias de backscatter puede llevar semanas, según el incidente y el receptor. Después compara exportación, almacenamiento e identidades autorizadas. Si buscas ahorrar, evalúa precios actuales, alias y buzones adecuados; cambiar el modelo de cobro no elimina por sí solo los riesgos operativos.
Consulta TrekMail y verifica precios, buzones IMAP y condiciones actuales del catch-all.
