Email Validator

• Step 1: Type or paste an email address into the input field.

• Step 2: Click "Validate Email." The validator checks the email address against the rules of the email address specification and returns a result.

• Step 3: Read the result. A valid result confirms the email address has the correct format. An invalid result identifies the specific structural problem so you know exactly what to correct.

• Step 4: Fix and revalidate. If the address is invalid, correct the identified issue and validate again.

What this validator checks

The validator confirms that the email address follows the syntactic rules of the email address format as defined in RFC 5321 and RFC 5322. This includes verifying the presence and correct placement of the @ symbol, the validity of characters in the local part (before the @), the validity of the domain part (after the @), and the presence of a valid top-level domain.

What this validator does not check

This tool validates format and syntax only. It does not verify that the email address actually exists, that the mailbox is active, that the domain currently has a working mail server, or that the address has not been abandoned. Format validation confirms the address is structurally correct. Deliverability verification requires sending a test email or using a service that performs MX record lookups and SMTP handshake checks.

An email address has two main parts separated by a single @ symbol: local-part @ domain. Both parts must follow specific rules. Understanding these rules helps you interpret validation results and write correct email addresses from the start.

The Local Part (before the @)

The local part is everything to the left of the @ symbol. It can contain:

• Uppercase and lowercase letters (A through Z, a through z)

• Digits (0 through 9)

• The following special characters: dot (.), underscore (_), hyphen (-), plus (+), and a number of other special characters including ! # $ % & ' * / = ? ^ { | } ~

Rules for the local part:

• The local part cannot start or end with a dot (.)

• Two consecutive dots (..) are not permitted

• The local part is case-sensitive in theory (the email specification treats "User" and "user" as different addresses) but in practice almost all mail servers treat the local part as case-insensitive

• The local part can be a maximum of 64 characters

Valid local parts: john, john.doe, john_doe, john+newsletter, john123, j.d.123

Invalid local parts: .john (starts with dot), john. (ends with dot), john..doe (consecutive dots), john doe (space not allowed without quoting)

Quoted local parts

The email specification allows a quoted local part using double quotes, which permits characters that would otherwise be invalid, including spaces. For example: "john doe"@example.com is technically valid according to the specification. However, quoted local parts are rarely used in practice and many mail servers and applications do not handle them correctly. Most validators focus on the more common unquoted format.

The Domain Part (after the @)

The domain part is everything to the right of the @ symbol. It consists of labels separated by dots, where each label:

• Contains only letters, digits, and hyphens

• Does not start or end with a hyphen

• Is between 1 and 63 characters long

• The full domain cannot exceed 253 characters

The domain must end with a top-level domain (TLD): the final label after the last dot. Common TLDs include .com, .org, .net, .edu, .gov, and country-code TLDs like .uk, .de, .in, .pk, .ae.

Valid domains: gmail.com, company.co.uk, university.edu, example.io, subdomain.example.com

Invalid domains: example (no TLD), example..com (consecutive dots), -example.com (starts with hyphen), example-.com (ends with hyphen)

The @ symbol

There must be exactly one @ symbol in the email address. Zero @ symbols means no valid address. Two or more @ symbols makes the address invalid.

Complete email address length

The full email address (local part + @ + domain) cannot exceed 254 characters total according to RFC 5321.

• Missing @ symbol. The most basic error: the address contains no @ symbol. Sometimes caused by a user submitting a username rather than a full email address, or a copy-paste error that drops the @ character. Invalid: johndoeexample.com. Corrected: johndoe@example.com

• Multiple @ symbols. The address contains more than one @ character. This can happen when a user accidentally types the address twice separated by @, or when form auto-fill inserts the address into a field already containing partial text. Invalid: john@@example.com or john@doe@example.com. Corrected: john@example.com

• Spaces in the address. Standard email addresses cannot contain unquoted spaces. A space before or after the @ symbol, between characters in the local part, or within the domain makes the address invalid. Invalid: john doe@example.com or john@example .com. Corrected: john.doe@example.com

• Missing domain. The address has a local part and an @ symbol but no domain following it. Invalid: john@. Corrected: john@example.com

• Missing TLD (top-level domain). The domain exists but has no dot separator and TLD. Some validators accept addresses with IP addresses in the domain but most practical implementations require a recognizable domain format. Invalid: john@example. Corrected: john@example.com

• Consecutive dots. Two dots with nothing between them in the local part or domain. Invalid: john..doe@example.com or john@example..com. Corrected: john.doe@example.com

• Local part starting or ending with a dot. The local part cannot begin or end with a dot character. Invalid: .john@example.com or john.@example.com. Corrected: john@example.com

• Invalid characters. Characters not permitted in unquoted local parts (such as commas, parentheses, or angle brackets) make the address invalid. Invalid: john,doe@example.com or john(doe)@example.com. Corrected: john.doe@example.com

• Domain starting or ending with a hyphen. The labels within the domain cannot begin or end with a hyphen. Invalid: john@-example.com or john@example-.com. Corrected: john@example.com

This is the most important distinction for users of any email validator. Understanding the difference prevents misplaced confidence in validation results.

