Vuelva a verificar una lista de correo cuando la última evidencia sea demasiado antigua para la decisión que va a tomar o aparezca un dato que ponga en duda el resultado. Si prepara una campaña, decídalo antes del envío. Si aún no va a usar un contacto del CRM, conserve el resultado y su fecha para evaluarlos cuando lo necesite. Ningún plazo fijo garantiza que todas las direcciones funcionen durante un mes ni que dejen de funcionar al día siguiente.
Defina la antigüedad máxima que acepta para cada uso. Revísela cuando vaya a emplear la dirección y adelante la comprobación si hay un rebote, cambia la dirección o se reanuda el envío tras una pausa larga. Ese plazo es una regla de su equipo, no una fecha de caducidad establecida por Emvero.
Decidir antes de usar la lista
Para el segmento previsto, responda a tres preguntas:
- ¿Cuándo se obtuvo la evidencia? Guarde el último estado y las fechas de observación junto a cada dirección. La fecha de importación de un CSV o de consulta de una respuesta almacenada no cambia la fecha de la comprobación original.
- ¿Qué ha ocurrido después? Una dirección corregida requiere su propia comprobación. Un rebote, un cambio de dominio o una campaña tras una pausa larga reducen el valor de la evidencia anterior. Una baja o un bloqueo siguen siendo decisiones independientes sobre el envío: un nuevo
deliverableno los anula. - ¿Para qué necesita la dirección? Un mensaje de bienvenida durante el alta, una campaña a un segmento antiguo y un contacto del CRM todavía inactivo tienen plazos y consecuencias distintos. Fije una antigüedad máxima para cada flujo y revísela con sus propios datos de rebotes y respuestas.
Por ejemplo, un equipo podría exigir que la evidencia tenga como máximo 14 días al aprobar una campaña. Es una regla interna ilustrativa, no una recomendación sobre la vigencia de una dirección ni una medida de la velocidad a la que cambian los buzones. Una dirección comprobada tres días antes cumple la regla; otra comprobada hace cinco semanas necesita una nueva revisión. En ambos casos deben respetarse las autorizaciones y exclusiones del envío.
| Lo que sabe antes del próximo uso | Decisión sobre el momento de verificar |
|---|---|
| El segmento se comprobó hace poco según su regla y no hay señales negativas nuevas. | Conserve el resultado para esta decisión. Revise su antigüedad de nuevo en el siguiente uso. |
| La lista lleva tiempo inactiva o se importó sin una fecha de comprobación fiable. | Compruébela antes del próximo envío. La importación no demuestra que las direcciones puedan recibir correo. |
| Cambió una dirección o el informe de entrega muestra un rebote. | Examine la causa y excluya por ahora la dirección afectada del envío. Compruebe la dirección corregida como una dirección nueva; otro resultado no borra una baja ni un fallo de entrega conocido. |
El último intento devolvió unknown o sigue pending. |
No tome una decisión que requiera un resultado definitivo. Repita la comprobación o consulte la misma verificación en curso, según proceda. Ninguno de los dos estados significa undeliverable. |
La guía para limpiar una lista antes de un envío explica qué hacer con un resultado actual deliverable, risky, undeliverable o unknown. Aquí la decisión es cuándo pedir otro resultado.
Consultar cuándo se obtuvo la evidencia
Emvero devuelve freshness.dns_checked_at y freshness.smtp_checked_at por separado cuando esas comprobaciones aportan evidencia. La ruta DNS y la respuesta SMTP sobre un destinatario pueden haberse observado en momentos distintos. Una respuesta almacenada conserva las fechas originales; volver a consultarla no renueva la evidencia. El artículo sobre cómo interpretar el resultado de verificación explica estos campos y sus límites.
Guarde el resultado, las fechas de observación y la decisión que tomó. Si una comprobación nueva no aclara el caso, conserve la observación anterior y su fecha original para poder reconstruir el historial. Registre el nuevo intento como unknown, un resultado reciente pero inconcluso. No presente un deliverable antiguo como si fuera reciente. Si recibe pending, consulte esa misma verificación después del intervalo indicado antes de tomar una decisión definitiva.
Una verificación completa puede obtener evidencia sobre el destinatario sin enviarle un mensaje. El servidor receptor puede ocultar la respuesta. Incluso si acepta al destinatario, eso no garantiza entregas futuras ni prueba que la persona controle el buzón. Elija un límite de antigüedad adecuado para la decisión y tenga presentes estas limitaciones.
Separar el permiso de envío de la verificación
La verificación ayuda a valorar si una dirección puede recibir correo. No demuestra que la persona haya pedido recibir su campaña. Un contacto que se dio de baja debe seguir excluido aunque una comprobación posterior devuelva deliverable. Para mensajes dirigidos a cuentas personales de Gmail, las directrices de Google para remitentes recomiendan confirmar la dirección de cada destinatario antes de suscribirlo y facilitar la baja.
Un informe de rebote es una señal que conviene investigar. No repita la verificación de la misma dirección indefinidamente hasta obtener un resultado favorable. Conserve por separado el evento de entrega, la comprobación y el registro del permiso.
Si va a revisar una lista que gestiona por su cuenta, el proceso de CSV a API muestra cómo enviar una petición desde el servidor por cada dirección, retomar las verificaciones pending y asociar cada resultado a su fila original. Defina antes la regla de antigüedad para seleccionar las direcciones que toca revisar.