Free email verifier: check syntax, MX records, disposable/role addresses, and live mailbox existence to see whether an email address is deliverable.
Paste one address, press Verify, and this tool reports back five separate checks plus a single verdict: deliverable, risky, undeliverable or unknown. It exists for the moment before a send — when you have a signup that looks like a typo, a lead that came in from a form, or a mailing list you inherited and do not trust. Bouncing hard on addresses that never existed is what damages a sending domain's reputation, and every bounce you catch beforehand is one your mail provider never sees.
The honest headline first: no verifier can guarantee that a message will be delivered without actually sending one. Anyone claiming 100% accuracy is either sending mail or overstating. What a verifier can do is separate the addresses that are definitely broken from the ones that are probably fine, and flag the ones nobody can resolve either way. That third category is real and this tool labels it rather than guessing.
Each verification returns the same five checks, shown as a pass, fail or neutral row. Neutral means the check could not be completed — it is not a quiet pass.
| Check | What it establishes | How much it proves |
|---|---|---|
| Valid syntax | The address is shaped like an address: a local part, an @, and a domain with at least one dot. | Cheap and certain. Catches name@gmail and name @example.com. Proves nothing about whether anyone reads it. |
| Domain accepts mail (MX) | The domain publishes MX records in DNS, so some mail server has been nominated to receive its mail. | A fail here is close to conclusive — no MX means no inbox. A pass only proves the domain accepts mail, not that your recipient exists. |
| Not a disposable address | The domain is not on a list of throwaway inbox providers. | List-based, so it is good on the well-known providers and blind to a domain registered this morning. |
| Not a role address | The local part is not a shared function mailbox — info@, support@, sales@, admin@ and similar. | Definitive about what the address is, not whether it works. Role addresses usually deliver fine; they are flagged because they are a marketing-list liability, not a technical fault. |
| Mailbox | Whether the receiving server acknowledges that specific mailbox. Reported as exists, not_found, catch_all or unverifiable. | The most valuable check and the least reliable one. See the section on catch-all domains and greylisting below. |
Alongside the checks you get up to three extras when they are available: the mail provider behind the domain, the method used to reach the mailbox verdict, and a suggestion if the domain looks like a near miss for a common one. The suggestion is clickable — if you typed name@gmial.com and it offers name@gmail.com, one click re-runs the whole verification against the corrected address rather than making you retype it.
The verdict is a single word. The confidence line underneath it tells you how much of the verdict is evidence and how much is inference, and it is the part most people skip.
| Verdict | Meaning | What to do with it |
|---|---|---|
| Deliverable | Syntax, DNS and the mailbox check all came back clean. | Send. This is as good as it gets short of sending. |
| Risky | Nothing is provably broken, but something warrants caution — a catch-all domain, a disposable provider, or a role mailbox. | Judgement call. Keep it for transactional mail, think twice before including it in a bulk campaign. |
| Undeliverable | Something failed outright: broken syntax, no MX records, or a mailbox the server rejected. | Remove it, or go back to the source and get it corrected. |
| Unknown | The checks did not produce enough signal to call it. | Retry later. A server that was refusing connections at that moment is a common cause. |
The confidence values map to how the mailbox verdict was reached:
verified — the mail provider confirmed the mailbox exists. The strongest result available.best_effort — inferred from the available signals rather than confirmed by the provider.mx_only — the domain accepts mail, but the mailbox itself could not be confirmed. Very common on providers that deliberately reveal nothing at the SMTP layer.none — not enough signal to assign a confidence level at all.A verdict of deliverable with confidence mx_only is a materially weaker claim than the same verdict with confidence verified. If you are deciding whether to keep an address on a list, read both.
Four things break mailbox-level verification, and all four are ordinary rather than exotic:
nonsense-string@company.com and it says yes. That is why the mailbox check reports catch_all as its own state rather than pretending it is a pass — on a catch-all domain, no external test can distinguish a real mailbox from an invented one.mx_only.Nothing here sends a message to the address you enter. The person who owns it receives no email, no notification and no test message as a result of your check.
The practical reason to verify is bounce protection. Mailbox providers score you on how much of your outbound traffic hits addresses that do not exist, and a list that has been sitting unused for a year or two decays quietly — people change jobs, domains lapse, free accounts get deleted. Sending to that list as-is is what turns a good sending reputation into a filtered one.
A workable order of operations before a campaign:
not_found are the two results you can act on without hesitation.One important limitation for this workflow: this tool checks one address at a time. There is no file upload, no paste-a-thousand-rows box and no CSV export. It is built for spot checks — the suspicious signup, the lead you are about to call, the address on a business card — not for processing a list of ten thousand. To keep the free tier usable for everyone, checks are rate limited to ten per minute from a single IP address; go past that and you will get a "rate limit reached" message and need to wait a minute.
If your interest is the DNS side rather than the mailbox — inspecting a domain's MX records themselves — the email validator and MX checker covers that ground.
Be clear about this one, because it matters if you are checking customer data. Mailbox verification cannot be done in a browser — a web page cannot open an SMTP connection to a mail server. So the address you type is sent to our server, which forwards it to the verification service that performs the DNS and mailbox checks, and passes the result back to you. The address leaves your machine. That is inherent to how mailbox verification works, not a design choice, and any tool that offers a mailbox verdict works the same way regardless of what its marketing says.
Practically: only the address itself is sent, nothing else from your session accompanies it, and the upstream response is filtered down to the documented fields before it reaches your browser. If you are working under a data-handling policy that forbids sending customer addresses to third parties, that policy applies here, and the answer is to run verification inside your own infrastructure instead.
| Message | Cause |
|---|---|
| That does not look like a valid email address | Rejected before any lookup: no @, no dot in the domain, whitespace or quote characters, or longer than 254 characters — the practical maximum length for an address. |
| Rate limit reached | More than ten checks in a minute from your IP. Wait sixty seconds. |
| Verification timed out | The upstream check exceeded its twelve-second budget, usually because the recipient's mail server was slow to answer. Retry; a second attempt often succeeds. |
| Temporarily unavailable | The verification service could not be reached. Nothing you can fix from your side — try again later. |
Will the person know I checked? No. No message is sent to the address.
It says deliverable but my mail bounced. The likely explanations are a catch-all domain that accepts everything at the SMTP layer and discards it later, a mailbox that filled up or was disabled between the check and the send, or a block on your sending domain specifically — which is a reputation problem, not an address problem. Read the bounce message; a hard bounce naming the recipient is different from a rejection naming your IP.
It says unknown for an address I know is real. That is greylisting or a provider that refuses to answer, and it is the expected result on a fair number of domains. Unknown means unproven, not invalid.
Should I delete every risky address? No. Risky covers catch-all domains and role mailboxes, and plenty of legitimate business contacts fall into both. Segment them rather than deleting them.
Validate entire lists or wire verification into your app with the pushmail.dev API.
It runs four layers of checks. First, syntax — is the address shaped correctly. Second, MX records — does the domain have mail servers configured in DNS to receive mail. Third, disposable and role detection — is it a throwaway provider or a shared address like info@ or support@. Fourth, a mailbox check that probes the mail server to see whether the specific mailbox exists, is not found, or sits behind a catch-all domain. The combined result is a single verdict: deliverable, risky, or undeliverable.
A syntax validator only confirms the address looks like name@domain.com. That catches typos but nothing else — a correctly formatted address can still bounce because the mailbox never existed. This tool adds DNS/MX lookups and a live mailbox check, so it tells you whether the address can actually receive mail, not just whether it is well-formed.
No. Verification never delivers an actual email. It uses syntax rules, DNS/MX lookups, and an SMTP-level handshake with the receiving server — the same conversation a sending mail server starts before delivery — but stops before any message is sent. The mailbox owner is not notified and receives nothing.
Risky means the address is technically accepted but uncertain. The most common cause is a catch-all domain, which is configured to accept mail for any address — so the server cannot confirm whether that specific mailbox truly exists. Role addresses (info@, sales@) and disposable providers are also flagged as risky. A risky result is not necessarily bad, but you should treat it with more caution than a confirmed deliverable address.
Sending to invalid addresses causes hard bounces, which hurt your sender reputation and can push your future mail into spam folders or get your domain throttled. Verifying at the point of capture — signup forms, checkouts, imported lists — keeps bounce rates low, protects deliverability, and stops fake or disposable signups from polluting your data.
This free tool verifies one address at a time. To validate entire lists in bulk or verify addresses programmatically inside your own signup flow or backend, use the pushmail.dev API, which exposes the same checks over a simple REST endpoint with an API key.