Resultados de verificación de correo: valid, invalid, risky y unknown

Todos los verificadores de correo electrónico clasifican las direcciones en aproximadamente cuatro resultados: valid (válido: el servidor de correo confirmó el buzón), invalid (inválido: rechazado, sin servidor de correo o con sintaxis incorrecta), risky (de riesgo: alcanzable pero imposible de confirmar, normalmente catch-all) y unknown (desconocido: sin respuesta útil). Las palabras cambian según el proveedor. Las decisiones que hay detrás no, y eso es lo que mapea esta guía.

Si alguna vez has pasado una lista de una herramienta a otra y has visto que las columnas no coinciden, este es el motivo. El 1 de octubre de 2026 leímos la documentación de resultados de ocho servicios de verificación y comparamos sus etiquetas una por una.

Los cuatro resultados que hay debajo de cada etiqueta

Cada estado es, en realidad, la respuesta a una sola pregunta: ¿qué dijo el servidor de correo del destinatario, si es que dijo algo? La verificación funciona abriendo una conversación SMTP con el servidor y preguntando por el buzón en el paso RCPT TO, sin enviar ningún mensaje. Explicamos el mecanismo en cómo comprobar un correo sin enviarlo.

Resultado	Qué hizo el servidor	Causa habitual
Valid	Aceptó la dirección y rechazó una dirección inventada del mismo dominio	Un buzón real que funciona
Invalid	Rechazó la dirección, o no había servidor al que preguntar	Error tipográfico, buzón eliminado, dominio muerto, sintaxis incorrecta
Risky	Aceptó la dirección, pero también aceptó una inventada	Dominio catch-all, buzón lleno, proveedor desechable (según el proveedor)
Unknown	No dio ninguna respuesta útil	Tiempo de espera agotado, greylisting, conexión rechazada, sistema antispam

La distinción clave que se pasa por alto es la de las dos últimas. Risky significa que el verificador obtuvo una respuesta y esa respuesta no significaba nada. Unknown significa que no obtuvo ninguna respuesta. Lo primero es una propiedad del dominio y no cambiará si vuelves a comprobarlo mañana. Lo segundo es un intento fallido y a menudo sí cambiará.

Cómo llaman ocho proveedores a los mismos resultados

Los mismos cuatro resultados aparecen con al menos cinco vocabularios distintos. Esta tabla mapea las etiquetas propias de cada proveedor, tomadas de su documentación de API (fuentes enlazadas debajo de la tabla).

Proveedor	Valid	Invalid	Catch-all	Unknown	Otras etiquetas de primer nivel
ZeroBounce	valid	invalid	catch-all	unknown	spamtrap, abuse, do_not_mail
NeverBounce	valid	invalid	catchall	unknown	disposable
Kickbox	deliverable	undeliverable	risky (con el indicador accept_all)	unknown	ninguna
Bouncer	deliverable	undeliverable	risky (motivo low_deliverability)	unknown	ninguna
Hunter	valid	invalid	accept_all	unknown	webmail, disposable
Clearout	valid	invalid	catch_all	unknown	indicador safe_to_send: yes / risky / no / unknown
DeBounce	5 Valid	6 Invalid	4 Accept-All	7 Unknown	1 Syntax, 2 Spam Trap, 3 Disposable, 8 Role
EmailListVerify	ok	email_disabled, dead_server, invalid_mx, invalid_syntax	ok_for_all	unknown	antispam_system, smtp_protocol, disposable, spamtrap

Fuentes: códigos de estado de ZeroBounce, comprobación individual de NeverBounce, README del SDK de Ruby de Kickbox, terminología de Bouncer, referencia de la API de Hunter, descripción general de Clearout, códigos de resultado de DeBounce y la especificación OpenAPI publicada por EmailListVerify en api.emaillistverify.com/api-doc.

Dónde discrepan de verdad los proveedores

La mayoría de las etiquetas se traducen una a una, pero tres categorías caen en grupos distintos según la herramienta. Si comparas los porcentajes resumidos de dos verificadores sin saber esto, sacarás la conclusión equivocada.

Direcciones desechables

Una dirección desechable, como una de Mailinator, suele tener un buzón que funciona. Nadie la va a leer.

• NeverBounce, Hunter, DeBounce y EmailListVerify le dan su propio estado de primer nivel.
• ZeroBounce la clasifica en do_not_mail con el subestado disposable.
• Bouncer la clasifica como risky, con el motivo low_quality.
• Kickbox la devuelve con un indicador disposable junto al resultado principal.

Así que una lista limpiada en Bouncer mostrará una proporción de risky mayor que la misma lista en NeverBounce, sin ninguna diferencia en los datos de fondo. Puedes comprobar cualquier dominio tú mismo con el verificador de correos desechables.

Direcciones de rol

info@, sales@ y support@ son buzones reales, así que la mayoría de las herramientas devuelven el veredicto del buzón y añaden un indicador de rol. Dos no lo hacen: DeBounce asigna a las cuentas de rol su propio código (8, que etiqueta como "Maybe, Not recommended") y ZeroBounce las pasa a do_not_mail con el subestado role_based. Si debes enviarles correos es otra cuestión, que tratamos en ¿deberías enviar a info@ y sales@?.

