ToolSura's email validator parses the address you paste, entirely inside your browser. Your address is never uploaded, it never leaves your device, and no server ever sees it, so nothing is logged and nothing can leak. An email address is what you use to reset a password, so pasting one into a stranger's free validator hands over that account's recovery key. No account, no signup, no upload.

Start with the concession, because it is the honest one. Plenty of free email validators genuinely do more: a server-side service can look up MX records, attempt an SMTP transaction, and report that the mailbox exists. This page cannot and will not pretend to. What it does is answer the narrower question exactly: can this string be parsed as an address under the grammar RFC 5322 defines, which is addr-spec = local-part "@" domain. RFC 5321 and RFC 5322 remain the current Standards Track documents (RFC 5322).

Key Takeaways

• Syntax is checkable in a browser. Deliverability is not. The verdict says which one you are getting.
• [email protected] is invalid. "john..doe"@example.com is valid. Same string, different quoting.
• RFC 5321 sets three limits: 64 octets local-part, 255 domain, 256 for the whole path.
• The regex in HTML's own <input type="email"> is, by the standard's admission, a willful violation of RFC 5322.
• Nothing here opens an SMTP connection, so nothing here can tell you a mailbox exists.

What This Tool Checks, and What It Cannot

Most tools called email validators answer one question and imply they answered another. Here is the line, drawn against the grammar rather than convenience.

Checked in the browser	Authority
One unquoted @, both halves non-empty	RFC 5322 §3.4.1
Local-part is dot-atom, quoted-string, or obs-local-part	RFC 5322 §3.2.3, §4.4
Every local-part character is atext	RFC 5322 §3.2.3
Quoted local-part is well formed	RFC 5322 §3.2.3
Domain is dot-atom or domain-literal ([192.0.2.1])	RFC 5322 §3.4.1
Local-part ≤ 64, domain ≤ 255, path ≤ 256 octets	RFC 5321 §4.5.3.1.1–.3
Each domain label ≤ 63 octets, domain ≤ 253	DNS label rules
Non-ASCII reported as EAI, not failure	RFC 6531

Not checked, not claimable in a browser	Why
Does the domain resolve?	Needs a DNS query. No browser API issues one.
Does the domain publish MX records?	Also DNS. RFC 5321 §5.1 defines it as a lookup.
Does the mailbox exist?	Needs an SMTP RCPT TO exchange on port 25.
Disposable, catch-all, role account?	Defined by the receiving server, not by the string.

The first table is exact and costs nothing to compute. The second requires handing your domain to a machine you did not choose.

The One Rule That Defines an Address

Every check here descends from a single production. RFC 5322 §3.4.1 writes it as addr-spec = local-part "@" domain, where local-part is a choice of three forms (dot-atom, quoted-string, or obs-local-part) and the domain is a dot-atom or a domain-literal (RFC 5322).

An address is not a pattern to memorise; it is two halves, with a fixed number of legal shapes on each side. Any validator that does not branch on the left-hand form gets quoted local-parts wrong.

The 2008 revision earns one sentence of authority: both were published in October 2008, RFC 5321 obsoleted RFC 2821, RFC 5322 obsoleted RFC 2822, and neither carries an Obsoleted by marker.

Which Characters a Local-Part May Contain

The permitted set is not a matter of taste, and worth copying rather than guessing. RFC 5322 §3.2.3 defines atext as the printable US-ASCII characters that are not specials:

atext           =   ALPHA / DIGIT /
                    "!" / "#" / "$" / "%" / "&" / "'" /
                    "*" / "+" / "-" / "/" / "=" / "?" /
                    "^" / "_" / "`" / "{" / "|" / "}" / "~"

atom            =   [CFWS] 1*atext [CFWS]
dot-atom-text   =   1*atext *("." 1*atext)

So jo!hn$%&'*+-/=?^_{}|[email protected]is legal, and that is because of the local-part, not the domain. A validator that names the offending character beats one returning a bare failure:contains a space at position 5andcontains an unescaped quote at position 2` send you to different fixes.

