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 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 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 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 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.
Try it on an address you already know.
The free checker returns the whole result - every stage, every reason code, nothing held back.