What Does Email Address Verification Actually Check?

Updated

Email address verification checks more than whether an address looks correctly formatted. A verifier typically examines syntax, the domain's mail (MX) records, whether the mailbox appears to exist, and whether the domain is disposable or a free provider — then returns a status such as deliverable, undeliverable, risky, or unknown rather than a simple yes/no. WhoisXML API's Email Verification service describes its products as answering "these questions and others" for every email, and offers three delivery modes: an API, bulk verification, and a disposable email domains database. Which one fits depends on whether you're checking one address interactively, cleaning a list, or filtering signups at scale.

The specific checks behind a verification result

Most verification pipelines run through a sequence of gates. Each gate can pass, fail, or return an inconclusive result:

Check What it looks at Typical failure signal
Syntax Format per RFC rules (local part, @, domain) Malformed address
Domain / DNS Whether the domain resolves and has MX records No MX, domain doesn't exist
Mailbox existence SMTP handshake or equivalent probe against the mail server Rejected recipient
Disposable domain Whether the domain belongs to a throwaway service Match against a disposable-domain list
Free domain Whether the domain is a consumer webmail provider Match against a free-domain list
Role account Whether the local part is generic (e.g., info@, sales@) Flagged as role-based, not personal

The page evidence lists these as the questions the service answers for every email, and separately notes a Disposable Email Domains Database and a Free Email Domains Database as distinct products — meaning disposable and free detection are treated as their own data problems, not just side effects of an SMTP probe.

Why you get statuses, not a yes/no

A verifier can only report what the receiving server tells it. Several conditions make a definitive answer impossible:

  • Catch-all domains accept mail for any address at the domain, so the server won't confirm whether a specific mailbox exists.
  • Greylisting temporarily rejects first-time senders; a probe that doesn't retry may read this as undeliverable.
  • SMTP timeouts or rate limiting from the receiving server leave the result unknown rather than invalid.

This is why results come back as deliverable, undeliverable, risky, or unknown. A "risky" or "unknown" result isn't a bug — it's the honest output when the domain's configuration prevents a conclusive check. Treating unknown as undeliverable will discard real addresses; treating it as deliverable will let some bad ones through.

API vs. bulk validator vs. disposable-domain feed

These three modes solve different problems, and the choice follows from your workflow:

Real-time API — for checking a single address at the moment of capture, such as a signup form or a support ticket. You get a per-address answer immediately, which lets you block or flag the address before it enters your system.

Bulk verification — for cleaning an existing list before a send. You submit many addresses at once and get statuses back for each, then suppress the undeliverable and risky ones. This is a batch job, not an interactive check.

Disposable email domains database — for filtering at scale without a per-address round trip. If your main concern is throwaway signups, matching the domain against a downloadable list is faster and cheaper than verifying every address individually. WhoisXML API lists this as a separate product with its own pricing page.

A practical pattern is to combine them: use the disposable-domain feed as a fast first filter, the API for real-time signup checks, and bulk verification for periodic list hygiene.

Choosing based on your use case

  • Signup forms and transactional flows → real-time API, so you can act on the result before the address is stored.
  • Marketing list cleaning before a campaign → bulk verification, because you need statuses for thousands of addresses in one pass.
  • High-volume signup abuse prevention → disposable email domains database, because domain-level matching scales without per-address latency.
  • Mixed needs → the service's product lineup supports combining these; the page presents them as separate products rather than one bundled tool.

WhoisXML API's page states that free trials are available, and its pricing links reference "Start from $129/month," API pricing, and database pricing as separate pages. Check the specific product page for the mode you need, since API and database pricing are listed separately.

Common reasons a valid-looking address fails

If an address that clearly exists comes back undeliverable or unknown, the cause is usually on the receiving side, not the address itself:

  1. The domain uses a catch-all, so no per-mailbox confirmation is possible.
  2. The server greylists or rate-limits probes, producing a timeout.
  3. The mailbox is real but the server refuses SMTP verification for anti-spam reasons.
  4. The address is a role account or alias that the verifier flags as risky rather than invalid.

In each case, the right response is to route the address to a review or retry path rather than hard-rejecting it.