Email verification, explained

Email verification checks whether a mailbox exists by asking the receiving mail server directly, and stopping before any message is transmitted. Nobody receives a test email.

What a check looks at

• Syntax. Is the address structurally valid under RFC 5322?
• Domain. Does the domain resolve in DNS?
• [MX records](/learn/mx-records). Which servers accept mail for this domain?
• Mailbox. Will the receiving server accept mail for this specific address?
• Signals. Disposable providers, role accounts and catch-all behaviour.

Nothing is ever delivered to the recipient at any stage.

Why the result isn't always binary

• [Catch-all](/learn/catch-all-email) domains accept every address, so acceptance proves nothing on its own. VeriMailX resolves these to a definitive verdict; most verifiers do not.
• [Greylisting](/learn/greylisting) makes a receiving server defer unfamiliar senders, so the check has to be repeated later.
• Some providers deliberately obscure mailbox existence for privacy.

A serious verifier handles these honestly instead of forcing every address into valid or invalid.

What the statuses mean

• Valid — the mailbox exists and will accept mail.
• Invalid — permanent rejection; do not send.
• Catch-all / accept-all — accepted, and unresolved by most tools.
• Disposable — a temporary mailbox from a throwaway provider.
• Role — a shared team inbox.
• Unknown — the check could not complete; retry.

Doing it yourself vs using a service

Getting reliable answers at any volume is hard: networks block the traffic, unfamiliar senders get throttled, and provider behaviour changes constantly. That is the work a verification service absorbs — see the email verification api for how to call it in one request.