---
title: "How to clean an email list before sending - Emvero"
description: "Review a list before a campaign: retain its history, verify addresses, separate uncertain results and apply subscription and suppression rules."
url: https://emvero.io/guides/cleaning-an-email-list/
language: en
updated: 2026-10-09
---

Guides

# How to clean an email list before sending

Keep the original list, check the addresses and build a sending segment from the evidence. Treat technical failures, uncertainty and subscription rules separately.

## 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 | Consider it for this campaign only after checking subscription context and exclusions. A positive result does not guarantee delivery or permission to send. |
| Risky | Review the reasons before including it. Hold unresolved cases for this campaign; keep the contact and record why it was held. |
| Undeliverable | Exclude the checked address from this send. Keep the evidence and contact history; require a correction or new evidence before reconsidering it. |
| Unknown | Hold it from this campaign until review or a later check. Keep any established domain evidence and the reason for uncertainty; do not classify it as invalid. |

## Start with the list and its history

Save the original data before changing a campaign segment. Keep the address source, subscription context, unsubscribe and complaint exclusions, and previous delivery outcomes. Deduplicate identical email values without merging people or erasing their history. A verification result does not override an existing exclusion.

## Check addresses and retain the evidence

Verify the addresses you are considering for the send. Store `status`, `action`, `reason_codes` and `checks` with the checked value. Keep `freshness` too: retrieving a result today does not mean every observation was made today. The [verification result guide](https://emvero.io/blog/reading-a-verification-result/) explains those fields.

A `pending` response means the check is unfinished. Wait for `retry_after_ms`, then retrieve the same verification. Keep pending work out of the reviewed segment until it finishes or your own deadline triggers a fallback.

## Separate failure from uncertainty

Use the verdict table above as a campaign policy, together with the returned action and reasons. Clear syntax or domain failures can establish `undeliverable`. A recipient refusal does not automatically do so: `SMTP_MAILBOX_NOT_FOUND` is currently reported as `unknown` with `SMTP_RECIPIENT_REJECTED_AMBIGUOUS`.

A catch-all result or an inconclusive SMTP attempt may need review. Holding that address for this campaign preserves the option to reconsider it. A role flag alone does not change the verdict, and a working mailbox still needs the right subscription context. Unknown results may retain useful domain findings.

## Apply the sending rules before export

Build the campaign segment from the reviewed results and your subscription, suppression and delivery records. Keep held addresses separate from confirmed technical failures. The [verification and list hygiene comparison](https://emvero.io/compare/verification-vs-list-hygiene/) explains why a mailbox check cannot replace these records or identify [spam traps](https://emvero.io/glossary/spam-trap/).

Choose when to recheck from the age of the evidence and the use you are planning; there is no universal interval. A later check may add evidence without guaranteeing delivery. If the source is your CRM, the [CRM email validation guide](https://emvero.io/guides/crm-data-cleaning/) shows how to keep results with the address while preserving the contact record.

## 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. |
| `ACCEPT_ALL_DOMAIN` | Domain accepts every recipient |
| `SMTP_CONNECT_TIMEOUT` | Mail server did not answer in time |
| `DISPOSABLE_DOMAIN` | Disposable address provider |

## 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.

### Spam trap

An address used to identify problematic sending practices. A verification check cannot certify that an address is not a trap.

## The choice behind this

### Email verification vs list hygiene

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

[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