How does SimpleVerifier verify an email address?

It checks the syntax, looks up the domain's mail servers in DNS, compares the domain against a disposable list, flags role addresses, then connects to the mail server on port 25 and asks whether it would accept mail for that address (SMTP RCPT TO) without sending a message. It first asks about a random non-existent address to detect catch-all servers.

What do valid, risky and invalid mean?

Valid: the mail server accepted this exact address and does not accept random ones. Invalid: it will bounce or is a throwaway address. Risky: delivery could not be confirmed, for example a catch-all domain, a role address, Outlook or iCloud, or a server that would not answer. Only valid is a confirmation.

Why is an unconfirmed address risky and not valid?

Because calling it valid would be a guess. The code returns valid only when a server accepts the exact address and rejects a made-up one. Every other outcome is risky or invalid, so a valid result is never a hope.

What is catch-all confidence?

A higher, medium or lower likelihood label on rows that are risky because the domain accepts every address. It is built only from data we already have: whether the name format matches confirmed addresses on the same domain, guessed spellings of one name in the list, the format of the rest of the list, and placeholder and disposable flags. In our back-test on 82,853 addresses, higher-graded ones existed 69.0% of the time and lower-graded ones 1.4%. It opens no extra mail connection, never turns a row valid, and is not a per-row percentage.

How accurate is SimpleVerifier?

We do not publish an accuracy percentage because we have not measured one in a way anyone could reproduce. The method on this page is exactly what runs; the limits are listed above. When we run an independent, reproducible benchmark we will publish the method with the number.

How a SimpleVerifier check works

A check runs seven steps in order and stops at the first one that settles the answer: syntax, disposable and typo domains, DNS and mail route, role address, providers that never confirm, a live SMTP RCPT probe of the mail server, and a catch-all test. Only an address the server accepts, on a server that does not accept everything, is valid. Everything unconfirmed is risky.

Written from the verification code, not from marketing. Last checked against the code on 23 October 2026.

What happens to one address

1. Syntax

The address must be a plain unquoted address: letters, digits and . _ % + - before the @, a domain with a letter-only ending, at most 320 characters. A dot may not lead, trail or double up in the part before the @. Fails: invalid, "Invalid format".

2. Disposable and typo domains

The domain is looked up in a list of disposable-email providers. Forwarding and alias services (Apple Hide My Email, DuckDuckGo, SimpleLogin and similar) are deliberately not on it, because they deliver to a real inbox. A near-miss of a large provider (gmial.com) is reported as a typo with a suggestion instead. Fails: invalid, "Disposable address" or "Typo domain - did you mean gmail.com?".

3. DNS and mail route

We look up the domain's MX records. No MX falls back to the domain's own address record, as the mail standard says. A domain that publishes a null MX (it accepts no mail) or has no mail server at all is invalid. A DNS timeout is not treated as a bad domain: the answer is risky and says to try again, and is never remembered.

4. Role addresses

A short list of shared-inbox names (info, support, admin, sales, contact, noreply, hello, billing, team and a dozen more) is answered risky without contacting the mail server. The domain takes mail; whether anyone reads that inbox is not something a check can tell.

5. Providers that never confirm

Outlook.com, Hotmail, Live, MSN and iCloud (including me.com and mac.com) accept mail for any address at the door and sort it out afterwards, so a mailbox check cannot tell a real address from a made-up one. These are answered risky, "Provider hides mailbox status", without a connection.

6. SMTP RCPT probe

For everything else we open a connection to the domain's highest-priority mail server on port 25, introduce ourselves, give a sender, and ask whether it would accept mail for the address (the RCPT TO step). We then hang up. No message is ever sent. A 250 answer means the server accepts the address; a 5xx answer that says the user is unknown means it does not; 4xx answers mean the server deferred (greylisting, a temporary error), which is not an answer.

7. Catch-all test

Before asking about the real address, we ask about a random address that cannot exist at that domain. If the server accepts it, the server accepts everything, so its acceptance of the real address proves nothing. The result is risky, "Accepts all addresses".

The disposable list holds 9,913 domains. The role list, the provider list and the typo matching are fixed lists in the code, not a model. A free check of any address is on the verifier tool.

What valid, risky, invalid and unknown mean

Status	Meaning
valid	The domain's mail server accepted this exact address and does not accept random ones. Reason: Mailbox exists. send_advice: safe.
risky	Delivery is not confirmed. Includes catch-all domains, role addresses, Outlook/Hotmail/iCloud, servers that refused or deferred our check, and the cases where we could not check at all. send_advice: care (the domain takes mail, the mailbox is unconfirmed) or retry (we got no answer; ask again later).
invalid	It will bounce or it is a throwaway: bad format, disposable or typo domain, no mail server, null MX, or the server said the mailbox does not exist. send_advice: do_not_send.
unknown	Not a separate status. The API has exactly three. What other tools call unknown is risky here, with send_advice retry and a reason such as "Mailbox check unavailable" or "Server would not confirm".

Every reply also carries reason, reason_detail and send_advice (safe, care, retry or do_not_send), and mailbox_probed, which says whether this address’s mail server was actually asked. Fields are in the API docs.

