---
title: "CRM email validation without losing contact history - Emvero"
description: "Validate CRM email fields while retaining contact history. Bind results to the checked address, preserve evidence dates and record inconclusive rechecks."
url: https://emvero.io/guides/crm-data-cleaning/
language: en
updated: 2026-10-09
---

Guides

# Validate CRM email addresses without losing history

Attach verification evidence to the exact email value in your CRM. Keep the latest result, earlier observations and your sending decision separate.

## What to do with each answer

The same four verdicts every time. The instruction changes with the situation, because what a mistake costs changes with it.

| Verdict | What to do here |
| --- | --- |
| Deliverable | Store the result against the checked email with its evidence dates. Review campaign eligibility separately; do not mark an old cached observation as new. |
| Risky | Keep the contact and annotate the reasons. Apply a rule suited to the intended message; do not treat a role flag as a failed mailbox check. |
| Undeliverable | Stop sending to the checked value until it is corrected or new evidence changes the decision. Preserve contact history; verification alone is not a deletion policy. |
| Unknown | Record the latest inconclusive result and its reasons. Retain earlier evidence as history, but do not silently keep an old deliverable result effective for sending. |

## Bind the result to one email field

A contact record can contain company details, ownership, deals and correspondence. Verification concerns its email field. Keep the submitted `email` with the verification `id`, `status`, `action`, `reason_codes` and `checks`. If someone edits the address, the previous result belongs to the old value; check the replacement before applying a decision to it.

Two contacts sharing an email address are not necessarily duplicate people. Decide record merging through your CRM rules, separately from address verification. Emvero does not merge contacts or update your CRM automatically; your integration or import process writes the result. The [email verification API](https://emvero.io/email-verification-api/) explains the request and response.

## Keep observation dates and retrieval dates separate

When present, `freshness.dns_checked_at` and `freshness.smtp_checked_at` record when the respective evidence was gathered. Save those original dates alongside your own request or retrieval time. A cached result can retain older SMTP evidence; do not replace its observation date with today. The [verification result guide](https://emvero.io/blog/reading-a-verification-result/) explains how to read freshness.

## Record an inconclusive recheck without losing history

Suppose the same address previously returned `deliverable` and the latest completed check returns `unknown`. Keep the earlier result as a dated historical observation and record the new result with its reasons. Unknown may still contain valid domain evidence.

Make the latest uncertainty visible to your sending logic. Do not let the historical deliverable label silently approve a campaign. Your policy may hold the address for review or check it later. If the address has changed, none of the old evidence establishes anything about the replacement.

## Choose a sending rule without destroying the contact

For a technical failure, exclude the checked address until correction or review; the contact history can remain useful. A [role account](https://emvero.io/glossary/role-account/) is a separate attribute, not an automatic refusal. Subscription context and exclusions remain your own records, and verification does not decide how long you should retain a contact. For campaign selection, use the [list-cleaning workflow](https://emvero.io/guides/cleaning-an-email-list/) alongside the verdict table above.

## Reason codes that decide something here

The API uses these identifiers to explain a check. The notes identify values that the current verification policy or probe does not return.

|  |  |
| --- | --- |
| `SMTP_MAILBOX_NOT_FOUND` | Recipient refusal observed by SMTP; current policy returns unknown with SMTP_RECIPIENT_REJECTED_AMBIGUOUS. |
| `DNS_NXDOMAIN` | Domain does not exist |
| `ACCEPT_ALL_UNKNOWN` | Defined code for unresolved catch-all behaviour; the current verification policy does not return it |
| `ROLE_ACCOUNT` | Address uses a role name |

## Terms worth knowing first

### Hard bounce and soft bounce

Permanent and temporary delivery failures describe a sending attempt. Learn how they differ from verification evidence.

### Catch-all domain

A mail server accepts arbitrary recipients, so acceptance alone cannot establish whether a particular mailbox exists.

### Role account

An address for a team or function, such as support@. It can receive mail; its suitability depends on the purpose.

## The choice behind this

### Email verification vs list hygiene

Technical address evidence and ongoing subscription, suppression and engagement records answer different sending questions.

### Real-time vs list verification

Check one address while someone waits or work through a stored list. Compare timing, pending responses and the workflow your system manages.

[All guides](https://emvero.io/guides/)

## Try it on an address you already know.

The free checker returns the whole result - every stage, every reason code, nothing held back.

See an example check

Start for free