Why Validate Email Format at All?
A contact form, a sign-up screen or a newsletter subscription on a website all ask the user for an email address. If that address is mistyped — a missing letter, say, or a forgotten @ sign — the confirmation email, order update or password reset link never arrives. The user usually never notices, because the form displayed a "success" message. That is why checking whether an email address is at least syntactically valid before the data is saved is a basic part of any form or sign-up flow.
This check is not limited to end-user forms. A newsletter list or customer database fills up over time with records accumulated from exported files, legacy systems and manual entry. Reviewing that list before a bulk send, and weeding out the addresses that are at least broken in terms of format, is a useful first step — bearing in mind, of course, that it is no substitute for mailbox verification.
What Is RFC 5322?
RFC 5322 is the official standards document that defines the format of internet messages, email included. It describes which characters an email address may contain, how the local part is separated from the domain part, and which cases count as invalid. The full RFC 5322 grammar is extremely complex, however; it covers quoted local parts (such as "john doe"@example.com), comment blocks and many other rarely used exceptions. That is why almost every real-world implementation — form validators, email clients, backend libraries — implements not the full grammar but a simplified subset that works in practice.
The Syntax Rules of a Valid Email Address
In the simplified rule set used in practice, an address has to satisfy all of the following conditions to be considered valid:
- The address must contain exactly one
@sign; none at all, or more than one, is invalid. - The local part (the section before the
@sign) must not exceed 64 characters. - The domain part (the section after the
@sign) must contain at least one dot (e.g..com,.net) and must not exceed 255 characters. - The address must not contain two consecutive dots (
..). - The address must not start or end with a dot at the beginning or end of either the local part or the domain part.
- The address must contain only characters from the permitted set; anything outside letters, digits and certain special characters (
. ! # $ % & ' * + / = ? ^ _ ` { | } ~ -) counts as invalid.
These rules can be applied practically with a regex (regular expression). A check like this instantly catches the most common mistakes: the user forgetting the @, typing a double dot, or leaving the domain part empty.
Valid and Invalid Addresses by Example
| Address | Result | Why |
|---|---|---|
| first.last@company.com | Valid | Satisfies every syntax rule |
| firstlastcompany.com | Invalid | No <code>@</code> sign |
| first@company@company.com | Invalid | More than one <code>@</code> sign |
| first..last@company.com | Invalid | Contains two consecutive dots |
| .firstlast@company.com | Invalid | Starts with a dot |
| first@company | Invalid | No dot in the domain part |
A Correct Format Does Not Mean the Mailbox Exists
There is an important distinction not to be confused here: syntactic validation only checks whether the address obeys the spelling rules. It does not show that the address really exists, is active, or can receive messages. nobody-at-all@a-real-domain.com may be perfectly correct in terms of spelling, and that mailbox may never have existed. The only reliable way to confirm that an address actually works is to send a verification email to it and wait for the user to click the link. A format check does not replace that; it merely filters out the most common and most cheaply preventable errors in front of your forms.
The Most Common Typos: Single-Letter Domain Slips
Most of the mistakes users make when entering an email address are in fact syntactically valid but point at the wrong domain. Single-letter slips such as gmial.com instead of gmail.com, or hotmial.com instead of hotmail.com, are both common and hard to spot, because the form accepts these addresses as syntactically valid. A practical way to catch this class of error is to compare the entered domain against the domains of the well-known major providers (gmail.com, yahoo.com, hotmail.com, outlook.com, icloud.com, yandex.com and so on) and, when a close match turns up, offer the user a "did you mean" suggestion.
Privacy During Validation
A syntactic email validator only analyses the text entered against a set of rules; it sends no query to the address and never contacts a mail server. That makes it a safe, fast way to give instant feedback before the user has even submitted the form. Real mailbox verification is a separate matter, and it is normally handled by the email delivery infrastructure itself, through a click on a confirmation link.
This distinction matters especially for the developers designing the form: running the syntax check on the client side (as the user types) provides instant feedback without sending unnecessary requests to the server. The same check then has to be repeated on the server side, because client-side validation is trivially bypassed through the browser's developer tools. This two-layer approach — fast client-side feedback plus a mandatory server-side check — protects both the user experience and data integrity.
How to Check It in Practice
Checking email addresses by hand in a form or a data set wastes time and invites human error. For anyone who wants to check a single address quickly, see which rule was broken (length, a dot problem, a missing @ and so on) and get a suggestion for a likely typo, a simple validation tool is the most practical answer.