email validationMust Be a Valid Email Address: Format Rules and Examples

When a form says your entry "must be a valid email address", it means the text doesn't match the email address format the form expects. Most of the time the cause is small: a space after the address, a missing @, a comma, or a domain without a dot. So what is a valid email address? In short, it's one local part, one @ and a domain, written without spaces.

So what is the email format, exactly? A valid address has:

• One local part (the part before the @), up to 64 characters.
• Exactly one @.
• A domain made of labels separated by dots, such as example.com. Most sign-up forms and mail services expect at least one dot.
• No spaces.
• Up to 254 characters in total, in practice.

"Valid" has three layers: what the email standards allow, what web forms built on the HTML standard accept, and what real mail providers and sites accept. They don't match exactly, and this guide shows where they differ. Keep one more thing in mind: an address can pass every format rule and still not exist.

This page covers only the format rules. For why bad syntax costs you leads and reputation, see the hidden cost of ignoring email syntax errors. For the ways to check whether an address works, see how to check if an email is valid.

The parts of an email address

Every email address format follows the same shape: local-part@domain (RFC 5322, section 3.4.1).

Take first.last@example.com:

Part	In the example	What it is
Local part	first.last	The mailbox name, chosen by the person or the organization
@	@	The separator between the two parts
Domain	example.com	The domain that receives mail for the address

How a company builds the local part from a person's name (first.last, flast and so on) is a different question. Our guide to company email formats covers it.

The rules for a valid email address format

What is a valid email format under the standards? These are the rules for the common, unquoted form of an address (RFC 5322, sections 3.2.3 and 3.4.1; RFC 5321, section 4.5.3.1):

1. Exactly one @ outside of quotes.
2. The local part is at most 64 octets (characters, for plain ASCII addresses).
3. The local part uses letters, digits and these characters: ! # $ % & ' * + - / = ? ^ _ ` { | } ~, plus dots. A dot can't come first or last, and two dots can't sit next to each other.
4. Each domain label (the parts between dots) uses letters, digits and hyphens, is at most 63 characters, and doesn't start or end with a hyphen.
5. The domain is at most 255 octets.
6. No spaces, except inside a quoted local part (see below).

If you're asking what is valid email format for a sign-up form, the short version is: rules 1 to 6, plus at least one dot in the domain, because most sites expect one.

Length limits: 64, 255 and why 254

You'll often read that an email address can be 320 characters long: 64 for the local part, 1 for the @ and 255 for the domain. The parts do have those limits, but the full address has a tighter one.

RFC 5321 limits the "path" that mail servers use to 256 octets, and that path includes the angle brackets around the address (< and >). Take those two away and the address itself tops out at 254 characters in practice. This is spelled out in an erratum to RFC 3696.

Quoted strings, comments and what to ignore

The standard also allows a local part in double quotes, which can then contain characters that are otherwise forbidden, such as "john..doe"@example.com (RFC 5322, section 3.2.4). Web forms built on the HTML standard reject quoted local parts, and most people never see one.

If you build forms or clean lists, you can treat quoted addresses as an edge case. Don't suggest them to users as a way around a form.

Case sensitivity

The domain is not case-sensitive: EXAMPLE.com and example.com are the same domain. The local part technically can be case-sensitive, but RFC 5321, section 2.4 discourages relying on that.

In practice, treat addresses as case-insensitive when you compare them, for example to find duplicates. When you store an address, keep what the user typed rather than lowercasing it, because the standard still allows a mail server to treat case as meaningful.

Valid and invalid examples

The table shows each address against two layers: the email standard (RFC 5322 and RFC 5321) and the HTML type="email" check that browsers use in forms. They disagree on a few rows, which is why one form accepts an address another rejects.

Address	Standard (RFC)	HTML type="email"	Why
first.last@example.com	Valid	Accepted	Local part, @, domain with a dot
user+tag@example.com	Valid	Accepted	+ is an allowed character
o'brien@example.com	Valid	Accepted	The apostrophe is an allowed character
user@sub.example.co.uk	Valid	Accepted	A domain can have several labels
@example.com	Invalid	Rejected	The local part is missing
user.example.com	Invalid	Rejected	There's no @
user@	Invalid	Rejected	The domain is missing
user@example	Valid	Accepted	Allowed for local hosts, but most sites and mail services expect a dot in the domain and reject it
user..name@example.com	Invalid	Accepted	Two dots in a row break the standard, but the HTML check allows them
.user@example.com	Invalid	Accepted	A leading dot breaks the standard, but the HTML check allows it
user name@example.com	Invalid	Rejected	Spaces aren't allowed outside quotes
user@-example.com	Invalid	Rejected	A domain label can't start with a hyphen
user@example..com	Invalid	Rejected	Empty domain label between two dots

Why a form says "must be a valid email address"

Seeing "email address must be valid" or "must be a valid email address" usually means one of these:

