Una dirección de correo catch-all dirige a un destino los mensajes para destinatarios desconocidos de tu dominio. Alguien escribe slaes@yourcompany.com en vez de sales@ y la regla puede recuperar ese contacto. Es una ventaja útil, pero no significa aceptar cualquier mensaje sin filtros ni condiciones.
Esta red de seguridad amplía la recepción a direcciones que no has creado. Puede aumentar la carga de spam y requiere controlar los rechazos posteriores y la autenticación si reenvías a otro servicio. La comodidad debe valorarse junto con el trabajo de filtrado, almacenamiento y supervisión.
Esta guía explica el comportamiento SMTP, tres riesgos que conviene revisar y alternativas para recibir con mayor control. Para rutas y configuración, consulta cómo gestionar el catch-all del dominio sin perder el control.
Qué es una dirección de correo catch-all
Un catch-all, también llamado dirección comodín, asigna los destinatarios desconocidos de un dominio válido a un buzón o ruta concreta. El servidor puede responder “250 OK” al comando RCPT TO en lugar de “550 User unknown”. Aceptar un destinatario no equivale a aceptar definitivamente el mensaje después de DATA; los filtros y otras políticas siguen siendo relevantes.
Rechazar destinatarios desconocidos durante SMTP antes de recibir su contenido es una política de rechazo por defecto. Un catch-all introduce una política de aceptación de destinatarios desconocidos, no una obligación de aceptar malware o spam. Erratas legítimas y direcciones inventadas pueden compartir destino si el mensaje supera las comprobaciones aplicables.
Puede ayudar durante una migración o en usos permanentes bien delimitados. Requiere controles adecuados al tráfico real.
Cómo funciona el catch-all en SMTP
La distinción aparece en RCPT TO, definido en RFC 5321. El servidor decide sobre ese destinatario antes de recibir el contenido de la transacción. Los ejemplos simplifican el intercambio: ya se han transferido comandos y respuestas, y la aceptación final del mensaje es un paso posterior.
Sin catch-all: rechazo del destinatario desconocido
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT: Connection closed. Zero data transferred.El rechazo se refiere a ese destinatario; no obliga a cerrar la conexión. El servidor emisor decide cómo informar al remitente y el aviso no tiene por qué ser inmediato. No se acepta contenido para el destinatario rechazado, aunque ya hubo intercambio SMTP y puede haber otros destinatarios válidos en la misma transacción.
Con catch-all: destinatario desconocido admitido
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 250 2.1.5 OK
RESULT: Server accepts headers, body, and attachments.
Routing logic directs mail to the catch-all mailbox.La respuesta admite el destinatario. El servidor puede comprobar el mensaje durante DATA y rechazarlo antes de su aceptación final. Si lo acepta, debe gestionar contenido, colas, filtros y almacenamiento. Conviene rechazar tráfico no deseado durante SMTP cuando corresponda, o ponerlo en cuarentena sin generar avisos a remitentes falsificados.
Tres riesgos operativos que conviene revisar
Revisa tres áreas: la carga de sondeos de direcciones, los avisos de no entrega enviados a terceros inocentes y la autenticación al reenviar. Son riesgos que dependen de la implementación y los controles, no consecuencias inevitables del catch-all.
1. Sondeos de directorio (DHA)
Los atacantes pueden probar miles de nombres habituales: admin, invoice, hr, accounts, david, noreply, info, billing. Buscan averiguar qué direcciones existen y enviar mensajes a las que parecen válidas.
Sin catch-all, respuestas 550 pueden revelar direcciones inexistentes, pero no obligan al atacante a retirarse. Si todas las sondas reciben 250 OK, cuesta distinguir direcciones creadas e inventadas. Esa menor exposición del directorio puede ir acompañada de más carga de recepción y filtrado. Miles de mensajes a destinatarios inventados pueden dificultar encontrar el correo útil.
2. Backscatter y reputación
Hay backscatter cuando se acepta un mensaje y después se envía un aviso de no entrega a una identidad de sobre falsificada, perjudicando a un tercero. Este tráfico puede afectar a la reputación y aparecer en listas de bloqueo como ips.backscatterer.org.
Un ejemplo de configuración problemática:
- Un atacante envía malware a random@yourdomain.com con MAIL FROM falsificado como innocent@gmail.com.
- El catch-all admite el destinatario y el servidor acepta después el mensaje sin rechazarlo durante SMTP.
- Un análisis posterior detecta malware y marca un fallo interno.
- Si el servidor genera un aviso de no entrega (NDR) a innocent@gmail.com, lo recibe alguien que no envió el mensaje.
- El destinatario recibe un rebote no solicitado y el servicio receptor puede considerarlo tráfico abusivo.
Un volumen elevado puede perjudicar la reputación o contribuir a bloqueos, sin que ocurra siempre. Prefiere el rechazo durante SMTP o una cuarentena segura sin rebotes ni respuestas automáticas a identidades falsificadas.
3. Reenvío y autenticación SPF
Algunos administradores reenvían *@company.com a Gmail personal. El catch-all no rompe SPF por sí mismo; el reenvío introduce otro servidor y debe evaluarse con las identidades SMTP y los resultados del receptor.
Si el intermediario conserva el MAIL FROM original, por ejemplo bankofamerica.com, Gmail puede evaluar una IP no autorizada por el SPF de ese dominio. Con reenvío mediante SRS (Sender Rewriting Scheme) se reescribe el sobre; el SPF del dominio utilizado debe autorizar la IP del intermediario. Eso no alinea automáticamente SPF con el From original. DKIM válido y alineado puede permitir DMARC sin SRS ni ARC. ARC requiere una cadena validada y un sellador de confianza para el receptor; no garantiza aceptación ni evita todas las pérdidas. Revisa registros, avisos y clasificación del mensaje.
Alternativas al catch-all
Los alias explícitos y el direccionamiento con etiquetas pueden cubrir muchas necesidades sin admitir destinatarios arbitrarios. Comprueba su compatibilidad y comportamiento en el servicio. El catch-all también puede ser adecuado si tiene un propósito y controles claros.
| Característica | Catch-all | Alias explícitos | Direccionamiento con etiquetas |
|---|---|---|---|
| Sintaxis | *@domain.com | sales@domain.com | user+tag@domain.com |
| Destinatarios admitidos | Incluye desconocidos del dominio, sujeto a controles | Solo direcciones configuradas según la ruta | Etiquetas de destinatarios base válidos, si se admite la función |
| Riesgo de spam | Puede aumentar la carga | Menos direcciones admitidas; aún requiere filtros | Depende de compatibilidad, exposición y filtros |
| Coste en TrekMail | Verificar disponibilidad y condiciones del plan | Verificar costes y límites actuales | Verificar compatibilidad y condiciones actuales |
Los alias explícitos permiten definir qué direcciones son válidas y rechazar las demás según la configuración SMTP. Son una base práctica para muchas operaciones estables. Para diseñarlos y distinguir alias de buzones, consulta reenvío de alias de correo y alias de dominio frente a buzón.
Licencias: compara la necesidad real de buzones
El precio por usuario puede motivar la búsqueda de alternativas. Como ejemplo histórico, a $6/usuario/mes en Google Workspace, sales@, support@ y billing@ como buzones con licencia independiente sumarían $18/mes para tres direcciones. Pero alias y buzones compartidos pueden tener condiciones diferentes; no hace falta recurrir al catch-all por principio.
El modelo de almacenamiento compartido de TrekMail puede cambiar el cálculo. Verifica la capacidad agrupada de la cuenta, las cuotas individuales de los buzones, los permisos y los límites del plan actual; no presupongas buzones adicionales sin coste o ilimitados en cualquier modalidad.
| Ejemplo histórico de licencias por usuario | Referencia histórica de TrekMail | |
|---|---|---|
| 3 buzones funcionales | $18/mes (Google Workspace, ejemplo) | $3.50/mes en total (Starter, referencia histórica) |
| 50 buzones | $300/mes en el ejemplo | $3.50/mes en total como referencia histórica |
| Necesidad de catch-all | Depende del diseño; alias y recursos compartidos pueden servir | Depende de necesidades, funciones y límites actuales |
| Comportamiento SMTP | Puede rechazar destinatarios desconocidos | Verificar validación y rutas configuradas |
La referencia histórica de Starter a $3.50/mes menciona hasta 50 dominios y 100 buzones por dominio; verifica precios y límites vigentes. Configura sales@, support@, billing@, info@ y las direcciones realmente necesarias. Comprueba la validación de destinatarios y la ruta de entrega, además de mantener filtros y controles.
Un buzón de revisión para el catch-all
Durante una migración con directorio incompleto puede interesar recuperar correo legítimo a direcciones antiguas. Usa un destino separado y restringido. Llamarlo cuarentena no lo convierte en un entorno aislado seguro: siguen siendo necesarios filtros, permisos y manejo cuidadoso de adjuntos.
- Crea un buzón dedicado: catchall-quarantine@yourdomain.com, separado de la bandeja principal y con acceso limitado.
- Configura la ruta: envía solo los destinatarios desconocidos del dominio autorizado a ese buzón.
- Evita notificaciones y respuestas: revisa los filtros y avisos del cliente, desactiva reenvíos y respuestas automáticas del buzón y evita rebotes a identidades falsificadas, sin suprimir los avisos de no entrega legítimos que correspondan.
- Revisa semanalmente: identifica correo legítimo y crea un alias explícito después de verificar quién debe recibirlo.
- Define un criterio de cierre: 30 días sin correo legítimo puede ser una referencia de planificación; decide según ciclos de tráfico y necesidades reales.
Así puede funcionar como herramienta de diagnóstico limitada en el tiempo. Identifica direcciones antiguas activas, conviértelas en alias autorizados y revisa si el catch-all sigue siendo necesario. Un uso permanente exige justificación y supervisión propias.
Agencias: cobertura con direcciones explícitas
Al gestionar 100+ dominios, preparar alias estándar puede resultar laborioso. Comprueba si el panel y plan actuales de TrekMail permiten plantillas u operaciones masivas. Una lista como postmaster@, abuse@, accounts@, info@ debe adaptarse a cada cliente y a sus permisos; revisa los resultados de cualquier operación antes de ampliar su alcance.
RFC 2142 describe buzones de contacto en función de los servicios y responsabilidades aplicables. postmaster@ es obligatorio para los dominios atendidos por un servicio SMTP activo de entrega o retransmisión; abuse@ depende del servicio y la función pertinentes. Comprueba acceso, responsables y funcionamiento sin depender del catch-all.
Cuándo puede ser útil el catch-all
Estos son tres ejemplos de uso que conviene delimitar:
- Migración activa: trasladas un sistema antiguo y aún no tienes un directorio completo.
- Adquisición de dominio: necesitas revisar tráfico histórico desconocido antes de decidir qué direcciones conservar.
- Entornos de pruebas: usas direcciones inventadas en dominios de prueba sin crearlas individualmente.
En los tres casos, limita el alcance, usa un destino controlado y revisa cuándo desactivar la regla. No son los únicos usos legítimos: una configuración permanente bien administrada puede ser adecuada si sus riesgos y objetivos están claros.
Valora el catch-all por su utilidad y sus costes operativos
Recuperar una errata puede ser útil, pero hay tres áreas que supervisar: carga de spam, backscatter por avisos posteriores a identidades falsificadas y autenticación del reenvío. Evalúa cada una con datos de tu servicio, sin dar por inevitables bloqueos o pérdidas de correo.
Si el motivo es el coste, compara licencias, alias, recursos compartidos y almacenamiento agrupado. TrekMail puede permitir una estructura de buzones adecuada según el plan vigente. Sales@, support@, billing@ y 47 más son un ejemplo de organización, no una garantía actual de capacidad o precio único.
Consulta una posible prueba gratuita de 14 días y los requisitos de tarjeta actuales. Comprueba también disponibilidad y condiciones de Free/Nano, incluida la modalidad sin tarjeta ni prueba. Solo en el modelo Nano descrito necesitas SMTP externo propio para todos los envíos y respuestas; el SMTP gestionado de las modalidades de pago depende de los permisos vigentes y de la configuración del cliente compatible.
