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 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 explains why a mailbox check cannot replace these records or identify spam traps.
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 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
Try it on an address you already know.
The free checker returns the whole result - every stage, every reason code, nothing held back.