--- title: "Cómo interpretar los resultados de verificación de email - Emvero" description: "Lea status, action, checks, reason_codes, confidence y freshness. Dos ejemplos completos ayudan a decidir cuándo admitir, confirmar, revisar o rechazar una dirección." url: https://emvero.io/es/blog/reading-a-verification-result/ language: es updated: 2026-10-10 --- Blog # Cómo interpretar los resultados de verificación de email La respuesta separa conclusión, recomendación, evidencia y antigüedad. Hay que leer esos campos en orden antes de aceptar o rechazar una dirección. Publicado 2026-09-07 Para interpretar un resultado de verificación de email, compruebe primero si ha terminado. Consulte de nuevo la misma comprobación si devuelve `pending`. En un resultado completo, lea `status` y `action`; después, `reason_codes` y `checks` explican la decisión. `confidence` resume la evidencia y `freshness` indica cuándo se obtuvo. Conserve esos campos juntos. Una dirección con evidencia insuficiente necesita una respuesta distinta de otra cuya entrada o dominio aportan un motivo inequívoco para rechazarla. ## Leer la conclusión y la acción recomendada Emvero tiene cuatro estados finales. El estado separado `pending` indica que la comprobación está en cola o en curso. | `status` | Qué demuestra el resultado | Siguiente paso | | --- | --- | --- | | `deliverable` | El destinatario fue aceptado y ninguna señal de riesgo superior cambió la conclusión. | Seguir `action`, normalmente `allow`; la entrega y el acceso al buzón siguen sin demostrarse. | | `risky` | Una señal, como correo desechable o comportamiento catch-all, cambia cómo tratar la dirección. | Leer la causa y la acción: puede corresponder `allow` o `allow_with_email_confirmation`. | | `undeliverable` | Hay un motivo determinante de rechazo, como entrada incorrecta, `DNS_NXDOMAIN` o MX nulo. | Seguir `reject` y solicitar una dirección corregida o diferente cuando proceda. | | `unknown` | La evidencia no resuelve la dirección. | Valorar confirmación, verificación posterior o revisión por separado según la causa. | | `pending` | La verificación no ha terminado. | Recuperar la misma comprobación después de `retry_after_ms` antes de aplicar una regla para resultados finales. | La [referencia de veredictos](https://docs.emvero.io/answers/verdicts/) describe los campos. El estado resume la evidencia técnica; la acción recomienda un flujo de trabajo. Cumplen funciones distintas. Una dirección desechable puede ser `risky` con `allow`, mientras que un comportamiento catch-all establecido puede producir `risky` con `allow_with_email_confirmation`. Una observación SMTP negativa también requiere cuidado. Emvero devuelve actualmente la evidencia de buzón no encontrado durante el sondeo como `unknown` con `SMTP_RECIPIENT_REJECTED_AMBIGUOUS`. La acción es `allow_with_email_confirmation`. Ese sondeo no basta para rechazar como lo haría un fallo determinante de sintaxis o dominio. ## Encontrar la causa en `reason_codes` y `checks` `reason_codes` contiene identificadores que una integración puede interpretar para las observaciones y limitaciones. `SMTP_RCPT_ACCEPTED` se refiere a la aceptación del destinatario; `DISPOSABLE_DOMAIN`, a un atributo del dominio; `DNS_NXDOMAIN`, a un dominio inexistente; y `SMTP_GREYLISTED`, a un aplazamiento SMTP temporal. Compruebe qué parte del proceso describe el código antes de convertirlo en una regla sobre la dirección. Una restricción de la política del destino describe lo que el servidor remoto permitió averiguar al sondeo. Un fallo del servicio describe un problema del verificador. Ninguno demuestra que el buzón sea incorrecto. La [referencia de códigos de motivo](https://docs.emvero.io/answers/reason-codes/) contiene el vocabulario completo. Los códigos son identificadores estables, pero pueden añadirse otros. Conserve los valores desconocidos y aplique una regla de respaldo, en vez de rechazarlos solo por su nombre. Los campos de `checks` muestran hasta dónde llegó la comprobación: - `syntax` es `valid` o `invalid`. `domain` y `mail_routing` también pueden ser `unknown`. - `smtp` es `accepted`, `rejected`, `skipped`, `unknown` o `pending`. Una etapa omitida no se ejecutó. Un valor `smtp: rejected` puede coexistir con `status: unknown`. - `accept_all` es `yes`, `no` o `unknown`. - `disposable`, `role_account`, `public_provider` y `smtp_utf8_required` describen atributos de la dirección o del dominio. Por ejemplo, `mail_routing: valid` con `smtp: unknown` deja una duda distinta de `domain: unknown`. El primer caso tiene evidencia de la ruta; el segundo aún no ha resuelto el dominio. La causa permite decidir si otra comprobación puede ayudar. La [comparación entre unknown y undeliverable](https://emvero.io/es/compare/unknown-kept-apart/) trata esa decisión concreta. ## Usar `confidence` y `freshness` dentro de sus límites `confidence` es una puntuación de la evidencia entre 0 y 1. No es una probabilidad de entrega calibrada: `0.7` no significa que vaya a llegar el 70 % de los mensajes. Una regla como `confidence > 0.85` tampoco demuestra acceso al buzón ni garantiza entrega. Use la puntuación para ordenar dentro de un estado o priorizar una revisión. La [documentación de confidence](https://docs.emvero.io/answers/confidence/) explica el valor; la [comparación entre puntuación y evidencia](https://emvero.io/es/compare/score-vs-evidence/) muestra por qué no sustituye a los demás campos. `freshness` registra por separado los momentos de observación de DNS y SMTP: ``` { "freshness": { "dns_checked_at": "2026-09-05T09:14:22Z", "smtp_checked_at": "2026-09-05T09:14:23Z" } } ``` Son los momentos en que se obtuvo la evidencia, no cuando recibió la respuesta. Una respuesta en caché conserva sus marcas de tiempo originales. Elija una antigüedad aceptable para su caso y compruebe las fechas al consultar de nuevo: otra solicitud puede devolver la misma evidencia en caché. La guía sobre [cuándo volver a verificar una lista de correo](https://emvero.io/es/blog/when-to-reverify-email-list/) explica esa decisión. ## Ejemplo: una dirección desechable aceptada Esta respuesta completa es ilustrativa y utiliza un dominio reservado para ejemplos. No es una comprobación en vivo ni una medición de un proveedor concreto. ``` { "id": "00000000-0000-4000-8000-000000000001", "generation": 1, "email": "person@disposable.example", "normalized": { "domain": "disposable.example", "ascii_domain": "disposable.example" }, "status": "risky", "confidence": 0.85, "action": "allow", "checks": { "syntax": "valid", "domain": "valid", "mail_routing": "valid", "smtp": "accepted", "accept_all": "unknown", "disposable": true, "role_account": false, "public_provider": false, "smtp_utf8_required": false }, "reason_codes": ["SMTP_RCPT_ACCEPTED", "DISPOSABLE_DOMAIN"], "freshness": { "dns_checked_at": "2026-09-05T09:14:22Z", "smtp_checked_at": "2026-09-05T09:14:23Z" } } ``` El destinatario SMTP fue aceptado, pero `DISPOSABLE_DOMAIN` cambia el estado a `risky`. La acción sigue siendo `allow`. Un buzón temporal puede funcionar técnicamente aunque su duración no encaje con las necesidades del producto. Decida esa regla de negocio por separado. Puede admitirlo para una newsletter o pedir una dirección duradera para una prueba de pago. Conserve la evidencia devuelta para que la decisión de negocio no parezca un fallo técnico. ## Ejemplo: un sondeo aplazado por greylisting La segunda respuesta completa también es ilustrativa. La sintaxis y la ruta de correo superaron las comprobaciones, pero el servidor receptor aplazó la sesión. ``` { "id": "00000000-0000-4000-8000-000000000002", "generation": 1, "email": "person@greylisted.example", "normalized": { "domain": "greylisted.example", "ascii_domain": "greylisted.example" }, "status": "unknown", "confidence": 0.4, "action": "allow_with_email_confirmation", "checks": { "syntax": "valid", "domain": "valid", "mail_routing": "valid", "smtp": "unknown", "accept_all": "unknown", "disposable": false, "role_account": false, "public_provider": false, "smtp_utf8_required": false }, "reason_codes": ["SMTP_GREYLISTED"], "freshness": { "dns_checked_at": "2026-09-05T09:14:22Z", "smtp_checked_at": "2026-09-05T09:14:23Z" } } ``` `SMTP_GREYLISTED` deja el resultado en `unknown`. No demuestra que el buzón exista ni que esté ausente. En un [formulario de registro](https://emvero.io/es/guides/signup-form-validation/), siga la acción y haga que su aplicación envíe confirmación cuando necesite comprobar el acceso; el sondeo de Emvero no envía correo. Una verificación posterior puede aportar evidencia, sin prometer un resultado concreto. Durante la [limpieza de una lista de correo](https://emvero.io/es/guides/cleaning-an-email-list/), conserve la dirección y el motivo en un grupo separado hasta decidir si volver a comprobarla o mantenerla pendiente de revisión. Enviar automáticamente a todas las direcciones desconocidas presupone más de lo que demuestra esta respuesta. ## Guardar la decisión y su fundamento con la dirección Consulte primero las comprobaciones sin terminar. Para resultados finales, parta de `action`, use `reason_codes` para precisar la política y consulte `checks` para localizar lo que sigue sin probarse o resolverse. `confidence` sirve para ordenar; `freshness`, para evaluar la antigüedad de los datos. Guarde la evidencia junto con la decisión para poder explicar una aceptación, una petición de confirmación o un rechazo posterior. La página de la [API de verificación de correo](https://emvero.io/es/email-verification-api/) muestra cómo solicitar una comprobación y recuperar su resultado. ## Términos que aparecen aquí ### Dominio catch-all Un dominio cuyo servidor acepta destinatarios aunque no exista un buzón para cada dirección. ### Greylisting Una política antispam que aplaza un intento SMTP y puede permitirlo más adelante. ### Rechazo ambiguo Un rechazo del destinatario que no basta para distinguir un buzón inexistente de una restricción del servidor. ## Situaciones a las que se aplica ### Validar una dirección en un formulario de registro Alguien espera al otro lado de la petición, así que la latencia define el diseño y un rechazo equivocado le cuesta el cliente. ### Limpiar una lista antes de un envío Está protegiendo la reputación del dominio desde el que envía, así que la pregunta no es qué direcciones son malas, sino cuáles puede permitirse este envío. [Todos los artículos](https://emvero.io/es/blog/) ## Elige qué comprobar ahora. Haz una consulta desde tu cuenta y examina los datos del resultado. Empezar gratis