Why unconfirmed stays risky

The code that turns a mail server’s reply into a verdict returns valid in one case only: the server answered the exact address with a success code. Deferrals, refusals, unusual replies, timeouts, blocked checks and unreachable servers all become risky with a reason. A 5xx answer becomes invalid only when the server says in words that the mailbox does not exist (or uses the mailbox-unknown status code) and nothing in the reply points at a block or a policy. A refusal at the greeting or at the sender step is about us, never about the mailbox, so it is never “not found”.

A backup mail server is only tried when the main one cannot be reached, and a backup that refuses to relay proves nothing, so that answer stays risky.

Catch-all confidence

A catch-all domain accepts every address, so no verifier can confirm a mailbox there. Those rows stay risky with send_advice care. To make them less of a dead end, each one also gets catch_all_confidence: higher, medium or lower likelihood, with the reasons in catch_all_reasons.

Whether the name format matches confirmed addresses on the same domain, in the same list or in our recent results (first.last next to a confirmed first.last).
Whether the list holds several spellings of the same name on the domain (anna.lee, a.lee, alee): a guess list, where at most one is real.
Whether the address uses the same format as the rest of the list on that domain, and placeholder and disposable flags.

We measured each signal on 82,853 addresses at domains that do answer: higher-graded addresses existed 69.0% of the time, lower-graded ones 1.4%. The mail host, SPF and DMARC records and response timing did not separate real from fake addresses, so they are shown as context only. The label opens no extra mail connection and is not a per-row percentage. The safe-to-send download can add higher catch-alls, or every catch-all except lower; confirmed only is the default. The full method, numbers and limits are on catch-all scoring.

Batching, politeness and caching

Batching. In a list, addresses on the same mail server share one connection: at most 10 RCPT questions per connection, one random-address test per domain, and one conversation per mail server at a time. A server that defers or closes on us is left alone for a growing wait. Single API checks use their own connection.
Provider blocks. Some providers refuse every check from our server (reputation lists, missing reverse DNS). After four refusals in a row from one provider we stop spending connections on it, answer risky “Provider is blocking our checks; not probed”, and test again every couple of hours. We would rather say so than guess.
Daily allowance. Mailbox connections are limited per day. List rows that need one wait for the next reset; a single check past the limit returns risky with budget_exhausted.
Caching. Only answers the server actually gave (mailbox exists, mailbox not found, accepts all addresses) are cached, for 14 days, so a repeat check is instant. A domain found to be catch-all is remembered for 7 days. Failures and deferrals are never cached. Domain mail routes are kept in memory while the service runs.
Credits. Answers where no verdict was reached (check unavailable, refused, deferred, blocked, DNS failure) do not spend free checks or credit packs.

What we cannot know

Whether an Outlook.com, Hotmail, Live or iCloud mailbox exists. Those providers do not say, so every such address is risky.
Whether a catch-all domain has a real mailbox behind an address. The server says yes to everything.
Whether a role inbox is monitored, or whether a person will read or want your email. Verification confirms a mailbox exists, not that mail will reach the inbox rather than spam, and not that the mailbox has space.
Whether a server that refuses checks from our IP is hiding a good or a bad address. We report the refusal as risky instead of guessing.
Whether a phone number is in service. The phone check validates the number against its country's numbering plan, gives the E.164 form and the number type, and with the phone add-on returns the carrier's reported line type. No lookup confirms someone is using a number today.

Accuracy

We publish no accuracy percentage. We have not run an audited, reproducible benchmark, and the checks depend on how each mail server answers on the day, so a single number would be marketing, not measurement. If we publish one, it will come with the address set, the date and how to repeat it.

Common questions

How does SimpleVerifier verify an email address?: It checks the syntax, looks up the domain's mail servers in DNS, compares the domain against a disposable list, flags role addresses, then connects to the mail server on port 25 and asks whether it would accept mail for that address (SMTP RCPT TO) without sending a message. It first asks about a random non-existent address to detect catch-all servers.
What do valid, risky and invalid mean?: Valid: the mail server accepted this exact address and does not accept random ones. Invalid: it will bounce or is a throwaway address. Risky: delivery could not be confirmed, for example a catch-all domain, a role address, Outlook or iCloud, or a server that would not answer. Only valid is a confirmation.
Why is an unconfirmed address risky and not valid?: Because calling it valid would be a guess. The code returns valid only when a server accepts the exact address and rejects a made-up one. Every other outcome is risky or invalid, so a valid result is never a hope.
What is catch-all confidence?: A higher, medium or lower likelihood label on rows that are risky because the domain accepts every address. It is built only from data we already have: whether the name format matches confirmed addresses on the same domain, guessed spellings of one name in the list, the format of the rest of the list, and placeholder and disposable flags. In our back-test on 82,853 addresses, higher-graded ones existed 69.0% of the time and lower-graded ones 1.4%. It opens no extra mail connection, never turns a row valid, and is not a per-row percentage.
How accurate is SimpleVerifier?: We do not publish an accuracy percentage because we have not measured one in a way anyone could reproduce. The method on this page is exactly what runs; the limits are listed above. When we run an independent, reproducible benchmark we will publish the method with the number.