Skip to content

📧 Email Validator (Bulk)

Bulk-validate large lists of email addresses (one per line). Checks include RFC 5322 syntax, disposable domains (30+ services), role accounts (admin@, info@), duplicates and case-mismatch detection. CSV export.

100% Free No signup Browser-only 5 languages Dark mode

🔒 About Privacy (Important)

📖 Where people get stuck

Paste addresses one per line and it checks RFC 5322 format, disposable domains, role accounts, duplicates and case-only differences in one pass, entirely in the browser, with a CSV export of the valid ones. What can be judged here is whether the format is well-formed, not whether mail will arrivea great many perfectly formatted addresses are unreachable because someone left, a domain lapsed, or there was a typo. A browser cannot query MX records either.

Case What happens What to do
Trying to decide validity with a regular expression A regular expression that fully implements RFC 5322 runs to thousands of characters, because it must cover quoted local parts, comments and IP address literals. And even then it tells you nothing about deliverabilitya@b is well formed and does not exist. The failure in the other direction does more damage: over-strict validation rejects legitimate addresses — the plus sign in user+tag@example.com (the Gmail alias feature), long gTLDs such as .photography, internationalised domains, dots in the local part. The person rejected has no idea why, and simply leaves. Keep form validation at roughly one at sign with a dot after it. That catches only obvious typos, and that is enough: existence can only be established by sending a confirmation email, and if you are doing that, tightening the format check buys you nothing. The reasoning rests on an asymmetry — a legitimate address you wrongly rejected is a loss you will never see, whereas an invalid one you wrongly accepted is caught reliably when the confirmation fails to arrive. Start with the HTML type="email", which validates within sensible limits: it is looser than a hand-written regex, and it is correct.
Putting too much faith in the disposable-domain list Disposable mail domains multiply daily — some services register a domain and use it for a few hours — so every list is perpetually out of date, and not on the list does not mean not disposable. The problem runs the other way too: people use disposable addresses for legitimate reasons — a one-off enquiry, a signup where they want privacy, and the forwarding addresses officially provided by platforms, such as Apple Hide My Email and Firefox Relay. Those exist, deliver reliably, and are flagged as disposable by some lists. Treat a disposable match as a warning, not a rejection. That distinction matters more than anything else here: rejecting costs you legitimate prospects and privacy-conscious users. The right use of the signal is to change what happens next — excluding them from a marketing send to keep the bounce rate down, or detecting repeated free-trial signups — not to close the door. If you truly want only accounts that exist, requiring a click on a confirmation email — double opt-in — is the one reliable method: someone on a disposable address can still click, but at least you have established that they intend to receive it right now.
Case and formatting differences hide duplicates By specification the local part before the at sign is case-sensitiveTaro@example.com and taro@example.com are strictly different addresses. In practice, however, almost every mail server ignores case and both reach the same mailbox. The domain part is case-insensitive by specification too. That gap between the specification and reality is exactly where duplicates hide: register two rows differing only in case as separate people and the same person receives the same email twice. Gmail goes further, ignoring dots in the local part and everything after a +, so several visibly different addresses point at one mailbox. Lower-case before storing and before checking for duplicates. The specification says case matters, but implementations that honour it effectively do not exist, so treating addresses case-insensitively is the practical answer. Keep the original input for display and the user experience is unaffected. Whether to go as far as Gmail normalisation — stripping dots and everything after a + — depends on your purpose: it helps in detecting abuse, but overdone it risks treating two different people as one, since not every provider ignores dots. Put a UNIQUE constraint on the lower-cased column in the database — an application-level check alone lets duplicates through under concurrent requests.

What actually helps in pre-send cleaning is bounce management, not format checking. Even with perfect formatting, people leave, domains lapse, mailboxes fill and addresses are mistyped, and an unmaintained list loses twenty to thirty percent a year to those causes. Once your bounce rate passes five percent, your sending domain reputation falls and even legitimate mail starts landing in the spam folder — meaning the cost of continuing to send to invalid addresses is paid by the whole list, not just those addresses. What you need, therefore, is to narrow the entrance with double opt-in, remove hard bounces immediately, and periodically retire subscribers who neither open nor click. This tool exists to drop the obviously invalid ahead of time; it does not guarantee the quality of a list — that can only be built through operations. Note also that MX lookups are not possible from a browser, since it cannot query DNS directly; do it server-side if you need it.

📖 How to Use

  1. 1
    Paste the list
    Paste email addresses one per line into the textarea. Surrounding whitespace and quotes are trimmed automatically.
  2. 2
    Click Validate
    Runs RFC 5322 syntax, disposable-domain, role-account, duplicate and case-mismatch checks together.
  3. 3
    Export valid as CSV
    Use "Valid as CSV" to download only the rows judged valid. Handy for cleaning a list before email marketing.

❓ Frequently Asked Questions

How are disposable emails detected?
We match against a built-in list of 30+ major disposable domains (10minutemail, mailinator, tempmail, guerrillamail, yopmail, etc.). This is not exhaustive — commercial SaaS APIs have higher coverage.
Can you verify MX records?
No. Browsers cannot query DNS directly, so MX verification is out of scope. For that you need a server-side DNS API.
What is a role account?
Addresses like admin@, info@, support@, sales@ that map to a team rather than a person. Sending marketing in bulk to these often hurts deliverability, so we flag them as warnings.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.

* Browser info (UA / screen / language / URL) is sent automatically to help reproduce the issue