Guías
Validar direcciones del CRM sin perder el historial
Asocie las pruebas al valor exacto del correo en su CRM. Separe el resultado más reciente, las observaciones anteriores y la decisión de envío.
Qué hacer con cada respuesta
Los mismos cuatro resultados siempre. La instrucción cambia con la situación, porque con ella cambia lo que cuesta equivocarse.
| Resultado | Qué hacer aquí |
|---|---|
| Entregable | Guarde el resultado con la dirección comprobada y las fechas de las pruebas. Valore la campaña por separado; no marque como nueva una observación antigua en caché. |
| Con riesgo | Conserve el contacto y anote los motivos. Aplique una regla para el mensaje previsto; no trate la marca de función como un fallo al comprobar el buzón. |
| No entregable | Deje de enviar al valor comprobado hasta corregirlo o cambiar la decisión con nuevas pruebas. Conserve el historial; verificar no es, por sí solo, una política de borrado. |
| Desconocido | Registre el último resultado no concluyente y sus motivos. Conserve las pruebas anteriores como historial, pero no mantenga un deliverable antiguo activo para enviar sin revisión. |
Vincular el resultado a un campo de correo
Una ficha de contacto puede contener empresa, responsable, oportunidades y correspondencia. La verificación afecta a su campo de correo. Guarde el email enviado con el id, status, action, reason_codes y checks de la verificación. Si alguien cambia la dirección, el resultado anterior corresponde al valor antiguo. Compruebe la nueva dirección antes de aplicarle una decisión.
Dos contactos con el mismo correo no son necesariamente la misma persona. Decida las fusiones según sus reglas del CRM, por separado de la verificación. Emvero no fusiona contactos ni actualiza automáticamente su CRM; su integración o proceso de importación escribe el resultado. La API de verificación de correo explica la petición y la respuesta.
Separar las fechas de observación y recuperación
Cuando aparecen, freshness.dns_checked_at y freshness.smtp_checked_at indican cuándo se recogieron las pruebas respectivas. Guarde esas fechas originales junto a la hora de su petición o recuperación. Un resultado en caché puede conservar pruebas SMTP antiguas; no sustituya su fecha por la de hoy. La guía del resultado de verificación explica cómo interpretar la antigüedad de las pruebas.
Registrar una comprobación incierta sin perder el historial
Suponga que la misma dirección había devuelto deliverable y la última comprobación completada devuelve unknown. Conserve el resultado anterior como observación histórica con fecha y registre el nuevo con sus motivos. Unknown puede seguir conteniendo pruebas válidas del dominio.
Haga visible la nueva incertidumbre en su lógica de envío. No deje que la etiqueta entregable del historial apruebe una campaña sin revisión. Su política puede retener la dirección o comprobarla después. Si la dirección cambió, ninguna prueba antigua establece nada sobre el nuevo valor.
Elegir una regla de envío sin borrar el contacto
Ante un fallo técnico, excluya la dirección comprobada hasta corregirla o revisarla; el historial del contacto puede seguir siendo útil. Una dirección genérica es un atributo separado, no un rechazo automático. El contexto de suscripción y las exclusiones siguen siendo sus propios registros. La verificación tampoco decide cuánto tiempo debe conservar un contacto. Para seleccionar una campaña, use el proceso de limpieza de listas junto con la tabla anterior.
Reason codes que deciden algo aquí
Estos códigos forman parte del vocabulario de la API y explican una comprobación. Las notas también indican qué valores no devuelve la política de verificación o el sondeo actual.
SMTP_MAILBOX_NOT_FOUND | Rechazo del destinatario observado por SMTP; la regla actual devuelve unknown con SMTP_RECIPIENT_REJECTED_AMBIGUOUS. |
DNS_NXDOMAIN | El dominio no existe |
ACCEPT_ALL_UNKNOWN | Código definido para un comportamiento catch-all sin determinar; la política actual no lo devuelve |
ROLE_ACCOUNT | El nombre de la dirección indica una función; no identifica a quien usa el buzón |
Términos que conviene conocer antes
Rebote duro y rebote blando
Los fallos de entrega permanentes y temporales describen un intento de envío. Aquí se explica cómo se diferencian de la evidencia de verificación.
Dominio catch-all
Un servidor acepta destinatarios arbitrarios. Esa aceptación por sí sola no demuestra que exista un buzón concreto.
Dirección de función
Una dirección para un equipo o una función, como support@. Puede recibir correo; su idoneidad depende del propósito.
La decisión que hay detrás
Verificación de correo frente a higiene de listas
La evidencia técnica y los registros de suscripción, exclusión de envíos e interés responden a preguntas distintas sobre el envío.
Verificación en tiempo real frente a verificación de listas
Compruebe una dirección mientras alguien espera o recorra una lista guardada. Compare tiempos, respuestas pending y el proceso que gestiona su sistema.
Pruébelo con una dirección que ya conozca.
El verificador gratuito devuelve el resultado completo: cada etapa, cada reason code, sin ocultar nada.