Format validation (what this tool does)

Format validation checks whether the email address string follows the syntactic rules of the email address specification. It is a purely structural check that happens instantly without any network requests. A format-valid email address is correctly structured: it has a properly formed local part, a single @ symbol, and a properly formed domain with a recognizable TLD structure.

Format validation confirms that:

• The string could be a legitimate email address

• It will not be immediately rejected by most form validation logic

• It is safe to attempt delivery to this address

Format validation does not confirm that:

• The domain actually exists on the internet

• The domain has an active mail server (MX record)

• The specific mailbox (local part) exists at that domain

• The address has ever been used

• The address is not currently bouncing

Deliverability checking (what this tool does not do)

Full email deliverability checking requires network operations: a DNS lookup to find the domain's MX records (mail exchange records that identify which server handles email for the domain), and optionally an SMTP connection to the mail server to verify the specific mailbox exists without actually sending a message.

These checks:

• Confirm the domain has an active mail server

• Catch domains that exist but have no email capability

• Catch some invalid mailboxes (servers that respond to SMTP verification)

• Are used by professional email verification services

However, deliverability checking has limitations too: many mail servers deliberately do not respond to SMTP verification to prevent email harvesting. A server may confirm a mailbox exists even when it bounces all messages. Temporary server issues can produce false negatives. These checks require server access and cannot be done in a browser.

Practical guidance

For most use cases including form validation, data entry verification, and quick format checks, format validation is exactly what is needed. If an address fails format validation, no further checks are needed: it is definitely wrong. If an address passes format validation, it is structurally correct and worth attempting delivery. The only way to definitively confirm deliverability is to send a test email with a confirmation link.

For developers and technically minded users, email validation appears in several contexts in web applications.

HTML5 browser-level validation

The HTML5 input type="email" attribute provides basic email format validation in the browser before form submission. The browser displays an error if the entered value does not match its internal email format check. This is convenient but browser implementations vary slightly in what they accept as valid.

JavaScript client-side validation

JavaScript email validation using regular expressions is common in web forms. Regular expressions for email validation range from simple (checking for @ and a dot) to extremely complex (attempting to match the full RFC 5322 specification). A commonly used moderate-complexity pattern that catches most invalid addresses:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

This pattern requires at least one non-space, non-@ character before the @, an @ symbol, at least one non-space, non-@ character as the domain, a dot, and at least one non-space, non-@ character as the TLD. It is not a full RFC 5322 implementation but it catches the vast majority of malformed addresses.

Server-side validation

Client-side validation is always complemented by server-side validation. A user can bypass browser-level and JavaScript validation by submitting data directly to the server endpoint. Server-side validation in languages like Python (using the email-validator library), PHP, Node.js, and others provides the authoritative check before the email address is stored or used.

Database storage

Email addresses stored in databases should be normalized to lowercase before storage (since most mail servers treat the local part as case-insensitive in practice, even though the specification allows case-sensitive local parts). The maximum storage length for an email address column should accommodate the 254-character RFC limit.

Email list hygiene

Marketing teams and email marketers regularly validate their mailing lists to remove invalid addresses before campaigns. Sending to invalid addresses increases bounce rates, which damages sender reputation with ISPs and email delivery services (Gmail, Outlook, Amazon SES). High bounce rates can lead to account suspension with email delivery providers.

These examples illustrate the range of valid email address formats that exist in the real world.

• Standard formats: john@example.com, john.doe@example.com, john_doe@example.com, john+newsletter@example.com, j.d.123@example.com, JOHN@example.com (uppercase, technically valid)

• Subdomains: john@mail.example.com, john@subdomain.company.co.uk

• International TLDs: john@example.co.uk, john@example.de, john@example.in, john@example.io, john@example.app, john@example.photography

• Numbers in domain: john@example123.com, john@123example.com

• Long TLDs: john@example.travel, john@example.technology, john@example.solutions

All of the above are format-valid email addresses. Whether mailboxes at these addresses actually exist and accept mail is a separate question that format validation alone cannot answer.

These examples illustrate common invalid formats with the specific reason each fails.

• john (no @ symbol, no domain)

• john@ (no domain after @)

• @example.com (no local part before @)

• john@example (no TLD)

• john @example.com (space before @)

• john@ example.com (space after @)

• .john@example.com (local part starts with dot)

• john.@example.com (local part ends with dot)

• john..doe@example.com (consecutive dots in local part)

• john@example..com (consecutive dots in domain)

• john@@example.com (two @ symbols)

• john@-example.com (domain label starts with hyphen)

• john doe@example.com (unquoted space in local part)

• john,doe@example.com (comma not permitted)

Thetoolity brings together a growing collection of free, fast, and clean online tools for developers, marketers, data analysts, and anyone who needs to verify email address formats quickly. Our email validator checks format and syntax instantly in your browser with no server requests, no data transmission, and no account required.

No accounts. No subscriptions. No cluttered interfaces. No data stored. Just a clean, instant email format check.

Explore the full collection at Thetoolity.com and find generators, converters, calculators, checkers, and testers, all free and all instant.