• A space before or after the address. This often comes from copying and pasting. Browsers' built-in email fields strip surrounding spaces (HTML standard), but many sites run their own check that rejects them. Delete any spaces and try again.
• Two addresses in one field, separated by a comma or semicolon. Most fields take one address. Enter just one.
• A missing @ or a missing dot in the domain, such as janeexample.com or jane@example. Add the missing part.
• A name added by autofill or a paste, such as Jane Doe <jane@example.com>. Keep only the address.
• A non-English letter in the local part, such as josé@example.com. Many forms don't accept these yet (see the next section).
• A typo in a real address, such as gmial.com. This one usually passes the format check, which is the problem: the address looks right but won't reach anyone. Our post on email syntax errors explains why these slip through.

If you build the form, the fix is mostly on your side: trim spaces before you check, and show a clear message that says what's wrong (for example "the address needs an @"). Our guide to real-time email validation at the point of capture covers sign-up forms in more detail.

Internationalized addresses (UTF-8)

RFC 6531 extends email so the local part can contain non-ASCII characters (josé@example.com) and the domain can be an internationalized domain name. Both sides have to support it: the sending and receiving servers negotiate it with an extension called SMTPUTF8.

Support is still uneven. Many forms, mailing tools and receiving servers reject these addresses, and the HTML type="email" check accepts only ASCII in the local part. MDN also notes known issues in the HTML standard with internationalized domain names. Before you accept or send to such addresses, check that your sending tool supports them.

What providers accept vs what the standard allows

The standard allows far more than most services accept. Quoted local parts, characters like { or |, and domains without a dot are all allowed on paper, and many sign-up forms will still turn them down.

Providers also apply their own rules on top of the format. For example, Gmail ignores dots in @gmail.com addresses, so first.last@gmail.com and firstlast@gmail.com reach the same inbox. On work or school accounts that use an organization's own domain, dots do matter (Google Help).

Plus tags (user+tag@example.com) are valid under the standard, but whether mail to them reaches the base mailbox depends on the provider. Check with yours before you rely on them.

If you build forms, a good rule of thumb is to accept what the HTML standard accepts and not reject addresses on a guess. An unusual address that follows the rules may be real.

Regex and type="email": simple vs strict

The easiest client-side check is the browser's own. Use an email input:

<input type="email" name="email" required>

Browsers check the value against the HTML standard's definition of a valid email address. The standard publishes that definition as a regular expression. Treat it as a starting point, not a verdict:

/^[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])?)*$/

The HTML standard calls this a "willful violation" of RFC 5322: it is deliberately simpler than the full email standard. In practice that means:

• It rejects quoted local parts such as "john..doe"@example.com.
• It rejects empty and hyphen-edged domain labels, such as user@example..com and user@-example.com, and labels longer than 63 characters.
• It accepts some addresses the standard doesn't, such as user..name@example.com and .user@example.com.
• It accepts domains without a dot, such as user@localhost.
• It doesn't check the 64- and 254-character length limits.

Client-side checks are a convenience for the user. Anyone can bypass them, so validate again on the server (MDN).

Avoid long "RFC-perfect" regexes. They're hard to read and maintain, and they still can't tell you whether an address works. No regex catches a typo like gmial.com, because it's a correctly formatted address.

Format valid is not the same as the mailbox exists

nobody-here@example.com passes every rule on this page, and mail sent to it can still bounce. A format check only tells you that an address is written correctly. It can't tell you whether the domain receives mail or whether the mailbox exists.

Other addresses are correctly formatted but still risky: a disposable email address often stops working after a short time, and on a catch-all domain the server accepts mail for any address, so a single mailbox can't be confirmed.

To find out whether a valid email address can actually receive mail, check it with the free email verifier. For the full set of methods, see how to check if an email is valid.

FAQ

What is a valid email address format? A local part, one @ and a domain, with no spaces, such as first.last@example.com. The local part is up to 64 characters, each domain label up to 63, and the whole address up to 254 in practice.

How long can an email address be? Up to 254 characters in practice. The local part can be up to 64 characters and the domain up to 255, but the mail server path limit of 256 octets includes two angle brackets, which leaves 254 for the address (RFC 5321, erratum 1690).

Can an email address have a plus sign, dots or underscores? Yes. +, _ and dots are all allowed in the local part. Dots can't come first, last or twice in a row under the standard. Whether a + tag reaches your main inbox depends on your provider.

Are email addresses case sensitive? The domain isn't. The local part technically can be, but the standard discourages relying on it, so in practice addresses are treated as case-insensitive.

Can an email address have two @ signs? Only inside a quoted local part, such as "john@doe"@example.com, which the standard allows. The HTML type="email" check rejects it, so in practice an address has exactly one @.

Can an email address use non-English letters? Yes, under RFC 6531, if both the sending and the receiving side support it. Many forms and mail tools don't yet, so such an address can be rejected or fail to deliver.

Does a valid format mean the email works? No. A correctly formatted address can still point to a mailbox that doesn't exist or a domain that doesn't receive mail. Only a check of the address itself can tell you that.

Check the address, not just the format

A correct format does not mean the mailbox exists. Check whether an address can receive mail with the free email verifier, no signup (5 free checks per hour).

Checking a whole list? Sign up for 200 free validations, no credit card needed.