What email verification establishes
Email verification checks whether an address is correctly formed and what its domain and mail server disclose about receiving mail. It can identify malformed addresses, missing routing, mailbox rejections and risk flags. It does not prove permission to contact the owner, ownership of an account or future inbox placement.
Keep three decisions separate: a verifier checks mailbox signals; a confirmation email establishes access to an inbox; your subscription process records consent. Replacing any of these with a single “valid” label creates gaps in the workflow.
A layered check
- Format: reject incomplete input and preserve meaningful characters such as + in aliases. Do not assume every unusual-looking local part is invalid.
- Routing: inspect the domain and DNS mail-routing records. MX describes a receiving server, not a named recipient. SMTP also defines fallback routing for some domains without MX.
- Mailbox signals: interpret the receiving server's response. Some servers defer, block probes or accept arbitrary recipients.
- Risk flags: review disposable, shared-role and catch-all contacts according to the purpose of your application.
Build a decision policy, not a yes/no shortcut
| Observation | Suggested handling |
|---|---|
| Confirmed invalid | Ask the user to correct it; exclude confirmed invalid contacts from campaigns. |
| Valid with no risk flags | Continue your consent or account-confirmation flow. |
| Unknown or catch-all | Keep for review, including recent engagement and delivery history. |
| Tool failure | Mark the check unavailable; do not classify the mailbox. |
Illustrative signup example: a user enters an address with an apparent domain typo. Display the suggestion and let the user confirm it. A silent correction might send account information to someone else's address. If the server times out, offer a later retry or a confirmation flow rather than claiming the address does not exist.
Where to check and what to save
For one address, you can use a free checker without signup. For an application, call verification from your backend and keep credentials out of browser code. Save only the information you need: result, reason, flags and verification time. Avoid writing API keys or unnecessary contact data into logs.
Review the result again when its age, collection source or sending context makes it less useful. Verification is a snapshot, not a permanent property of a contact. A successful send today also does not override an unsubscribe tomorrow.