Validating emails with regex is a common way to ensure data quality. Here, we'll walk through five different methods, providing working code for each. We'll then look at the pitfalls of relying solely on regex and see how Abstract API offers a more comprehensive solution.
How to Implement Email Validation with Regex
These methods use regular expressions to validate email syntax. Each offers a different level of strictness, from a basic structural check to patterns that follow official internet standards.
Minimal Structural Filter
This pattern provides a fast, basic check suitable for front-end validation or pre-processing logs. It confirms the email has a local part, an @ symbol, and a domain part separated by a dot. This approach is dialect-agnostic and quickly weeds out obviously malformed entries, according to one analysis.
The code checks for one or more non-whitespace characters before and after the @ symbol, separated by a literal dot in the domain portion.
^[^\s@]+@[^\s@]+\.[^\s@]+$
HTML Standard ABNF Pattern
This regular expression matches the grammar that modern browsers apply to input fields with type="email". It is based on the HTML standard and provides a practical balance between strictness and real-world use.
The pattern accepts dot-atoms and DNS labels up to 63 characters long. However, it rejects more obscure formats like comments and quoted strings that are technically valid but rarely used.
/^[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])?)*$/
Near-RFC 5322 Pattern
For a more comprehensive syntax check, this pattern closely follows the official RFC 5322 specification. It is significantly more complex because it accounts for less common but valid email address formats. These formats include quoted local parts and IP addresses used as domain literals.
This powerful expression, which can expand to over 6 KB, is often packaged into validation libraries like Email::Valid. It offers one of the most thorough checks available through regex alone.
(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:\d{1,3}\.){3}\d{1,3}|IPv6:[0-9a-fA-F:.]+)\])
TLD-Whitelisted Pattern
This method enhances a standard regex by restricting the Top-Level Domain (TLD) to a specific list of approved domains. This approach helps reduce typos, such as ".cmo" instead of ".com", while the regex itself remains relatively small and efficient.
The list of valid TLDs is generated from the official IANA root zone database. According to a technical article, this pattern must be updated through a build step whenever new TLDs are introduced to remain effective.
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.(?:com|net|org|io|…)$
Challenges of Email Validation with Regex
While regex offers a quick way to check email syntax, it has significant limitations. These patterns cannot confirm deliverability and often struggle with the complexity and constant evolution of email standards.
- To fully follow RFC 5322, a regex must account for obscure formats like nested comments. This results in a massive, unreadable pattern that is difficult to review or modify, as seen with the near-RFC 5322 pattern.
- A regex only confirms text syntax. It cannot check DNS records. An address can pass a minimal structural filter but still bounce because the domain lacks MX records, which undermines the validation result.
- The TLD-whitelisted pattern requires constant updates. The list of valid domains changes whenever a new gTLD launches. This forces perpetual rebuilds of the pattern to prevent it from incorrectly reject valid emails.
- Complex patterns like the near-RFC 5322 version rely on heavy backtracking. At scale, this creates CPU hotspots and introduces security risks like Regular Expression Denial of Service (ReDoS), which forces a choice between accuracy and performance.
Validate Emails with Abstract API
Ensure the quality of your user data by implementing proper email validation from the start.
Get started for free
How Abstract API Handles Email Validation
Abstract API addresses the core weaknesses of traditional regex methods. It combines a fast syntax check with real-world deliverability verification.
- It provides typo autocorrection suggestions and a quality score from a machine-learning rank model.
- It performs real-time MX look-ups and SMTP handshakes to prove an address can receive mail.
- It cross-references addresses against constantly refreshed lists of disposable, free, role, and catch-all domains.
- Its risk model draws from over three billion historical validations and receives frequent data updates without any need for code changes.
How to Add Abstract API to Your Dev Environment
Once you know Abstract’s capabilities, you can add its email validation API to your project with ease.
- Sign up at Abstract API and copy your API key from the dashboard.
- Store the key as an environment variable, never hard-code it.
- Add an HTTP client to your project, like requests for Python or axios for Node.
- Write a wrapper function that sends a GET request to the API endpoint with your key and the email address.
- Parse the JSON response and check the deliverability and format fields before you accept the address.
- Optionally, gate the endpoint with a circuit breaker to handle API errors.
import os, requests
API_KEY = os.getenv("ABSTRACT_API_KEY")
email = "johnsmith@gmail.com"
resp = requests.get("https://emailvalidation.abstractapi.com/v1/",
params={"api_key": API_KEY, "email": email}, timeout=3)
data = resp.json()
if data["deliverability"] == "DELIVERABLE" and data["is_valid_format"]["value"]:
# accept user
pass
Sample Implementation with Abstract API
This Python code shows a basic request to the Abstract API email validation endpoint. It retrieves a stored API key, defines a target email, and uses the requests library to send a GET request. The request includes the API key and email as parameters. The code then checks if the response indicates the email is both deliverable and has a valid format before it proceeds. Below is a sample JSON response for a valid, deliverable address. The response provides a quality score and confirms the address is not disposable, a role account, or a catch-all.
{
"email": "johnsmith@gmail.com",
"autocorrect": "",
"deliverability": "DELIVERABLE",
"quality_score": 0.9,
"is_valid_format": { "value": true, "text": "TRUE" },
"is_free_email": { "value": true, "text": "TRUE" },
"is_disposable_email": { "value": false, "text": "FALSE" },
"is_role_email": { "value": false, "text": "FALSE" },
"is_catchall_email": { "value": false, "text": "FALSE" },
"is_mx_found": { "value": true, "text": "TRUE" },
"is_smtp_valid": { "value": true, "text": "TRUE" }
}
Final Thoughts
Regex alone cannot confirm if an email address actually exists, which leads to false positives. It also struggles with complex syntax rules, which creates false negatives. Abstract API solves these problems with a single call that verifies syntax and confirms real-world deliverability.
To reliably validate user emails, consider an account on Abstract API and get your free API key.
Validate Emails with Abstract API
Implement proper email validation to maintain clean user data and improve your email deliverability rates.
Get started for free