Note what dot-atom-text already forbids. Because every . must be followed by atext, the grammar rules out a leading dot, a trailing dot, and consecutive dots. The three classic false negatives fall out of the rule rather than needing a check of their own.

Dots, Quotes and Domain Literals

Here is the pair that separates a validator from a pattern. Take john..doe.

Input	Verdict	Why
[email protected]	Invalid	dot-atom-text requires atext after each dot.
"john..doe"@example.com	Valid	quoted-string is a separate production.
[email protected]	Invalid	1*atext cannot begin with a dot.
[email protected]	Invalid	Needs atext after the dot.
"john doe"@example.com	Valid	quoted-string.
[email protected]	Invalid	Bare IP is not a dot-atom.
john@[192.0.2.1]	Valid	domain-literal production.
user@[IPv6:2001:db8::1]	Valid	dtext runs from %d33–90 and %d94–126.

Same characters, same domain, same everything except the quotation marks. A naive character class cannot express this, because whether a dot is a separator depends on which production the local-part matched. RFC 5322 §3.2.3 says so directly: a quoted-string is treated as a unit, semantically identical to a single atom, which is why dots inside it stop being separators.

IETF agrees the real syntax is broader than everyday mail. RFC 3696 §3, on unusual characters different systems may treat differently, tells sending programs and programs evaluating address validity what to do with them (RFC 3696):

"sending programs (and programs evaluating address validity) must simply accept the strings and pass them on."

That is the right posture: reject what the grammar rejects, accept what it permits, and say which rule you applied.

The Length Limits: 64, 255 and 256

RFC 5321 states three limits, in three different subsections, and they are easy to conflate.

Limit	Octets	Section
Local-part (before @)	64	RFC 5321 §4.5.3.1.1
Domain name or number	255	RFC 5321 §4.5.3.1.2
Forward-path or reverse-path, with <, >, @	256	RFC 5321 §4.5.3.1.3

You will see "254 characters total" quoted constantly. It is derived, not quoted: 256 less two angle brackets. It appears nowhere in RFC 5321. Nor does the string 64 octets; that limit lives in §4.5.3.1.1, which states "the maximum total length of a user name or other local-part" (RFC 5321).

Report the count, not a bare rejection. "Local-part is 71 octets, over the 64-octet limit" tells a developer what to change; "invalid" does not. DNS has its own rules, each label 63 octets and the domain 253, stated separately so they are not mistaken for RFC 5321 limits.

A Syntax-Valid Address Is Not a Deliverable One

This is the distinction most free validators blur, and it deserves the bluntest form: a syntax-valid address is not a deliverable one. Syntax answers whether a string parses. Deliverability answers whether a message reaches a human. The second needs a network, and a browser cannot ask it.

RFC 5321 §5.1 defines the delivery path as a DNS operation followed by an SMTP transaction. The lookup "first attempts to locate an MX record associated with the name"; absent one, the address falls back to an implicit MX at the host itself; and if records exist but none are usable, the situation "MUST be reported as an error" (RFC 5321). After that comes the SMTP conversation, where a receiving server may accept RCPT TO for any address, reject on policy, or accept and drop the message.

A browser cannot issue a DNS query on port 53, and routing one through a third-party resolver would hand that third party the domain you are testing. That is not privacy against convenience: a deliverability checker can only work by sending your domain to a machine you did not choose. A syntax checker needs no such power, so declining it is a feature rather than a limitation.

MDN says the same of the one validator every browser ships, undercutting the tick: an <input type="email"> that checks out means "it is at least formatted correctly", and you "must verify the email address on the server side of any transaction in which the provided text may have any security implications" (MDN).

Why a Regular Expression Is Not a Validator

The regex every tutorial ships comes from the HTML standard, which is candid about it. The HTML Living Standard defines a valid address as a match against email = 1*( atext / "." ) "@" label *( "." label ), and states that "this requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users)" (WHATWG HTML).

