¿Qué es un dominio catch-all y por qué los verificadores no pueden comprobarlo?

Si alguna vez has pasado una lista B2B por un verificador, habrás visto resultados que no son ni válidos ni inválidos. Aparecen como catch-all, accept-all o risky (riesgoso), y es el resultado peor entendido de toda la verificación de correo electrónico.

No es que el verificador sea perezoso. Es que está siendo preciso sobre algo que realmente no puede determinar.

Cómo funciona normalmente la verificación

Para comprobar un buzón sin enviar nada, el verificador abre una conversación SMTP con el servidor de correo del destinatario y le pregunta si aceptaría correo para esa dirección:

> MAIL FROM: <verify@example.com>
> RCPT TO: <someone@company.com>
< 250 OK                    ← el buzón existe

Si el buzón no existe, un servidor bien configurado lo rechaza:

< 550 5.1.1 User unknown    ← no existe ese buzón

Esa diferencia, 250 frente a 550, es todo el mecanismo. Nunca se envía ningún mensaje: la conversación se abandona antes de transmitir datos.

Qué hace distinto un dominio catch-all

Un dominio catch-all (literalmente, "que acepta todo") está configurado para aceptar correo para cualquier dirección de ese dominio, se haya creado el buzón o no. Así:

> RCPT TO: <ceo@company.com>              < 250 OK
> RCPT TO: <asdkjh2981@company.com>       < 250 OK

Las dos se aceptan. Es evidente que la segunda dirección no existe, y aun así el servidor dijo que sí.

Por eso la aceptación de un dominio catch-all no te dice nada. La forma correcta de detectarlo es probar primero una dirección deliberadamente absurda: si se acepta una cadena aleatoria, el dominio lo acepta todo, y no se puede confiar en el resultado de ninguna dirección de ese dominio.

Por qué las empresas lo configuran así

Normalmente es deliberado y razonable:

• Prefieren recibir un error tipográfico antes que perderlo. El correo enviado a jon@ en lugar de john@ llega igual.
• Las pequeñas empresas en hosting compartido suelen tenerlo activado por defecto.
• Los departamentos cambian. En lugar de mantener alias a medida que entra y sale personal, se acepta todo y se clasifica después.

Nada de eso es una mala configuración. Simplemente hace imposible la verificación externa.

Qué debería decirte un verificador

Tres estados, y el del medio cumple una función real:

Resultado	Significado
valid (válido)	Un servidor de correo confirmó este buzón concreto
invalid (inválido)	Rechazado, sin servidor de correo, sintaxis incorrecta o desechable
risky / catch-all (riesgoso)	El dominio lo acepta todo, así que no se puede confirmar

Una herramienta que devuelve valid en un dominio catch-all te está hablando de la configuración del dominio y dejándote creer que habla del buzón. Ese es el fallo que de verdad importa, porque parece una buena noticia justo hasta que llegan los rebotes.

Qué hacer realmente con las direcciones catch-all

No te limites a borrarlas: en las listas B2B suelen ser una parte importante del archivo, y muchas son perfectamente reales.

Júzgalas según de dónde vienen.

• Una dirección publicada en el propio sitio web de la empresa probablemente es real. Alguien la puso ahí para que la contactaran.
• Una dirección deducida a partir de un patrón de nombres, como nombre.apellido@, es lanzar una moneda al aire. Sigue la convención, pero nada confirmó el buzón.
• Una dirección de una lista extraída por scraping o comprada sin procedencia conocida merece la menor confianza.

Envíales por separado. Mantén las direcciones confirmadas como válidas en tus envíos principales. Envía a las direcciones catch-all en un lote más pequeño y separado, para que, si la tasa de rebote es alta, el daño quede contenido en lugar de arrastrar toda tu reputación como remitente.

Usa otras señales. Una dirección catch-all asociada a una persona con nombre, con un perfil de LinkedIn que coincide y en una empresa que publica el mismo patrón en otros sitios es una apuesta mucho mejor que una simple suposición.

En resumen

Un resultado catch-all no es un fallo del verificador. Es un verificador que se niega a adivinar.

Una herramienta que nunca devuelve catch-all no es más precisa que una que sí lo hace: simplemente está menos dispuesta a decirte cuándo no sabe algo, y de los dos comportamientos ese es el que más caro sale.