Free Email Checker

What an email checker actually does

An email checker is a tool that verifies whether an address can receive mail before you try to send anything. The check runs five layers deep: syntax (does the address parse?), domain (does the domain exist?), MX records (is there a mail server?), SMTP handshake (will the server accept the address?), and risk classification (disposable, catch-all, role, spam-trap).

Most people only think about the first two. Syntax and domain checks catch typos like `jhon@gmial.com`, and that is useful, but it stops short of what receivers care about. A well-formed address at a real domain can still bounce because the mailbox does not exist, the user has been disabled, the inbox is over quota, or the address was a typo that happens to land at a real domain like `gmail.com`. The SMTP layer is where you find out.

Why checking emails before sending matters

Mailbox providers track your bounce rate. Send to a list with more than about 2% hard bounces and your domain reputation drops fast. Gmail starts dropping you into spam folders. Microsoft 365 begins outright rejecting your connections. Postmasters call this getting "throttled" or "soft-blocked" and digging out of it can take weeks of low-volume warm-up.

There are three practical reasons to run addresses through a checker before a campaign:

• You bought, scraped, or imported a list and have no recent engagement data.
• You collected addresses on a signup form without double opt-in and want to weed out typos before the welcome email.
• A list has been sitting unused for months. Email addresses decay at roughly 22% per year, so older lists need re-validation before reuse.

Catching bad addresses pre-send protects more than your bounce rate. Most spam filters also weigh how often your messages hit mailboxes that no longer exist. Cleaning the list keeps spam complaints down too: people who change addresses often mark forwarded mail as spam instead of unsubscribing.

The five checks under the hood

1. Syntax validation (RFC 5322)

First pass: does the address parse against RFC 5322? Most basic regex checkers fail here because RFC 5322 is more permissive than people expect. Quoted local-parts, plus-addressing, IP-literal domains, and comments are all valid syntax. Our Email Syntax Checker does this layer with bulk support if you want to isolate just the syntax pass.

2. Domain and MX lookup

The address parsed. Does the domain actually exist? A DNS lookup confirms the domain has been registered and resolves. A second MX record check confirms the domain has a mail server configured to receive mail. No MX records means no email delivery for that domain.

Some domains fall back to the A record when MX is missing, but most modern mail servers will refuse to deliver to a domain without explicit MX. If a domain has no MX and no A, the address is dead even before SMTP.

3. SMTP handshake

This is where verification gets real. The checker opens a TCP connection to the mail server, says hello with EHLO, declares a sender with MAIL FROM, then asks RCPT TO with the address being checked. The server responds with one of:

• `250 OK` — the mailbox accepts mail (or the domain is catch-all).
• `550` — the mailbox does not exist or is rejecting mail.
• `552` — quota exceeded, inbox full.
• `421` or `45x` — temporarily unavailable, try later (greylisting).
• Connection refused or timeout — the mail server is down or blocking.

No actual message is ever sent. The conversation ends with QUIT after RCPT TO. Receivers cannot tell whether you intend to send anything or were just checking, which is one reason some servers rate-limit or block too many probes from the same IP. Good checkers rotate sending IPs and back off when they see throttling.

4. Catch-all detection

A catch-all domain accepts every address. Send mail to `definitely-not-real-12345@example.com` and the server returns 250 OK even though no such mailbox exists. About 7-10% of business domains are configured this way, usually by accident through Google Workspace or Microsoft 365.

Detection works by sending RCPT TO for a randomly generated address that almost certainly does not exist. If the server says yes to that, it is going to say yes to everything. Catch-all addresses get flagged as risky because you genuinely cannot tell from SMTP alone whether the mailbox is real.

5. Risk classification

The address is accepted, but should you send? Risk classification flags:

• Disposable mailboxes — 10minutemail.com, mailinator, guerrillamail. The address works, but the person never sees the message.
• Role accounts — info@, admin@, no-reply@, sales@. These tend to have low engagement and high spam-complaint rates because multiple people read them.
• Known spam traps — addresses planted by anti-spam services to catch list scrapers. One hit can tank your sender reputation for months.
• Free providers with fast turnover — addresses at outlook.com and yahoo.com churn faster than corporate domains.

When a checker says "unknown"

Sometimes the SMTP server refuses to give a verdict. Gmail, Yahoo, and Microsoft all return 250 OK to almost every RCPT TO, then sort the spam afterwards. That makes mailbox-level verification at those domains effectively impossible through SMTP alone. Good checkers acknowledge this and return "unknown" or "accept-all" instead of pretending to know.

For Gmail and Outlook addresses, providers fall back to other signals: domain age, syntactic patterns that hint at typos, presence on known disposable lists, prior engagement data if available. Our verifier uses a two-engine fallback so addresses that one engine cannot resolve get re-checked through a second path before being marked unknown.

Free SMTP testers vs production-grade verification

Many free tools only run syntax + MX. They will tell you `jhon@gmail.com` is valid because Gmail accepts everything. They will not flag a disposable address. They will not detect catch-all. They will rarely run a real SMTP handshake at all, because doing so reliably requires sender IPs with clean reputations and the ability to rotate when blocked.

Valid Email Checker runs the full SMTP handshake through provider-grade infrastructure, falls back to a second engine when the first cannot return a verdict, and never charges for unknowns. The free version of the email verifier on this site uses the same engine paying customers do, capped at three checks per day per IP to keep the abuse rate low.

Pre-send checklist

Before any campaign, check both your list and your sending domain:

• Verify the list with an email checker. Remove hard bounces. Decide what to do with catch-all and role addresses based on segment.
• Confirm your SPF record authorises your sending IPs.
• Check that your DKIM record is published and the selector matches what your ESP signs with.
• Set a DMARC policy of at least `p=none` so you start receiving aggregate reports.
• Run the deliverability checker on your sending domain to verify everything resolves.

If you skip the list verification step, the authentication setup still matters but it cannot save you from a high bounce rate. A clean list and authenticated mail together are what get you to the inbox.

Bulk checking vs single address checking

Checking one address at a time is fine for sales workflows: a recruiter looks up a candidate, an SDR confirms a prospect, a freelancer verifies a client before sending an invoice. For lists over a few hundred addresses, single-checking through a UI is slow. Production setups use bulk verification with concurrency control, IP rotation, and retry on greylisting.

If you are doing more than a few dozen checks a day, switch to a CSV upload or API-based workflow. Single-address tools are not designed to handle hundreds of probes from the same IP without getting throttled by major mail providers.

What "valid" means and what it does not

A checker telling you an address is valid means the SMTP server accepted the RCPT TO command at the moment of the check. That is the strongest claim you can make about an address without actually sending mail. It does not mean:

• The address will accept mail an hour from now. Mailboxes get disabled, full, or deleted.
• The mailbox is monitored. Role accounts and abandoned addresses still accept mail.
• Your message will reach the inbox. Spam filters apply separately based on content, authentication, and reputation.
• The recipient will read it. Validity is plumbing, not engagement.

Verification is necessary but not sufficient. After cleaning the list, the next step is making sure the messages you do send pass authentication and do not look like spam. Tools like DMARC report analysis and header inspection help with the second half of the problem.