Tarde o temprano, todo remitente B2B se topa con el mismo enigma. La lista pasó por la verificación, las direcciones salieron bien y la campaña rebotó igualmente. Muy a menudo la causa es un dominio catch-all: un servidor de correo de empresa que dice que sí a cualquier dirección, así que la comprobación que debía proteger tu reputación como remitente no tenía nada real que contar.
Esta guía explica qué significa catch-all, por qué la verificación no puede ver más allá, cómo BounceIntel detecta y puntúa estas direcciones y qué reglas deciden a cuáles merece la pena enviar.
Qué significa catch-all (accept-all)
Un dominio catch-all, también llamado accept-all, es un dominio cuyo servidor de correo acepta mensajes para cualquier dirección de ese dominio. jane.doe@, j.doe@, sales-team@ y xq7k2@ reciben la misma bienvenida, exista o no un buzón con ese nombre.
Las empresas lo configuran por motivos que parecen razonables:
- No perder correo. Un cliente que escribe mal el nombre de un empleado llega igualmente a alguien, porque las direcciones desconocidas acaban en un buzón compartido.
- La rotación de personal. El correo dirigido a personas que ya se fueron sigue llegando a algún sitio en lugar de rebotar a los clientes.
- Las pasarelas de seguridad. Algunos servicios de filtrado situados delante de los buzones de una empresa aceptan todo primero y lo clasifican después.
- Una configuración antigua que nadie ha revisado en años.
Las configuraciones catch-all son habituales en dominios de empresa y raras en los grandes proveedores de consumo, y por eso el problema aparece sobre todo en listas B2B.
Por qué SMTP siempre dice «sí»
La verificación de email real se basa en una pregunta hecha por SMTP. El verificador se conecta al servidor de correo del dominio, indica la dirección con RCPT TO y lee la respuesta. Un servidor normal busca el buzón y lo acepta o lo rechaza como desconocido. Para la secuencia completa, consulta cómo funciona la verificación de email.
Un servidor catch-all se salta esa búsqueda o la deja para después. Responde 250, aceptado, a cada destinatario. Lo que le ocurra luego a un mensaje real depende de la configuración:
- Se entrega en un buzón compartido que alguien puede leer o no.
- Se acepta y después rebota, minutos u horas más tarde, como un mensaje de rebote aparte, mucho después de que terminara la conversación del verificador.
- Se descarta sin aviso.
El segundo caso es el peligroso. Un rebote que llega tarde cuenta igualmente en tu contra ante tu proveedor de email marketing, y sigue diciendo a los proveedores de correo que escribes a direcciones que no existen. Tu informe de verificación estaba limpio y tu reputación pagó de todos modos.
Cómo lo detectan los verificadores
Como el servidor dice que sí a la dirección real, el verificador le pregunta por una dirección que seguro que no existe. BounceIntel lo hace en la misma conexión SMTP que usó para la dirección enviada: manda un segundo RCPT TO con una parte local aleatoria de 15 caracteres en el mismo dominio. En ningún caso se envía un mensaje.
- Si la dirección aleatoria se rechaza, el servidor sí comprueba los buzones, y que aceptara tu dirección significa algo.
- Si la dirección aleatoria se acepta, el dominio es catch-all, y que aceptara tu dirección no dice nada sobre ese buzón.
Para unos pocos proveedores de correo cuyos servidores tienen un comportamiento propio conocido, la sonda se omite y se aplican reglas específicas del proveedor.
En la respuesta de la API, un catch-all detectado tiene este aspecto. Es un resultado real para un nombre inventado en nuestro propio dominio, que acepta correo para cualquier dirección:
{
"input": "[email protected]",
"is_reachable": "risky",
"smtp": {
"can_connect_smtp": true,
"is_deliverable": true,
"is_catch_all": true,
"is_disabled": false,
"has_full_inbox": false
},
"score": {
"reason_codes": ["catch_all", "catch_all_high_risk"],
"catch_all": {
"severity": "high",
"confidence": 55,
"factors": ["catch_all:corporate_domain", "website:present", "auth_records:present"]
}
},
"bounce_risk": { "action": "verify_manually" }
}
Fíjate en smtp.is_deliverable: true. El servidor sí aceptó la dirección, y esa es precisamente la respuesta que no se puede tomar al pie de la letra.
Por qué «válido» es mentira aquí
Muchas herramientas de verificación marcan una dirección catch-all aceptada como válida o entregable, porque técnicamente el servidor dijo que sí. Pero el servidor dice lo mismo de un empleado real y de un nombre que te has inventado hace treinta segundos. Una etiqueta que da la misma respuesta a los dos no es información. Es una suposición disfrazada de resultado.
El daño es previsible. Una lista pasa la verificación, la tasa de rebote sube de todos modos y la culpa recae en el verificador. Es aún peor con listas construidas a base de suposiciones, cuando alguien generó [email protected] para cada nombre de una web o compró un archivo con ese tipo de direcciones. En un dominio catch-all cada suposición «se verifica», así que la lista parece perfecta hasta el momento del envío.
BounceIntel nunca marca una dirección catch-all como segura. is_reachable es risky, score.safe_to_send es false y el código de motivo catch_all explica por qué, de modo que ninguna parte de tu código puede confundirla con un buzón confirmado.
Puntuar los catch-all y send_with_caution
Llamar arriesgadas a todas las direcciones catch-all es honesto, pero por sí solo no sirve de mucho: en B2B, una gran parte de una lista perfectamente buena puede estar en dominios catch-all. Por eso BounceIntel valora cada dirección según las pruebas que la rodean y lo resume en score.catch_all, con una severity (low, medium o high), un valor de confidence y los factors que lo justifican.
El punto de partida depende del dominio. Un dominio de empresa empieza con gravedad alta; un proveedor gratuito de consumo, con gravedad baja. Después, las pruebas la mueven:
| Prueba | Efecto | Factor |
|---|---|---|
| Tu cuenta ha visto esta dirección salir limpia al menos 3 veces en 180 días | La gravedad pasa a baja | tenant_history:safe_repeat |
| Al menos otras 5 direcciones con el mismo patrón de nombre verificadas en este dominio en tu cuenta en 180 días | La gravedad pasa a baja | pattern:…:verified_matches |
| Entre 2 y 4 direcciones así | Alta pasa a media | pattern:some_verified_matches |
| El dominio tiene al menos un año | Alta pasa a media | domain_age:established |
| El dominio no tiene sitio web | La gravedad pasa a alta | website:missing |
| Falta SPF o DMARC | La gravedad pasa a alta | auth_records:weak |
La gravedad se repite como código de motivo sobre el que puede decidir tu código: catch_all_low_confidence, catch_all_medium_confidence o catch_all_high_risk. La recomendación de bounce_risk.action sigue después el riesgo global de la dirección. Una dirección catch-all con buenas pruebas detrás suele volver como send_with_caution, una con pocas pruebas como verify_manually y una que además tiene otras señales malas, como una dirección genérica en un dominio sin sitio web, como do_not_send.
send_with_caution significa exactamente eso. La dirección probablemente está bien, y aun así conviene enviarle de forma que el daño sea limitado si no lo está.
Reglas B2B: conservar o suprimir
La verificación te da las pruebas. Qué haces con una dirección catch-all es una decisión de política, y conviene ponerla por escrito para que todo el equipo la aplique igual. Estas son las reglas que recomendamos.
Conserva la dirección, y envíale en un segmento propio, cuando:
- venga de un formulario que la persona rellenó por sí misma, idealmente con doble opt-in, o de una conversación real;
- el contacto haya abierto, hecho clic o respondido en los últimos meses;
- su gravedad sea
lowomedium, o siga un patrón de nombre ya verificado en esa empresa; - pertenezca a una persona con nombre en un dominio con sitio web y con SPF o DMARC configurados.
Suprímela cuando:
- sea una dirección genérica como
info@osales@en una lista fría, donde aparecen juntos los códigoscatch_allyrole_account; - se haya deducido, extraído por scraping o comprado, diga lo que diga cualquier verificador;
- su gravedad sea
highy no tengas historial de interacción con ella; - haya tenido un rebote duro, aunque sea una sola vez. Nunca reintentes un rebote duro.
Cuando sí envíes a direcciones catch-all:
- Mantenlas en un segmento separado de tus direcciones confirmadas, para que un problema quede contenido.
- Empieza con un lote pequeño y mira la tasa de rebote antes de enviar el resto.
- Detente y revisa si los rebotes suben, en lugar de enviar el segmento completo.
- Elimina de inmediato cada rebote duro, de todas las listas.
- Vuelve a verificar el segmento antes de la siguiente campaña, porque las pruebas de patrón en las que se basa la puntuación se acumulan con cada comprobación.
Comprueba tú mismo una dirección catch-all
En tu propio código, lee smtp.is_catch_all en la respuesta de POST /v1/check_email, o en cada fila de un trabajo masivo, y decide según score.catch_all.severity y bounce_risk.action. La documentación de la API describe cada campo y la verificación masiva muestra cómo pasar una lista entera por las mismas comprobaciones.
