Cómo interpretar los resultados de verificación de email

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.

La referencia de veredictos 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 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 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 explica el valor; la comparación entre puntuación y evidencia 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 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, 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, 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 muestra cómo solicitar una comprobación y recuperar su resultado.