E-postvalidator

A free email validator that runs in your browser

This email validator checks whether an email address is formatted correctly and flags the addresses most likely to bounce — all without sending a single message and without uploading your list anywhere. Paste one address or thousands and each is checked instantly for valid syntax, common typos, disposable domains and role-based accounts.

There's no sign-up, no API key and no cost. It's a free email validator and email checker you can keep open in a tab and reach for whenever you need to validate an email address or clean a list before you import it into Mailchimp, HubSpot, Klaviyo or any other platform. Works on iPhone, Android, tablet and desktop.

What a valid email address looks like

A valid email address has a name (the local part) before the @, exactly one @ symbol, and a domain with at least one dot and a real top-level domain — for example name@example.com. The local part can include letters, numbers and a handful of symbols, but it can't start or end with a dot, contain a space, or have two dots in a row.

This email syntax checker follows those RFC 5322 rules and tells you exactly which one an address breaks, so bad@@example.com is rejected for having two @ symbols and john@company for missing a top-level domain — instead of a vague 'invalid'. Many basic HTML5 form validators only catch the most obvious cases; this tool applies the full rule set.

Single checks and bulk list cleaning

Use the field at the top to check an email address as you type, with a live verdict and the exact reason it passed or failed. Drop down to the bulk email validator to clean a whole list: paste it in or upload a CSV and every row gets its own verdict, with running counts of valid, risky and invalid addresses.

Export the results as a CSV or copy just the clean valid addresses back to your clipboard — useful before importing contacts into a newsletter, CRM or outreach tool, where every invalid address hurts your sender reputation and wastes send credits. Paid tools like ZeroBounce and NeverBounce do the same job but charge $0.008–$0.01 per address and require an account.

How this compares to ZeroBounce, NeverBounce and Hunter.io

ZeroBounce and NeverBounce are the leading paid email verification services. They offer real-time SMTP checks that can confirm whether a specific mailbox exists — something no browser-based tool can do. ZeroBounce charges around $0.008 per email ($16 for 2,000 addresses); NeverBounce is similar. Both require you to upload your list to their servers and create an account, which raises GDPR and CCPA data-transfer questions. Hunter.io includes email verification in its API at 50 free checks/month before paid plans start.

This tool covers the 90% of bad addresses you can catch without SMTP checks: typos, disposable services, role-based addresses, and syntax errors. For most use cases — cleaning a list before a Mailchimp import, checking addresses on a signup form, validating contacts before a cold outreach campaign — syntax and quality validation is enough. For high-volume senders who need SMTP-level guarantees, ZeroBounce or NeverBounce are worth the cost. For everyone else, free and private is the right starting point.

Catch typos, disposable and role-based addresses

Most bad addresses aren't exotic — they're a slipped finger. The validator spots common domain typos such as gmial.com, yahooo.com, hotmial.com and outlok.com and suggests the correct provider with a one-click fix.

It also flags disposable or temporary email addresses (mailinator.com, guerrillamail.com, 10minutemail and dozens more), role-based mailboxes like info@, support@ and admin@ that rarely belong to a real person, and whether a domain is a free provider or a custom/corporate one. For Gmail it shows the normalized address, because Gmail ignores dots and anything after a +, so john.doe+news@gmail.com and johndoe@gmail.com reach the same inbox.

Private by design — your list never leaves your device

Because this email validator runs entirely in your browser, the list you paste never leaves your device — it isn't uploaded, logged or sold, unlike server-based bulk email verifiers like ZeroBounce, NeverBounce, Hunter.io and Kickbox that require you to hand over your contacts. For customer lists subject to GDPR or CCPA, a local-only approach avoids creating any data-transfer record.

Bookmark it as your go-to email checker for quick syntax checks, typo fixes and bulk list cleaning — a fast, private alternative to paid services when you just need to know which addresses are worth keeping.

RFC 5321 and RFC 5322: what the specification actually allows

The authoritative rules for email address syntax come from two IETF documents: RFC 5321 (the Simple Mail Transfer Protocol) and RFC 5322 (the Internet Message Format). Together they define the local part — everything before the @ — as a sequence of characters drawn from letters, digits, and the symbols ! # $ % & ' * + / = ? ^ _ ` { | } ~ . -. Crucially, unescaped spaces and commas are forbidden, and dots may not appear at the very start or end, nor consecutively. The domain side follows DNS hostname rules: each label separated by dots can be up to 63 characters, must start and end with an alphanumeric character, and may contain hyphens in between.

The specifications also impose hard length limits: the local part is capped at 64 characters and the full address (local + @ + domain) may not exceed 254 characters. A lesser-known detail is that the local part is technically case-sensitive per the RFC — User@example.com and user@example.com are formally different addresses — though in practice virtually every mail server treats them as identical. These rules also permit some addresses that regex-heavy validators wrongly reject: a@b.io (single character on each side) is perfectly valid, as is user+tag@example.co.uk (plus-tagging), "very.unusual"@example.com (quoted local part allowing otherwise-illegal characters), and test@xn--nxasmq6b.com (an internationalized domain in Punycode). A robust validator respects the full specification rather than only the common happy path.

Where the specification leaves ambiguity is in internationalized email addresses defined later by RFC 6530 and RFC 6532, which permit Unicode characters in the local part (e.g., 用户@例子.广告). These addresses are valid in modern mail infrastructure that supports SMTPUTF8, but many legacy systems still reject them. Treating non-ASCII local parts as always invalid is technically incorrect; treating them as always safe is also incorrect. The pragmatic approach — and the one this tool takes — is to flag them as requiring careful handling rather than silently accepting or rejecting them.

