5 Ways to Implement Email Validation with Joi

Validating emails in Joi is a common step for maintaining data quality. We'll walk through five different implementation methods, complete with working code. Along the way, we'll look at the pitfalls of these traditional approaches and see how Abstract API helps overcome them.

How to Implement Email Validation in Joi

Joi offers several ways to validate email addresses. Here are four common methods, from basic syntax checks to custom rule creation, each with a corresponding code example.

Standard Joi Email Validation

The most direct method uses the “Joi.string().email()” chain. This approach employs the RFC-compliant parser from “@hapi/address” for syntax validation. It also checks the email's top-level domain against the IANA TLD list.

If a bundler removes this list, you might encounter a “Built-in TLD list disabled” error message. The Joi documentation provides more details on this function.

const schema = Joi.string().email();

Explicit TLD Configuration

You can specify which top-level domains to accept. The “tlds” option lets you define an “allow” list, such as “com” or “net”. Alternatively, you can set “tlds” to “false” to bypass this check entirely.

This is a documented workaround for bundler issues. The “minDomainSegments” option ensures an address has a minimum number of domain parts, like in “foo@bar.com”. The official API documentation has further examples.

const schema = Joi.string().email({  
  tlds: { allow: ['com', 'net', 'io'] },  
  minDomainSegments: 2
});

Refined Rules for Length, Unicode, and FQDNs

Joi allows for tighter control over validation rules. You can set “allowUnicode” to “false” to block non-ASCII characters, a common need for legacy systems. To enforce the 254-character limit on email addresses, set “ignoreLength” to “false”.

The “allowFullyQualified” option, when “true”, permits a trailing dot in the domain name. This can be useful for certain internal DNS workflows. More information is available on the Joi API page.

const schema = Joi.string().email({
  allowUnicode: false,
  ignoreLength: false,
  allowFullyQualified: true
});

Custom Rules with @hapi/address

For more advanced cases, you can build a custom rule. The “custom()” method lets you use “@hapi/address” directly. The “Address.analyzeEmail” function exposes the same validator Joi uses internally.

This setup lets you chain extra logic without a need to fork Joi. The Address module API explains this in greater detail.

const Address = require('@hapi/address');
const emailSchema = Joi.string().custom((value, helpers) => {
  const error = Address.analyzeEmail(value, { tlds: { allow: true } });
  if (error) return helpers.error('string.email', { value });
  return value;
});

Challenges of Joi Email Validation

While Joi provides several validation methods, they come with inherent limitations. These challenges range from incomplete standards support to the inability to confirm if an email address is actually functional.

• Joi only implements a subset of RFC 5322 and rejects legal UTF-8 characters in an address's local part. The standard Joi.string().email() method lacks an option to support newer international standards.
• International domain names require Punycode translation. Joi validates the raw string, so native-script domains fail unless pre-encoded. This forces extra logic around methods like Joi.string().email() to handle these cases correctly.
• The default Joi.string().email() rule does not require a top-level domain, so it accepts invalid addresses. To fix this, you must explicitly configure TLDs, which creates maintenance overhead for your validation schema.
• Joi only asserts syntax, not deliverability. An address that passes validation with any method may still be undeliverable. The library cannot check for provider policies or actual mailbox existence.