Email validation regex that will not reject real users (and what a regex cannot catch)

Use the pattern the HTML standard gives for email fields, tightened in three small ways. Then check the length: at most 254 characters, with at most 64 before the @. In our test of 33 forms, it rejected no real address and let no broken one through. No regex can tell a throwaway domain from a real one, so check the domain and then confirm the inbox.

/^(?!\.)(?!.*\.\.)[A-Za-z0-9.!#$%&'*+/=?^_`{|}~-]+(?<!\.)@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+[A-Za-z](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?$/

This page is for developers who add an email field to a signup, checkout or contact form. The pattern stops typos before they reach your database. Throwaway inboxes and dead domains need the two steps after it.

#Which email regex should you use?

Start from the HTML standard. Browsers run its rule for every <input type="email">. The standard calls that rule a willful violation of RFC 5322, whose syntax it finds too strict before the @ and too vague after it (WHATWG).

Its own pattern lets a few broken forms through, so ours adds three rules. The part before the @ may not start or end with a dot or hold two dots in a row, as RFC 5322 requires. The domain needs at least one dot, which RFC 3696 advises checking. The last label must start with a letter, as every top-level domain on IANA's list does.

Two length rules come from the mail standards. The part before the @ holds at most 64 characters (RFC 5321). The whole address holds at most 254, because the 256-octet SMTP path also carries two angle brackets (RFC 3696, erratum 1690).

We ran each pattern as its page publishes it on October 25, 2026, in Node.js 22, PHP 8.3 and Python 3.13. The real forms include plus tags, an apostrophe, capitals, 11- and 18-letter top-level domains and domains in punycode. The bad forms include a missing @, double dots, a space, a trailing line break and a 260-character address.

#Why do common email regexes reject real users?

The usual culprit is the ending. Many older patterns end in [a-zA-Z]{2,4}, because every top-level domain once had two, three or four letters (RFC 3696). Today more than half of them are longer or internationalized.

Even {2,} rejects 151 of them: the internationalized ones, which travel in punycode with digits and hyphens, such as xn--vermgensberatung-pwb. The longest plain top-level domain today is travelersinsurance, at 18 letters.

The other misses in our test were small and easy to copy. emailregex.com's HTML5 pattern holds a typographic apostrophe (’) where ' belongs, so it refused o'brien@example.com. Its RFC 5322 pattern uses lowercase letters only and refused capitals. Test any pattern you copy before you ship it.

#How do you validate an email address in JavaScript, Python and PHP?

1. Trim spaces and line breaks from the input, as browsers do for email fields (MDN).
2. Check the two lengths, then match the whole string against the pattern. In PHP, filter_var does both, and it passed the same test.
3. Ask the free FFraud API about the address. Refuse a throwaway inbox, and accept a relay such as Hide My Email.
4. Send a confirmation email, and activate the account only after the click.

const EMAIL = /^(?!\.)(?!.*\.\.)[A-Za-z0-9.!#$%&'*+/=?^_`{|}~-]+(?<!\.)@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+[A-Za-z](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?$/;

export function looksLikeEmail(input) {
  const email = input.trim();
  const at = email.lastIndexOf("@");
  return email.length <= 254 && at >= 1 && at <= 64 && EMAIL.test(email);
}

export async function checkEmail(input, timeoutMs = 2000) {
  const email = input.trim();
  if (!looksLikeEmail(email)) return { accept: false, why: "not an email address" };
  try {
    const res = await fetch("https://api.ffraud.com/public/email/check", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(timeoutMs),
    });
    if (!res.ok) return { accept: true, why: "check unavailable" };
    const r = await res.json();
    if (r.email_type === "temp") return { accept: false, why: "disposable domain" };
    return { accept: true, why: r.is_role_address ? "role address" : "ok" };
  } catch {
    return { accept: true, why: "check unavailable" };
  }
}

Each snippet refuses only an email_type of temp. The API answers alias for relay services such as Apple's Hide My Email, which forward to an inbox a real person reads, and our guide to relay addresses explains why most sites should accept them.

Each snippet waits 2 seconds for the API. If the API fails or times out, it accepts the address and leaves the decision to the confirmation email. We ran all three against the live API on October 26, 2026:

JavaScript, Node 22.19.0
  "test@mailinator.com"             refused   disposable domain
  "test@privaterelay.appleid.com"   accepted  ok
  "user@@example.com"               refused   not an email address
  " team@ffraud.com "               accepted  role address
  "test@mailinator.com"             accepted  check unavailable (timeout set to 1 ms)
Python 3.13.7
  "test@privaterelay.appleid.com"   accepted  ok
  "us..er@mailinator.com"           refused   not an email address
  " team@ffraud.com\n"              accepted  role address
PHP 8.3.25
  "test@privaterelay.appleid.com"   accepted  ok
  "o'brien@mailinator.com"          refused   disposable domain
  "user@example"                    refused   not an email address

The trailing line break trap

In PHP and Python, $ also matches just before a final line break. Our test caught it: preg_match without the D modifier and re.match with $ both accepted user@example.com followed by a line break. Use /D in PHP and re.fullmatch in Python, as the snippets do. JavaScript's $ matches only at the true end of the string.

#What does a regex let through?

Format is all a regex can judge. We ran every pattern on all 224,282 throwaway domains in FFraud's open list, as user@ plus the domain. The patterns accepted between 92.7 and 100 percent of them, and ours accepted 99.95 percent.

A pattern cannot see a misspelled provider or a domain that takes no mail either. The free API knows the throwaway domains on its list. It flags test@gmial.com, for example, because that domain is on the list:

curl https://api.ffraud.com/public/email/check \
  -H "Content-Type: application/json" \
  -d '{"email":"test@mailinator.com"}'

The API has one limit to know. It does not test whether a domain can receive mail: a made-up domain we tried came back as normal. The MX lookup shows where a domain's mail goes. With no MX record, senders fall back to the domain's own address (RFC 5321), and a null MX, which example.com publishes, says the domain accepts no mail (RFC 7505). Only an email sent to the address proves the inbox exists, as the PHP manual and Microsoft's guide both say.

#What should each answer do to the signup?

The fields behind these answers are valid_format, email_type, is_role_address, community_blacklisted and safe_domain (email check docs). email_type is temp for a throwaway inbox and alias for a relay, while is_disposable is true for both. Major providers such as Gmail and Outlook are never returned as disposable.

Any list can be wrong about one domain. Show a plain message that asks for another address and offers a way to reach you, rather than a silent block. Our guide to stopping fake signups puts these checks into a whole signup flow.

#How do you test your validator?

Run your pattern on forms like these before you ship it. They are the ones that told good patterns from bad ones in our test:

should pass                                should fail
user+tag@example.com                       userexample.com
o'brien@example.com                        user@@example.com
User.Name@Example.COM                      .user@example.com
user@mail.example.co.uk                    us..er@example.com
user@example.photography                   user@-example.com
user@example.travelersinsurance            user name@example.com
user@xn--bcher-kva.example                 user@example
user@example.xn--vermgensberatung-pwb      user@192.0.2.1
(64 letters)@example.com                   (65 letters)@example.com
                                           user@example.com + line break

Speed was no problem. On hostile inputs of 20,000 characters, no pattern took more than 0.4 milliseconds in Node.js 22, and the length check in front keeps every input short.

Our pattern rejects four rare forms that the RFCs allow: a Unicode domain, a Unicode local part, a quoted local part and an address literal such as user@[192.0.2.1]. RFC 3696 calls quoted forms rarely used, though it advises passing them to the mail system instead of rejecting them. Unicode addresses need a mail system with SMTPUTF8 (RFC 6531). In PHP, FILTER_FLAG_EMAIL_UNICODE accepts a Unicode local part.

#Questions people ask

To check one address by hand, paste it into the free email checker or the disposable email checker.