Para verificar una dirección de correo catch-all, primero se comprueban la dirección y su ruta de correo. Después se compara la respuesta del servidor para el destinatario indicado con la respuesta para otro destinatario generado al azar. Si acepta ambos, se conoce el comportamiento del dominio, pero no se ha demostrado que exista ese buzón. El resultado debe tratarse como risky. Cuando importa saber quién controla la dirección, hace falta un correo de confirmación.
Un dominio catch-all puede aceptar mensajes dirigidos a cualquier nombre, incluso uno que nadie usa. Por eso no basta con marcar la dirección como «válida» o «inválida». La definición de dominio catch-all explica esa regla; aquí se describe cómo comprobarla y qué hacer con el resultado.
Paso 1: detectar los fallos claros antes de consultar la red
Se empieza por el formato: parte local, dominio y longitud total. No hace falta consultar DNS para detectar una dirección mal formada. Una parte local internacionalizada puede requerir la extensión SMTPUTF8 cuando se contacte con el servidor, tal como establece RFC 6531. Superar esta prueba solo indica que la estructura es correcta.
Después hay que comprobar si existe el dominio y por dónde recibiría correo. La inexistencia confirmada del dominio o un MX nulo explícito pueden terminar la verificación antes de SMTP. En cambio, la ausencia de un MX ordinario no basta: RFC 5321 permite una ruta implícita por la dirección A o AAAA del dominio. RFC 7505 define el MX nulo. La referencia sobre registros MX distingue los casos.
Una ruta utilizable indica a dónde podría enviarse correo. No demuestra que exista alex@example.com.
Paso 2: preguntar por el destinatario indicado
Una verificación completa puede abrir una sesión SMTP y presentar la dirección con RCPT TO. El servidor puede aceptarla, aplazar la respuesta, rechazarla o impedir el sondeo. Emvero se detiene antes de DATA, por lo que la prueba no envía mensajes. RFC 5321 separa la indicación del destinatario del contenido del correo.
Una respuesta positiva confirma la aceptación en ese momento. Todavía no se sabe si el servidor distingue entre destinatarios reales e inventados. Una respuesta temporal o un sondeo bloqueado dejan la pregunta abierta. Incluso una respuesta clasificada internamente como «buzón inexistente» se comunica, según la política actual de Emvero, como unknown con SMTP_RECIPIENT_REJECTED_AMBIGUOUS; no causa un reject automático.
Paso 3: tras la aceptación, usar un destinatario de control
Si el servidor aceptó la dirección solicitada, se presenta en la misma sesión otra dirección improbable y recién generada en el mismo dominio. Es mejor un valor aleatorio que un nombre como test, que podría existir. La documentación de Emvero sobre catch-all describe esta prueba.
| Dirección solicitada | Dirección de control | Qué se puede concluir |
|---|---|---|
| Aceptada | Aceptada | El servidor acepta nombres arbitrarios. El dominio funciona como catch-all; la existencia del buzón concreto sigue sin demostrarse. |
| Aceptada | Rechazada de forma específica | El servidor distingue destinatarios. La primera aceptación es una prueba más útil sobre el buzón, sin garantizar una entrega futura. |
| Aceptada | Respuesta temporal o ambigua | No se sabe aún si el dominio es catch-all. Esa respuesta no cuenta como un rechazo claro. |
| Rechazada o sin sondeo | No se envía | No hay una aceptación que aclarar mediante un control. La primera respuesta debe interpretarse por sí misma. |
El control sirve para conocer una regla del dominio. No enumera buzones ni demuestra quién controla uno. Si el estado catch-all ya se conoce por una observación anterior o por el proveedor, Emvero puede reutilizarlo sin repetir el control para cada dirección.
Paso 4: leer el resultado antes de actuar
Una verificación completa de un dominio catch-all conocido puede devolver:
{
"status": "risky",
"action": "allow_with_email_confirmation",
"checks": { "smtp": "accepted", "accept_all": "yes" },
"reason_codes": ["SMTP_RCPT_ACCEPTED", "ACCEPT_ALL_DOMAIN"]
}
SMTP_RCPT_ACCEPTED registra la respuesta al destinatario. ACCEPT_ALL_DOMAIN explica por qué no confirma que exista un buzón individual. Conviene leer juntos status, action, checks.accept_all y reason_codes. Un rechazo SMTP no equivale a un fallo definitivo del dominio: el resultado final puede seguir siendo unknown. Una dirección mal formada, un dominio inexistente o un MX nulo ofrecen una base distinta y anterior para descartar la dirección.
En un registro, se puede permitir el alta y pedir una confirmación por correo cuando importa el control del buzón. La guía para formularios de registro muestra cómo tratar risky y unknown sin convertirlos en fallos definitivos.
Al limpiar una lista, conviene mantener las direcciones catch-all separadas de los fallos confirmados y conservar la fecha de la observación. Las rutas y las reglas del servidor cambian. La guía de limpieza de listas explica cómo revisar ese grupo.
Antes de contactar con alguien, la procedencia, el permiso y las interacciones anteriores se evalúan por separado. La verificación técnica no acredita el consentimiento. Una confirmación demuestra control del buzón cuando alguien responde al mensaje, pero no garantiza la entrega futura ni la llegada a la bandeja de entrada.
Consultar un estado conocido o hacer una verificación completa
El comprobador gratuito de dominios catch-all muestra el estado que Emvero ya conoce. No abre una sesión SMTP y, si falta un dato fiable, responde unknown. Para obtener pruebas nuevas sobre el destinatario, se usa una verificación completa mediante la API de verificación de correo:
curl -sS https://api.emvero.tech/v1/verifications \
-H "Authorization: Bearer emv_your_credential" \
-H "Content-Type: application/json" \
-d '{"email":"alex@example.com","variant":"full"}'
Mientras se reúne la respuesta del servidor, la API puede devolver pending. Antes de aplicar una regla, hay que leer action y reason_codes en el resultado final. Si la acción es allow_with_email_confirmation, la duda pendiente se resuelve con un mensaje de confirmación real, no con otra prueba SMTP.