Guides

Last updated

July 20, 2025

5 Ways to Implement Email Validation in Yup

Nicolas Rios

Table of Contents:

ON THIS PAGE

Heading

Get your free

email validation

API key now

4.8 from 1,863 votes

See why the best developers build on Abstract

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

No credit card required

Ensuring email addresses are valid in Yup is a fundamental step for clean data. We'll walk through five different implementation methods, providing code for each. Then, we'll examine the common shortcomings of these techniques and introduce how Abstract API overcomes them for more reliable validation.

How to Implement Email Validation in Yup

Here are three common methods to validate email addresses with Yup. Each approach offers a different level of control and complexity for your data validation schemas.

The Built-in string().email() Method

The "email()" function attaches Yup’s default regex, which is the same pattern browsers use for an email input field. This method catches obvious formatting errors with no extra configuration, as shown in the npmjs.com documentation. Because the pattern is intentionally permissive, some invalid strings like “user@example.com..au” may pass.

The "email()" function also does not treat an empty string as invalid. To flag empty strings, you must also chain the "required()" function, a detail noted in a discussion on Lightrun.

Explicit Regex with matches()

The "matches()" function allows you to use any custom regular expression for validation. A tight pattern can enforce stricter rules, such as to forbid double dots, require a public suffix, or lock the domain to internal zones. If you need to allow optional emails without a separate "required()" call, you can use "excludeEmptyString", as suggested by the package documentation.

Delegation to validator.js with test()

You can delegate validation to an external library like "validator.js" through the "test()" function. The "validator.js" library provides a battle-tested implementation that follows RFC 5322 edge cases better than most ad-hoc regular expressions. The "test()" function receives the raw value and runs your predicate.

It can also reuse Yup’s interpolation system for the error message, a feature highlighted in a GitHub issue discussion. This approach combines the robustness of a specialized library with the declarative structure of Yup.

Challenges of Email Validation in Yup

While these methods offer basic checks, they present significant challenges. The limitations of regular expressions and local validation often lead to both false positives and false negatives, undermining data quality.

The built-in email method uses an outdated regex. It rejects valid but uncommon addresses with comments or international characters, and it accepts malformed strings with invisible characters or new top-level domains.
All local validation, including the built-in email and matches methods, only confirms the string's format. It cannot detect non-existent domains, temporary inboxes, or spam-trap addresses, which leads to subsequent delivery failures.
A custom regex with the matches method struggles with the full RFC grammar. Developers often write patterns that incorrectly block valid addresses that contain quotes or comments, which creates a poor user experience.
To tighten rules, one must write a custom test function or replace the regex. This approach adds maintenance costs and introduces inconsistencies if multiple services depend on the same shared validation schema.

Validate Emails with Abstract API

Implement strong email validation with Yup to ensure the quality and accuracy of user data.

Get started for free

How Abstract API Handles Email Validation in Yup

Abstract API addresses the core weaknesses of traditional validation methods through multi-layer checks that extend beyond simple syntax rules.

It performs multi-layer checks for syntax, typos, MX records, and SMTP responses, and it provides a risk score based on machine learning.
It provides a real-time deliverability flag and a numeric quality score to inform rejection or throttling logic.
It detects disposable, role-based, and catch-all email addresses so you can block or triage risky sign-ups.

How to Bring Abstract API to Your Dev Environment

Once you understand Abstract's capabilities, you can add its email validation API to your project with a simple process.

Install Yup and Axios with npm.
Create a free Abstract account and copy your Email Validation API key.
Add your ABSTRACT_KEY to a dot-env file or secret manager.
Write a helper function that calls the Abstract API endpoint with your key and the user's email.
Add an asynchronous Yup test that awaits the helper and checks for a "DELIVERABLE" status and a non-disposable address.
Use the schema in your controller or form. Yup will reject the promise if the API flags the address as risky.

Sample Email Validation Implementation with Abstract API

The code above defines a function, checkEmail, that sends a user's email to Abstract API. It returns "true" only if the API confirms the address is "DELIVERABLE" and not disposable. This function integrates into a Yup schema via the asynchronous .test method. This process layers real-time deliverability checks on top of Yup's standard syntax validation.

The API returns a detailed JSON object. Key fields like "deliverability" and "quality_score" tell you whether to accept, refuse, or flag an email. Other boolean flags for disposable, role-based, or catch-all addresses give you fine-grained control to filter sign-ups and protect your platform.

Final Thoughts

Traditional email validation often relies on syntax checks that approve undeliverable or temporary addresses. This method creates gaps for bad data and potential fraud.

Abstract API closes these gaps with real-time checks for deliverability and address type. For reliable user validation, create a free account on Abstract API and get your API key.

Frequently Asked Questions

What does Yup's built-in email() method actually check?

Yup's string().email() method validates email format using a permissive regex pattern that mirrors browser input validation. It catches obvious formatting errors but is intentionally lenient, which means it can accept malformed addresses like user@example.com..au and treats empty strings as valid unless you also chain .required().

How do I apply a stricter regex pattern for email validation in Yup?

Use Yup's matches() method to pass a custom regular expression, which lets you enforce rules such as forbidding double dots or restricting domains to an internal zone. You can also set the excludeEmptyString option to handle optional email fields cleanly without needing a separate required() call.

Can I use validator.js with Yup for RFC-compliant email validation?

Yes. You can wrap validator.js inside Yup's test() function to delegate the format check to a library that follows RFC 5322 more thoroughly than a hand-rolled regex. This gives you the reliability of a battle-tested external library while keeping Yup's declarative schema structure.

Why can't local Yup validation confirm whether an email address is real?

All local approaches (built-in email(), custom regex, or validator.js) only check syntax and cannot verify whether a domain exists, has valid MX records, or whether the inbox is active. This means a perfectly formatted address like nobody@fakeddomain.xyz passes every local check even though no mail will ever be delivered.

How do you integrate Abstract's Email Validation API into a Yup schema?

Add an async test() call to your schema that sends the value to Abstract's emailvalidation.abstractapi.com/v1 endpoint and returns true only when data.deliverability === 'DELIVERABLE' and data.is_disposable_email.value is false. This layers real deliverability checking on top of Yup's standard syntax validation with minimal extra code.

What extra signals does Abstract return beyond a pass/fail result?

The API response includes a quality_score, a deliverability flag, and boolean fields indicating whether the address is disposable, role-based, or a catch-all inbox. This granular data lets you apply different rules per use case: for example, blocking disposable addresses at sign-up while still allowing catch-all domains for B2B contact forms.