Email address regex: a practical JavaScript syntax check

An email address regex can catch a missing @ or a broken domain before a form is submitted. It cannot tell you whether a mailbox exists or whether the person entering the address can access it.

The first decision is which address formats your application supports. A short signup-form check can deliberately support common ASCII addresses, including plus tags, without claiming to recognize every address allowed by email standards. Make that scope explicit so an unsupported format is not mistaken for a nonexistent mailbox.

Quick answer

For an ASCII address screen, check the local part and domain separately. Reject empty dot-separated parts, enforce length limits, and require domain labels to start and end with a letter or digit. Used case-insensitively, a pattern such as [A-Z0-9._%+-]+@[A-Z0-9.-]+ does not do that: it can accept ari..lee@example.com and ari@-example.com.

The JavaScript function below implements one defined policy. A true result means only that the trimmed input passes that policy. Keep account verification as a separate state.

Choose the address formats you support

Email syntax includes more than the familiar name@example.com form. RFC 5322 permits quoted local parts, while SMTPUTF8 supports internationalized addresses. A regex that rejects those forms is enforcing a narrower application policy, not proving that the addresses are invalid everywhere.

This example accepts an unquoted ASCII local part and a domain with at least two ASCII labels. It excludes display names, address literals such as [127.0.0.1], single-label domains, quoted local parts, and Unicode characters. If your users need those formats, use a maintained parser and an explicit internationalization policy instead of extending this expression one exception at a time.

A practical regex example in JavaScript

The local-part expression permits letters, digits and the punctuation used in an unquoted dot-atom, including + and apostrophes. Dots must separate nonempty parts. Each domain label is limited to 63 characters and cannot start or end with a hyphen.

The function also limits the local part to 64 ASCII characters and the whole address to 254. These bounds fit the ordinary SMTP mailbox form within the SMTP length limits. Because this screen rejects non-ASCII input, character counts here also count bytes.

Save this as email-screen.mjs; it works as an ES module in Node.js or browser code:

export function screenAsciiEmail(value) {
  if (typeof value !== "string") return false;
  const email = value.trim();
  if (email.length > 254 || !/^[\x21-\x7E]+$/.test(email)) return false;

  const parts = email.split("@");
  if (parts.length !== 2) return false;
  const [local, domain] = parts;
  if (local.length > 64) return false;

  const dotAtom = /^[A-Za-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[A-Za-z0-9!#$%&'*+/=?^_`{|}~-]+)*$/;
  if (!dotAtom.test(local)) return false;

  const labels = domain.split(".");
  const domainLabel = /^[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?$/;
  return labels.length >= 2 && labels.every((label) => domainLabel.test(label));
}

For example:

• ari+billing@example.com, o'hara@example.com and ari@example.technology pass.
• .ari@example.com, ari..lee@example.com and ari.@example.com fail because of the local-part dots.
• ari@-example.com, ari@example-.com and ari@example..com fail because of the domain labels.
• ari@bücher.example and "ari lee"@example.com fail because they are outside this policy.

An ASCII IDN representation such as ari@xn--bcher-kva.example can pass the label checks. That does not validate the IDNA conversion or prove the domain exists. If you accept internationalized domain input, use a maintained IDNA implementation to validate and convert the domain before applying your ASCII policy. Unicode in the local part needs separate EAI/SMTPUTF8 support through your mail stack.

The function does not look up DNS, check a registered top-level domain list, or contact a mail server. Even a@b.c passes its format rules; whether the domain is usable is a different question.

Syntax checks also stop before the part of signup that sends a message and confirms access. MailSlurp provides test inboxes and APIs so you can exercise that flow repeatedly, inspect the received verification link, and assert the resulting account state.

Common regex mistakes

Blocking plus addressing

Keep ari+billing@example.com intact. Removing the tag changes the address the user supplied, and a blanket rejection prevents people from using addresses that their provider supports.

Treating long TLDs as invalid

Do not impose an old two-to-four-letter suffix rule. Validate label structure, then handle domain existence separately. A regex pass should not claim that the suffix is registered.

Skipping normalization

This function trims surrounding whitespace, but it does not return a normalized address. If you accept the input, retain and display the same trimmed value for confirmation and sending. Do not silently remove internal spaces, strip plus tags, or lowercase the local part. Domain handling and local-part semantics are different; see whether email addresses are case-sensitive.

Using regex as a fraud or deliverability system

A plausible-looking address can still be mistyped, unmonitored, shared, or unreachable. Likewise, a disposable-address policy is a business rule, not a syntax rule. Give these checks distinct results so users are not told that a well-formed address has invalid syntax.

A safer validation pipeline

Run the same supported-format policy on the frontend and backend. The frontend can offer immediate feedback; the backend must enforce the rule because a client can bypass the form.

After syntax, domain checks can identify DNS problems. A mail-routing lookup must account for SMTP's address-record fallback when no MX record exists, rather than treating every missing MX record as proof of failure. Even a successful DNS lookup or SMTP probe does not establish that the person entering the address controls the mailbox. SMTP defines the routing fallback, and the address verification guide covers the limits of checks made without sending a message.

For account access, send a verification challenge and mark the address verified only after the application validates the returned code or link. That demonstrates access at that point in time, not permanent ownership or guaranteed future delivery. Keep subsequent bounces and address changes separate from the original verification result.

How MailSlurp helps

Use a MailSlurp inbox as the address in an automated signup test. Submit the form, wait for the expected verification email, validate its link, complete the application action, and assert that the intended account is verified. A test that stops at receiving the email misses a broken link or an application that never changes the account state.

The email testing API implementation guide supplies a helper with explicit application adapters; the Playwright email testing guide covers browser integration. Add accepted and rejected address cases to your form tests as well, so a change to the syntax policy does not silently block supported users.

FAQ

What is the best regex for email validation?

Use a screen that matches your application's documented address formats. The function above is for unquoted ASCII addresses with multi-label domains. It deliberately does not implement every email address format.

Can regex verify whether an email address exists?

No. It evaluates the supplied string. DNS and SMTP checks add other signals, while a completed email challenge establishes access to the mailbox at the time of verification.

Should I validate email on the frontend or backend?

Both, with the same policy. Show useful feedback in the form, enforce the rule on the server, and keep syntax acceptance separate from successful account verification.