CaptainVerify verificó más de 126 millones de direcciones de correo en 2025. Alrededor del 2,5 % del volumen corresponde a un dominio catch-all. Si se toman solo las direcciones alojadas en un dominio corporativo, sin contar los buzones de uso personal que representan casi el 75 % del total verificado, la proporción se acerca al 11 %, casi 1 de cada 9 direcciones profesionales. Esta medida se refiere a direcciones. Las tasas mucho más altas que circulan por ahí cuentan dominios, que es otra unidad: un mismo dominio en catch-all puede aportar un puñado de direcciones a su base como puede aportar centenares. Sobre un fichero B2B de 50 000 contactos, eso supone del orden de 5 500 líneas cuya validez sigue siendo indecidible antes del envío.
El dominio que aloja esas direcciones se detecta en segundos con un comando SMTP. Los 2 niveles se tratan por separado: la detección del dominio depende de una prueba técnica reproducible, la decisión de enviar depende de sus umbrales de rebote.
¿Qué es una dirección catch-all?
Un catch-all es una regla de enrutamiento fijada a nivel de dominio: el servidor de recepción acepta los mensajes dirigidos a cualquier buzón del dominio, esté declarado o no.
La regla vive en la configuración del dominio receptor, detrás de su registro MX. Ningún buzón lleva la etiqueta por sí mismo. La expresión «dirección catch-all» circula como atajo y designa toda dirección cuyo dominio aplica este modo de reserva.
Un ejemplo hace evidente la mecánica. El dominio ejemplo.com declara david@ejemplo.com y activa un catch-all. Un corresponsal escribe daivd@ejemplo.com, con 2 letras invertidas. En un dominio estándar, el servidor rechaza esa dirección en el momento del RCPT TO y devuelve un error permanente al remitente, uno de los códigos de respuesta SMTP que hay que saber leer. En ejemplo.com, el mensaje entra, aterriza en el buzón de reserva y la errata pasa desapercibida.
Catch-all, alias, redirección y subdireccionamiento: no confundirlos
Un alias declara una dirección adicional que apunta hacia un buzón existente. Una redirección toma una dirección declarada y reenvía su correo hacia otro destino. El subdireccionamiento añade un sufijo tras un signo más, del tipo david+prensa@ejemplo.com, que el servidor devuelve al buzón de base. Estos 3 mecanismos operan sobre direcciones conocidas por el servidor, que rechaza todo lo que se sale de su lista. El catch-all actúa después de esa lista, sobre las partes locales que ninguna regla declara.
¿Para qué sirve la dirección catch-all?
Un catch-all recupera el correo enviado a una dirección mal escrita y priva a un atacante de la respuesta que le diría qué direcciones existen en el dominio.
El primer uso es trivial. Las erratas abundan en los apellidos compuestos, los buzones de empleados que ya se fueron siguen recibiendo correo durante meses y el catch-all recoge ese correo.
El segundo uso es defensivo. Un servidor que responde 550 sobre las direcciones desconocidas ofrece un oráculo gratuito: el atacante envía una lista de nombres y se queda con los que el servidor acepta. El dominio en catch-all responde 250 a todo el mundo y deja de clasificar nada para él.
El reverso llega al buzón de reserva. Un dominio que lo acepta todo atrae las campañas de diccionario, esos envíos masivos que prueban contacto@, admin@, sat@, rrhh@ y varios centenares de nombres hasta que algo se queda dentro. La clasificación recae entonces sobre el equipo que vacía el buzón, con el trabajo de limpieza de lista que eso supone del lado del remitente.
Cómo detectar un dominio catch-all
Un dominio catch-all se detecta enviando al servidor una dirección tomada al azar: si el servidor acepta una dirección improbable, acepta todo el resto.
La prueba SMTP paso a paso: MX, EHLO, MAIL FROM, RCPT TO
- Resolver los registros MX del dominio y quedarse con aquel cuyo valor de preferencia sea el más bajo, es decir el MX primario. A falta de MX, el correo recae sobre el registro A del dominio.
- Abrir una conexión en el puerto 25 hacia ese servidor y saludar con
EHLOseguido de un nombre de host que resuelva en DNS. - Anunciar
MAIL FROMcon un sobre vacío o con una dirección de prueba realmente accesible. - Enviar
RCPT TOsobre la dirección a verificar, y anotar después el código de retorno junto con el texto que lo acompaña. - Enviar
RCPT TOsobre una dirección aleatoria del mismo dominio, del tipo k7v29xq4m@ejemplo.com. - Cerrar la sesión con
QUIT, sin pasar nunca al comando DATA.
La señal se lee en la dirección aleatoria, y la primera aceptación sirve solo para comprobar que la sesión se comporta con normalidad. Prevea un RSET entre los 2 comandos RCPT TO, porque un servidor corta a menudo la sesión tras un destinatario erróneo. Cortar antes de DATA evita entregar un mensaje y deja en los registros remotos únicamente la huella de una apertura de sesión. La IP que sondea debe disponer de un registro PTR válido, de lo contrario un rechazo por política se lee erróneamente como una dirección inválida.
250 OK frente a 550: leer la respuesta del servidor
La RFC 5321 de octubre de 2008 fija la regla en su sección 3.3: el servidor responde 550 al RCPT TO cuando el destinatario no es entregable, con un mensaje del tipo «no such user». La RFC 3463 de enero de 2003 precisa el código extendido asociado en su sección 3.2: 5.1.1 señala una dirección de destino inválida y un fallo definitivo. Un 250 devuelto sobre la dirección aleatoria establece que el dominio acepta todo en el RCPT TO. La reserva cuenta: algunas pasarelas antispam colocadas en frontal aceptan también a cualquier destinatario en esta fase sin aplicar ningún catch-all. El rechazo diferido descrito más abajo produce la misma respuesta. Estos códigos afectan al sobre, mientras que la forma de la dirección depende de la sintaxis de una dirección de correo definida por las RFC.
Lo que falsea la prueba: MX compartido, greylisting, tarpitting y rechazo diferido
El MX compartido encabeza las señales falsas. Centenares de miles de dominios apuntan hacia los mismos servidores de mensajería en los grandes proveedores de alojamiento. La política de destinatarios se ajusta dominio por dominio detrás de ese MX común, así que el nombre del servidor no dice nada del modo de reserva.
El greylisting produce otro ruido. El servidor responde con un error temporal en 4xx en el primer contacto y espera un nuevo intento para pronunciarse. CaptainVerify espera hasta 30 minutos y relanza la verificación antes de concluir. Las direcciones que siguen mudas tras esa segunda pasada quedan en estado desconocido y se acreditan de nuevo. El tarpitting pertenece a la misma familia: el servidor ralentiza deliberadamente sus respuestas para desalentar las sondas.
El rechazo diferido complica todavía más la lectura. El servidor acepta al destinatario en el RCPT TO, y genera después un rebote una vez tragado el mensaje. La prueba ve un 250 limpio mientras que el envío real producirá un error permanente unos minutos más tarde.
¿Qué significa el estado accept_all en un informe de verificación?
El estado accept_all, llamado ok4all en los informes de CaptainVerify, indica que el dominio acepta todas las direcciones y que la verificación se detiene por tanto a nivel de dominio.
| Estado | Lo que dice el servidor | Acción |
|---|---|---|
| Válido | El servidor remoto declara que el destinatario existe. | Enviar sin reservas. |
| Inválido | Respuesta 550 o código extendido 5.1.1 en el RCPT TO. Este rechazo definitivo produce un hard bounce, a distinguir del soft bounce que señala un incidente pasajero. El 550 cubre también los rechazos por política, y la lectura del texto que lo acompaña lo resuelve. |
Retirar de la lista antes del envío. |
| ok4all (accept_all) | El dominio acepta todas las direcciones, la validez del buzón queda abierta. | Aislar en un segmento aparte y enviar por lotes. |
| De riesgo | Dirección de rol, desechable, protegida o trampa de spam identificada. | Excluir de las campañas masivas. |
| Desconocido | Greylisting o servidor mudo dentro del plazo previsto. | Reprogramar la verificación más tarde. |
La documentación de CaptainVerify clasifica ok4all en la familia de las direcciones de riesgo y anuncia el efecto sin rodeos: la tasa de rebote sube y la tasa de apertura baja. El informe dice por tanto 2 cosas en una línea. El dominio queda calificado, la persona que hay detrás de la dirección queda por confirmar con el envío.
¿Se puede verificar una dirección en un dominio catch-all?
El protocolo no resuelve la cuestión, porque el servidor devuelve la misma respuesta a todas las direcciones del dominio. Lo que sigue siendo posible es estimar una probabilidad y ordenar el segmento en consecuencia.
Mire primero lo que se esconde detrás del registro MX del dominio. Cuando apunta hacia una pasarela de seguridad, del tipo Proofpoint, Mimecast, Barracuda o Microsoft Defender para Office 365, es la pasarela la que responde por cuenta del dominio, antes incluso de consultar el buzón real. El estado accept_all refleja entonces una arquitectura de filtrado más que una regla de reserva decidida por la empresa. El caso es frecuente en las grandes cuentas.
Viene después la forma de la dirección. En un dominio cuyos buzones siguen una convención visible, nombre.apellido por ejemplo, una dirección que respeta esa convención tiene una probabilidad de validez mucho más alta que una cadena arbitraria. Compare sus líneas entre ellas: las que se salen del molde van a un segmento de prueba, las demás pasan como prioritarias.
Un verificador añade por último sus propias señales: la antigüedad del dominio, la reputación del proveedor de mensajería, el tamaño de la organización y el historial observado en envíos anteriores. El resultado da un índice de confianza que sirve para ordenar un segmento antes del envío.
Crear o desactivar un catch-all según el proveedor
El cambio se ajusta en la consola de administración del dominio: modo del dominio aceptado en Microsoft 365, regla de enrutamiento en Google Workspace, dirección por defecto en cPanel.
Google Workspace
Google Workspace no ofrece ninguna función catch-all nativa. Google publica en cambio una página de ayuda dedicada al buzón de recogida y nombra el tipo de cuenta afectada Unrecognized o Catch-all. La configuración pasa por una regla de enrutamiento, en Apps y luego Gmail y luego Routing, con la acción Change envelope recipient aplicada a las cuentas inactivas y no reconocidas. El correo dirigido a un buzón desconocido sale entonces hacia una dirección de recogida designada. Para volver atrás, elimine esa regla de enrutamiento: el dominio vuelve de inmediato a rechazar a los destinatarios que no conoce.
Microsoft 365
El comportamiento depende del modo del dominio aceptado, en Mail flow y luego Accepted domains. En modo Authoritative, el dominio rechaza a los destinatarios desconocidos y activa el Directory-Based Edge Blocking, que corta el mensaje en la frontera del servicio. El modo Internal relay reenvía el correo de los destinatarios desconocidos hacia otro servidor y produce de hecho un comportamiento de reserva.
cPanel
La función se llama Default Address. La opción por defecto devuelve un error al remitente durante la sesión SMTP, lo contrario exacto del catch-all. Las otras 2 posibilidades enrutan el correo de las direcciones desconocidas hacia un buzón existente o lo descartan en silencio. La documentación de cPanel etiqueta ella misma esta última opción como Not Recommended, por una razón de fondo: el remitente nunca llega a saber que su mensaje ha desaparecido.
Con qué sustituir un catch-all
La salida pasa por direcciones declaradas en lugar de una regla de reserva. Cree alias sobre las erratas más frecuentes de sus nombres de dominio y mantenga un buzón genérico de contacto que alguien vacíe de verdad. El subdireccionamiento toma el relevo para rastrear sus formularios sin multiplicar los buzones. El dominio recupera una lista de destinatarios limpia. Sus corresponsales reciben un error inmediato cuando se equivocan.
Catch-all con o sin bounce
Detrás de esta pregunta se esconden 2 configuraciones distintas. El catch-all acepta al destinatario desconocido en el RCPT TO y entrega el mensaje en un buzón de reserva, sin rebote de ninguna clase. El rechazo diferido acepta también en el RCPT TO, y fabrica luego un informe de no entrega después de haber tragado el mensaje.
Este segundo modo tiene un coste para todo el mundo. Cuando el sobre de origen está falsificado, que es la norma en spam, el informe de no entrega sale hacia un tercero inocente cuya dirección ha servido de señuelo. El fenómeno tiene nombre, backscatter. Alimenta las listas de bloqueo. Comprenderlo ayuda también a clasificar sus propios retornos, entre hard bounce y soft bounce.
¿Debería incluir las direcciones catch-all en sus campañas?
Enviar a direcciones catch-all hace subir la tasa de rebote y bajar la tasa de apertura, 2 curvas que las plataformas de envío vigilan para decidir la continuación. Por ahí es por donde la reputación de remitente se degrada, mensaje tras mensaje.
El riesgo real: umbral de rebote, tasa de quejas, reputación de remitente y trampas de spam
Los umbrales de rebote vienen de las plataformas de envío. Amazon SES pone su contador bajo revisión por encima del 5 % de rebote y puede suspender los envíos al 10 %. La documentación de Microsoft para Dynamics 365 Customer Insights, actualizada en agosto de 2026, distingue 2 niveles: una tasa de rebote aceptable no supera el 2 % en la mayoría de los casos. El producto en sí tolera hasta el 8 % antes de reaccionar. El 2 % corresponde por tanto a la buena práctica, el 8 % al umbral realmente aplicado. Retomemos el fichero de 50 000 contactos y sus unas 5 500 líneas en catch-all. Si la mitad rebota, el contador supera el 5 % antes incluso de haber contado el resto de la base, por encima de la barra que dispara la revisión de cuenta. Los umbrales de rebote aplicados por las plataformas de envío varían después de un actor a otro.
Los umbrales de quejas vienen de los servicios de correo y se cuentan aparte. Las reglas de Google para los remitentes, aplicables desde el 1 de febrero de 2024, piden una tasa de quejas por debajo del 0,10 % y fijan en el 0,30 % un límite que nunca hay que alcanzar, para todo remitente de más de 5 000 mensajes al día hacia Gmail. El Sender Hub de Yahoo pide mantenerse por debajo del 0,3 %. Estos 2 actores publican umbrales de quejas. Ninguno publica un umbral de rebote.
Queda el asunto de las trampas de spam. Spamhaus documentó el ciclo en febrero de 2022: una dirección abandonada rebota en error permanente durante 12 meses o más a menudo, y después el dominio la reactiva como trampa. Una base dejada sin limpiar desde hace 2 años contiene por tanto, estadísticamente, direcciones que han cambiado de naturaleza entretanto.
Reducir la incertidumbre antes del envío
La verificación previa de la lista hace la primera criba. Saca las inválidas y aísla las ok4all en su propio segmento. Sobre la base que queda, el rebote vuelve a ser previsible. Mire después el origen de la captación: una lista construida en opt-in simple o en doble opt-in produce claramente menos rebotes que un fichero comprado. Mire por último la antigüedad, ya que el ciclo descrito por Spamhaus corre sobre todas las direcciones dormidas. Este panorama de las herramientas de verificación de correos detalla los enfoques disponibles.
Validar por la interacción tras el primer envío
El segmento ok4all se trata como una prueba. Envíe primero sobre el 5 a 10 % del segmento. Mida el rebote y la apertura, y compare esos 2 valores con los del resto de la campaña. Una diferencia pequeña autoriza a subir el porcentaje en el envío siguiente. Una diferencia clara indica un segmento que dejar de lado o que retrabajar.
Tras 2 envíos sin apertura ni clic, una dirección en catch-all ha probado su inutilidad y sale de la lista. Antes de su próxima campaña, aísle las líneas ok4all de una muestra de su base y compare su tasa de rebote con la del resto: el veredicto llega en una hora y vale más que cualquier estimación.
Preguntas frecuentes
¿Es detectable un dominio catch-all?
Sí, en unos segundos. Basta un comando RCPT TO sobre una dirección aleatoria del dominio: una respuesta 250 sobre una dirección improbable revela el modo de reserva. La validez de cada dirección individual, en cambio, sigue siendo indecidible con esta prueba.
¿Qué parte de una base B2B está afectada?
Sobre más de 126 millones de direcciones verificadas por CaptainVerify en 2025, alrededor del 2,5 % salieron como catch-all. El perímetro de los dominios corporativos por sí solos eleva esa proporción a casi el 11 %. Una base B2B de 100 000 contactos contiene por tanto del orden de 11 000 líneas de este tipo, que hay que aislar antes del envío.
¿Protege el catch-all del spam?
Aumenta el spam recibido, ya que cualquier dirección inventada sobre el dominio encuentra un buzón. Su beneficio está en otra parte: el servidor deja de responder 550 sobre las direcciones desconocidas y priva al atacante del oráculo que le permitiría enumerar las direcciones válidas.
¿Hay que eliminar las direcciones catch-all de la lista?
La eliminación pura y dura se justifica cuando su plataforma de envío aplica un umbral de rebote bajo, como el 5 % que dispara una revisión de cuenta en Amazon SES. Sobre una IP dedicada que usted controla, un segmento separado y un envío por lotes siguen siendo una opción razonable.
¿Qué hacer con un estado desconocido en un informe?
Señala un servidor que se ha quedado mudo pese a la segunda pasada automática efectuada en los 30 minutos. CaptainVerify vuelve a acreditar esas verificaciones. Una nueva pasada más tarde resuelve la gran mayoría de los casos.