Catch-all marcado como valid

Este es el que hay que vigilar. El estado valid de ZeroBounce tiene un subestado llamado accept_all, que su documentación describe como direcciones que "pertenecen a dominios de la lista accept_all de ZeroBounce". Eso es distinto de su estado de primer nivel catch-all, que describe como "imposible de validar sin enviar un correo real y esperar un rebote". Si filtras solo por el estado de primer nivel, algunas direcciones accept-all viajan junto con las válidas. Lee la columna de subestado antes de importar.

Hunter tiene una versión más discreta del mismo problema. Su estado webmail abarca direcciones de proveedores como Gmail y Outlook, y su documentación dice que para las direcciones webmail y desechables "asignamos una puntuación arbitraria de 50". webmail te dice quién aloja el buzón, no si existe.

Qué hacer con cada resultado

Envía a los valid, borra los invalid, retén los risky y vuelve a comprobar los unknown. Esa es toda la política, con algunos matices.

Resultado	Acción	Por qué
Valid	Enviar	El servidor confirmó el buzón
Invalid	Borrar y suprimir para que nunca se vuelva a importar	Producirá un rebote duro
Disposable (desechable)	Borrar de las listas de marketing	Ningún humano lo va a leer
Spam trap (trampa de spam, si se marca)	Borrar	Caer en una daña la reputación del remitente mucho más que un rebote
Risky / catch-all	Enviar por separado, en lotes pequeños, solo si la dirección viene de una fuente fiable	No se puede confirmar, pero no es necesariamente mala
Unknown	Volver a verificar después de 24 a 48 horas	A menudo es un fallo temporal, como el greylisting
Role (rol)	Decisión tuya, según el caso de uso	Buzón real, mayor riesgo de quejas

Dos notas sobre esa tabla.

Valid tiene fecha de caducidad. La documentación de Clearout dice que su garantía de "safe to send" solo se aplica si envías "en las 24 horas siguientes al momento de la verificación", y ZeroBounce describe las direcciones válidas como direcciones con "una tasa de rebote muy baja, inferior al 2 %". Ambas son afirmaciones de los propios proveedores, no auditadas de forma independiente, pero coinciden en lo útil: un resultado valid describe el buzón el día en que lo comprobaste. Consulta cada cuánto volver a verificar tu lista.

Catch-all necesita su propia política. Suele ser el grupo no válido más grande de una lista B2B, y borrarlo sin más significa tirar a personas reales. Escribimos un marco de decisión para enviar correos a direcciones catch-all.

Unknown es un reintento, no un veredicto

Unknown significa que la comprobación no llegó a completarse, así que lo correcto es volver a ejecutarla, no decidir. Los subestados que publican los proveedores dejan claras las causas. ZeroBounce enumera greylisted, timeout_exceeded, mail_server_did_not_respond, failed_smtp_connection y antispam_system. Bouncer enumera timeout, unavailable_smtp, dns_error y unsupported. Kickbox enumera no_connect, timeout y unavailable_smtp.

La mayoría son temporales. Un servidor con greylisting rechaza el primer intento de un remitente desconocido con un código temporal 4xx y acepta uno posterior. Un servidor ocupado agota el tiempo de espera una vez y responde la siguiente.

Hay una causa de unknown que es culpa del verificador y no del destinatario: que la propia red del verificador no pueda llegar al puerto 25. Lo medimos en nuestra propia infraestructura en proveedores de nube que bloquean el puerto 25. Un verificador en esa situación debería devolver unknown o risky para todo lo que no pudo comprobar. Un verificador que devuelve valid en su lugar comete el fallo descrito en cómo saber si tu verificador de correo te está mintiendo.

Cómo se corresponden los tres estados de SimpleVerifier

Devolvemos tres estados en lugar de cuatro, y conviene dejar claro dónde va cada cosa:

• valid: el servidor de correo del destinatario confirmó el buzón.
• invalid: el servidor rechazó el buzón, la sintaxis es incorrecta, el dominio no tiene servidor de correo o el dominio está en nuestra lista de 8740 proveedores desechables.
• risky: el dominio funciona, pero no se pudo confirmar el buzón. Eso incluye los dominios catch-all y los servidores que no respondieron, así que tanto "risky" como "unknown" de la tabla de proveedores anterior acaban aquí.

Las direcciones de rol se marcan junto al estado, sin sustituirlo. Todo lo que no pudimos confirmar se devuelve como risky, nunca como valid. Los fallos transitorios se reintentan en lugar de guardarse en caché como veredicto.

Conclusión práctica

Cuando abras un archivo de resultados, haz tres cosas antes de importar nada:

1. Traduce las etiquetas a valid / invalid / risky / unknown con la tabla de arriba, para no comparar las categorías de dos proveedores como si coincidieran.
2. Lee la columna de subestado o motivo, no solo el estado principal. Ahí se esconden tanto los catch-all dentro de valid como los desechables dentro de risky.
3. Vuelve a ejecutar los unknown un día después antes de decidir nada sobre ellos.

Si quieres ver cómo se resuelve una sola dirección antes de procesar un archivo entero, el verificador de correos individual gratuito muestra el estado y el motivo.