What Does an Email Verifier Actually Check?

An email verifier checks an address at several layers: syntax, domain and MX records, mailbox existence via SMTP, and risk signals such as disposable or role-based addresses. It confirms whether an address is technically deliverable and flags risky ones, but it cannot guarantee a human will open or read your message. The checks below are the ones WhoisXML API's Email Verification service describes, and they apply to most verifiers on the market.

The Four Layers of Verification

1. Syntax Check

The verifier parses the address against RFC rules: a local part, an @ symbol, and a valid domain. It catches typos like name@@example.com, missing dots, illegal characters, and trailing spaces.

What it catches: malformed addresses that no mail server would accept. What it misses: a perfectly formatted address that does not exist.

2. Domain and MX Record Check

The verifier looks up the domain and its DNS records, especially the MX (mail exchange) records that tell the internet where to deliver mail for that domain.

• No MX record → the domain cannot receive email; the address is undeliverable.
• MX record present → the domain is configured to accept mail, so the address passes this layer.

This step also surfaces whether the domain is parked, expired, or has no mail infrastructure at all.

3. SMTP Probe (Mailbox Existence)

The verifier connects to the recipient's mail server and starts an SMTP conversation, asking whether the specific mailbox exists. A 250 response suggests the mailbox is real; a 550 typically means it is not.

This is the closest a verifier gets to confirming a mailbox exists, but it has limits:

• Many servers use catch-all configurations, accepting every address at the domain, so a positive response does not prove the individual mailbox is real.
• Some servers greylist or throttle probes, returning inconclusive results.
• Servers may accept then bounce later, so a clean SMTP result is not a delivery guarantee.

4. Risk and Reputation Signals

Beyond deliverability, verifiers flag addresses that are technically valid but risky to send to:

WhoisXML API offers a Disposable Email Domains Database and a Free Email Domains Database as separate data feeds, which is how these signals are typically sourced.

What the Results Mean for Sending Decisions

Verifiers usually return one of four statuses:

• Valid — passes syntax, domain, and mailbox checks. Safe to send.
• Invalid — fails at least one hard check (bad syntax, no MX, mailbox rejected). Remove from your list.
• Risky / Accept-all — technically deliverable but flagged (catch-all, disposable, role-based). Send with caution or segment separately.
• Unknown — the server would not give a definitive answer (greylisting, timeouts). Retry later or treat as risky.

The practical rule: send to valid, suppress invalid, and route risky/unknown into a separate, lower-volume campaign so a bad batch does not drag down your domain reputation.

Single vs. Bulk Verification

• Single (real-time) verification fits sign-up forms, checkout flows, or one-off checks — you verify as the user types or submits.
• Bulk verification fits list cleaning before a campaign. WhoisXML API's Bulk Email Verification API and Bulk Email Verification tool are built for processing large lists at once.

Use single checks to stop bad addresses at the point of entry; use bulk checks to clean lists you already have.

Verification Is a Snapshot, Not a Permanent Label

An address that is valid today can go invalid tomorrow: mailboxes get deleted, domains expire, and catch-all servers change behavior. For lists you reuse, re-verify on a regular schedule — quarterly is a common starting point — and always re-verify before a major send.

Where to Start

WhoisXML API's Email Verification service offers an Email Verification API, a web lookup for single addresses, and bulk validation for lists, with free trials available. Pricing for the API and the disposable email domains database is published on their respective pricing pages.