---
title: "Validar correos del CRM sin perder el historial - Emvero"
description: "Valide los campos de correo del CRM sin perder el historial. Vincule el resultado a la dirección, conserve las fechas y registre comprobaciones inciertas."
url: https://emvero.io/es/guides/crm-data-cleaning/
language: es
updated: 2026-10-09
---

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](https://emvero.io/es/email-verification-api/) 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](https://emvero.io/es/blog/reading-a-verification-result/) 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](https://emvero.io/es/glossary/role-account/) 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](https://emvero.io/es/guides/cleaning-an-email-list/) 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.

[Todas las guías](https://emvero.io/es/guides/)

## Pruébelo con una dirección que ya conozca.

El verificador gratuito devuelve el resultado completo: cada etapa, cada reason code, sin ocultar nada.

Ver una comprobación de ejemplo

Empezar gratis