What Does an Email Validator Actually Check?

An email validator checks an address in layers, from simple text formatting up to whether the mailbox can actually receive mail. Most tools run syntax checks, domain and MX record lookups, and mailbox-level probes, then add risk signals like disposable domains and role accounts. The result is usually a status such as valid, invalid, risky, or unknown — and the right action depends on which layer failed, not just the final label.

Syntax and format checks

The first pass is purely textual. The validator confirms the address matches the expected structure: a local part, an @ symbol, and a domain.

• Local part: allowed characters, no leading or trailing dot, no consecutive dots.
• Domain: at least one dot, valid characters, no leading or trailing hyphen in a label.
• Length limits: the local part and the full address stay within RFC-defined maximums.

This layer catches typos like [email protected] or name@domain with no top-level domain. It cannot tell you whether the mailbox exists — a syntactically perfect address can still be dead.

Domain and MX record checks

Next, the validator asks whether the domain can receive email at all.

• Domain existence: does the domain resolve in DNS?
• MX records: are there mail exchanger records pointing to a mail server?
• Fallback A/AAAA record: some valid setups accept mail on the domain itself when no MX record exists, so a good validator checks this too.

If the domain has no MX record and no fallback, the address cannot receive mail regardless of how it looks. This is a strong invalid signal.

Mailbox-level checks

This is where validators differ most. A mailbox check opens an SMTP conversation with the destination mail server and asks whether the specific address is accepted — without sending a message.

• SMTP handshake: connect, greet, and issue a RCPT TO command for the address.
• Server response: an acceptance suggests the mailbox exists; a rejection suggests it does not.
• Catch-all detection: some servers accept every address. A validator tests a random address at the same domain — if that is also accepted, the domain is catch-all and individual results are unreliable.

Mailbox checks are the most informative layer but also the least deterministic. Greylisting, rate limits, and servers that refuse to confirm addresses can all produce an "unknown" result rather than a clean yes or no.

Risk signals beyond existence

A deliverable address can still be a bad address to send to. Validators flag:

• Disposable domains: temporary inbox providers. WhoisXML API publishes a Disposable Email Domains Database for this purpose.
• Role accounts: addresses like info@, sales@, or support@ that reach a group rather than a person.
• Free email domains: consumer providers, which may matter for B2B list hygiene. WhoisXML API also offers a Free Email Domains Database.
• Spam traps and known-bad addresses: addresses that exist only to catch senders with poor list hygiene.

These signals do not make an address invalid. They make it risky, and the decision to keep or drop it depends on your use case.

How to interpret the results

The key point: "valid" is not the same as "wanted." A validator tells you whether mail can be delivered, not whether the recipient will engage. Use the status to clean hard failures first, then apply risk rules that match your sending policy.

What a validator does not check

• Whether the person wants your email — that is a consent and engagement question, not a technical one.
• Whether the inbox is full — a full mailbox may still accept the message and bounce later.
• Content or intent — an address tied to a spam trap looks normal at every technical layer.

For a practical workflow, run syntax and domain checks on every address at capture time, run mailbox and risk checks before a campaign, and re-verify addresses that have not been contacted in several months. WhoisXML API's Email Verification API and Bulk Email Verification API cover these layers, and the site lists free trials alongside paid API and database pricing.