Email deliverability: hard bounces, soft bounces and sender reputation

Validation matters most because of what bad addresses do to your sender reputation. When you send to an address that doesn't exist, the receiving mail server returns a hard bounce — a permanent failure with a 5xx SMTP error code, meaning the address will never accept mail. When a server temporarily refuses delivery (mailbox full, server overloaded, greylisted), you get a soft bounce — a 4xx error that your Email Service Provider (ESP) will retry for a period before giving up. Hard bounces are the more damaging signal: every ESP from Mailchimp to SendGrid to Klaviyo tracks your hard-bounce rate and starts throttling or suspending accounts once it climbs above 2–3%.

The mechanism behind the damage is IP reputation. ESPs send your email through shared or dedicated IP addresses. Internet service providers and anti-spam networks like Spamhaus, Barracuda and Microsoft's SNDS monitor how much mail from each IP results in bounces, spam complaints and trap hits. A high bounce rate signals that the sender either purchased lists, scraped addresses, or has poor list hygiene — all patterns associated with spammers. Once an IP or domain lands on a blacklist, legitimate emails start landing in spam folders or are rejected outright, and remediation can take weeks of sending low volumes from a clean list to rebuild trust.

The gold standard for ensuring addresses are both valid and genuinely owned is double opt-in: after a user submits their address, you send a confirmation email with a unique link, and the subscription only activates when they click it. Double opt-in eliminates typos that happen to form another real address, bot signups, and addresses entered by someone other than the inbox owner. Combined with syntax validation at the point of entry, it produces the cleanest possible list. Syntax validation and double opt-in are complementary — the former prevents wasting a confirmation send on an obviously malformed address; the latter confirms the deliverable address actually belongs to the person who typed it.

What email validation can and cannot detect

Syntax validation — the check this tool performs — can definitively catch malformed addresses: wrong character use, missing or multiple @ symbols, illegal dot placement, length violations, and domain format errors. A step up is MX record checking, which queries the domain's DNS records to confirm it has at least one Mail Exchange server configured, proving the domain exists and is set up to receive email. This eliminates addresses at domains that have been deleted or were never real. Neither of these checks requires sending a message or connecting to a mail server.

Going further, a SMTP connection check — the technique used by paid services — connects to the recipient's mail server and issues the RCPT TO command with the target address, then closes the connection before sending any message body. Many servers respond truthfully: they'll return a 250 OK if the mailbox exists or a 550 error if it doesn't. However, this approach runs into two significant limitations. Catch-all domains are configured to accept mail for any address at that domain, so every address appears valid even if most are fictional. Privacy-conscious providers including Google (Gmail) and Microsoft (Outlook) intentionally return 250 OK for all addresses regardless of whether they exist, to prevent address harvesting via SMTP probing. The result is that even SMTP checks cannot guarantee deliverability for these domains.

What no automated check can ever detect: whether the person who entered the address actually has access to it, whether the mailbox is monitored or a forgotten account, or whether the inbox is nearly full. Disposable and temporary email services like Mailinator, Guerrilla Mail, and 10MinuteMail deserve special mention — they generate syntactically valid addresses on real domains with functional MX records, so they pass syntax checks and MX checks alike. The only reliable way to block them is by maintaining a blocklist of known disposable domains, which this tool includes. For registration flows where real engagement matters — trials, newsletters, paid accounts — blocking disposable domains combined with double opt-in is the strongest practical defense.

Common email validation mistakes in web development

The most widespread mistake is the over-restrictive regex. Developers reach for a pattern that looks comprehensive but rejects legitimate addresses: blocking the + character breaks Gmail alias filtering (millions of users rely on user+label@gmail.com to sort incoming mail), rejecting subdomains blocks user@mail.company.com, and some patterns reject country-code TLDs longer than two characters or new gTLDs entirely. Jeff Atwood of Coding Horror documented this pattern famously — the conclusion is that the only regex worth using is one that checks basic structure, and the only way to truly verify an address is to send to it. This tool's pattern follows RFC 5322 closely enough to accept edge cases like a@b.io, user+tag@sub.domain.co.uk, and single-character local parts.

A frequently overlooked implementation detail is the maxlength attribute on email input fields. The RFC maximum is 254 characters, yet many forms hard-code a 50- or 100-character limit. Real corporate email addresses at large organizations — with long first names, last names, middle initials and long domain names — can legitimately approach or exceed 100 characters. Setting maxlength="254" on the input field is the correct implementation. Equally important is when you validate: triggering validation on keyup (as the user types) is aggressive and frustrating — the address is always 'invalid' mid-entry. Validating on blur (when the user leaves the field) or on form submission is the standard convention. The HTML type="email" attribute provides basic browser-level validation for free and should always be set; it doesn't replace a proper validator but catches the most obvious structural errors before JavaScript even runs.

A subtler mistake is conflating validation with verification in user-facing error messages. Telling a user 'this email address does not exist' when you've only checked syntax is both technically wrong and potentially confusing if they're entering a perfectly real address. The correct framing is 'this address doesn't appear to be formatted correctly' for syntax failures, and 'we've sent a confirmation email — please click the link to continue' for deliverability verification. The latter correctly communicates that you're using double opt-in rather than falsely claiming you know the mailbox state. Good error messaging, combined with format validation that accepts the full range of RFC-valid addresses, reduces signup friction while still catching the majority of mistakes.