The checks, in order
A verifier runs a sequence of checks, cheapest first. Each one can end the process early with a clear answer.
- Syntax. Does the address have the shape defined for the Internet message format (RFC 5322): a local part, an @, and a valid domain?
- Domain exists. Does the domain resolve in DNS? A domain that does not exist cannot receive mail.
- Mail servers (MX). Does the domain publish MX records, the DNS entries that tell senders where to deliver mail?
- Disposable provider. Is the domain a known throwaway or temporary-mail service?
- Role account. Is the local part a shared mailbox such as info@, sales@ or admin@?
- Typos. Is the domain a likely misspelling of a common provider, such as gmial.com?
- Mailbox probe. Where the receiving server allows it, an SMTP conversation (RFC 5321) asks whether it would accept mail for the address, without delivering a message.
Why some results are Unknown or Probably valid
The mailbox probe is the only check that speaks to the real mailbox, and it is the least reliable. Three situations are common:
- Catch-all domains accept mail for any local part, so the server's answer says nothing about whether a specific mailbox exists.
- Providers that block or rate-limit probes to prevent address harvesting, so the server never gives a clear yes or no.
- Temporary failures such as DNS timeouts or greylisting, where the honest answer is that the check could not finish.
A trustworthy verifier reports these as Unknown or Probably valid, with the evidence, instead of collapsing them into valid or invalid.
Verification, validation and list cleaning
| Term | Meaning |
|---|---|
| Validation | Is the address well formed? Syntax and sometimes domain checks only. |
| Verification | Can the address receive mail? Adds DNS, mail servers and, where possible, the mailbox. |
| List cleaning | The workflow around verification: dedupe, remove invalid addresses, then decide what to do with risky ones. |
When to verify
- At signup, to catch typos and throwaway addresses before they enter your database.
- Before a campaign, to remove addresses that would bounce.
- When importing leads from forms, events or purchased or scraped sources.
- On a schedule for older lists, because mailboxes close and domains lapse.
What verification cannot do
- It cannot confirm that a person reads the mail or consented to receive it.
- It cannot guarantee inbox placement. Delivery also depends on your sender authentication and reputation.
- It cannot reliably identify spam traps.
- It cannot see inside a catch-all domain.