The published pattern is:

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Read 1*( atext / "." ) and both failure directions appear in one line. Because . is an alternative inside the repetition, that ABNF accepts [email protected], which RFC 5322 rejects. Because there is no quoted-string branch, it rejects "john..doe"@example.com, which RFC 5322 accepts. It also excludes the bracket form and keeps the domain side ASCII-only, so john@[192.0.2.1] and every internationalised address fail. One pattern, two false negatives and two false positives, in a document that admits it is not the real grammar.

To see what a candidate expression actually accepts, test the regex in a scratchpad, and treat a passing regex as a filter rather than a decision.

Internationalized Addresses and SMTPUTF8

θσερ@example.com and 用户@例子.广告 are valid addresses. RFC 5322's atext is defined as printable US-ASCII, so any ASCII-only validator rejects them, including the one the HTML standard ships. RFC 6531, the Standards Track extension for SMTP transport of internationalised mail, makes them real: it negotiates an SMTPUTF8 parameter during the SMTP session (RFC 6531). That parameter is registered in the IANA mail parameters registry (IANA).

Delivery still depends on both mail servers advertising it, and a great many do not. So this page returns a third verdict rather than folding these into pass or fail: valid syntax, delivery requires SMTPUTF8 at both ends. Almost every competitor answers "invalid", reporting a browser limitation as a malformed address. MDN documents the underlying specification issue as open.

For the domain half, internationalised domains appear on the wire in punycode form, with an xn-- prefix on each encoded label. This page flags that shape without decoding the display form.

What This Tool Deliberately Does Not Do

Three checks commercial validators advertise are absent here, each for a structural reason, not an oversight.

• Disposable-address detection. A throwaway domain is a fact about a business model, not about the syntax of a string. Recognising one needs a maintained corpus.
• Catch-all and role-account detection. A domain that accepts mail for every local-part is defined by the receiving server's configuration. Only the server can tell you.
• Typo suggestions. Suggesting gmial.com should be gmail.com needs a corpus of real domains. Edit distance alone yields confident nonsense.

You will also notice no green tick labelled "deliverable", because there is no honest way to render one. The verdict reads as a syntax result with the specific rule named, and the caveat travels with it.

Validating a List of Addresses in Bulk

The single-address case and the list case need the same rules applied per line. Paste a column separated by newlines or commas, and each entry gets its own verdict and reason string, so one bad row in a migration export does not hide behind an aggregate pass.

This is where a syntax check earns its keep. Import jobs routinely die on a single address with a trailing space, a smart quote pasted out of a word processor, or a local-part three octets over the limit, and they usually die late. Screening the column first names the failures before the transaction rather than after. Leading and trailing whitespace is flagged rather than silently stripped, since a pasted space is the commonest cause of a rejection that looks inexplicable.

If the addresses arrive inside a JSON payload rather than a text column, format and validate the JSON first, then screen the values that come out.

Related Tools

• the UUID validator makes the same argument for identifiers: format-valid is not authentic. Email syntax-valid is not email deliverable, and both tools stop at the same line on purpose.
• the regex tester shows you what a candidate email pattern actually accepts, before you put it in front of users.
• the email template tester is the next step once addresses are clean: check how the message renders.

A Six-Question Checklist

Before an address enters your system, six questions decide whether the verdict you are about to act on is right.

1. Does the local-part match dot-atom-text, or is it a well-formed quoted-string?
2. Is there exactly one unquoted @, with both halves non-empty?
3. Is the local-part 64 octets or fewer, and the domain 255 or fewer?
4. Is every domain label 63 octets or fewer?
5. Is the domain a dot-atom, or a domain-literal such as [192.0.2.1]?
6. Have you recorded the verdict as a syntax result rather than a delivery result?

Six clean passes mean the string parses. Nothing more. The seventh question, whether this mailbox receives mail, is not one a browser can answer, and any tool that claims otherwise is telling you it has your domain.