Skip to content
Arcjet Docs

Arcjet email validation

Arcjet allows you validate & verify an email address. This is useful for preventing users from signing up with fake email addresses and can significantly reduce the amount of spam or fraudulent accounts.

What is Arcjet? Arcjet helps developers protect their apps in just a few lines of code. Bot detection. Rate limiting. Email validation. Attack protection. Data redaction. A developer-first approach to security.

Step 1: Validation

The first step is to validate the email address syntax. This runs locally within the SDK and validates the email address is in the correct format. Validation is performed against several RFCs with modifications to exclude email addresses you wouldn’t expect signing up to a real application e.g. local domains.

Two of the validation options are configurable: whether 2 parts of the domain are required (defaults to being required) and whether domain literals in the form of example@[127.0.0.1] are allowed (defaults to not being allowed). Configuring these is described within the SDK documentation.

Internally, validation is implemented using the open source email_address Crate.

Validation errors

If an email address fails validation, one of the following errors will be provided:

Configurable

  • MissingTopLevelDomain: The email address didn’t contain at least 2 domain segments — it must contain at least the domain name and TLD.
  • InvalidDomainLiteral: Domain literals (e.g. foo@[123.456.789.0]) are not supported but one was provided.

Non-configurable

  • MissingSeparator: The @ character was missing between the local part and domain.
  • InvalidCharacter: The email address contained an invalid character.
  • LocalPartEmpty: The local part of the email address must contain at least 1 character.
  • LocalPartTooLong The local part has a max-length of 64 characters, as per RFC3696
  • DomainEmpty: The domain of the email address must contain at least 1 character.
  • DomainTooLong: The domain has a max-length of 254 characters, as per RFC3696 errata 1690
  • SubDomainEmpty One or more domain segments, separated by the . character, are empty.
  • SubDomainTooLong One or more domain segments, separated by the . character, are longer than 63 characters, as per RFC1034

Step 2: Verification

If the email syntax is valid, the SDK will pass the email address to the Arcjet cloud API to verify the email address. This performs several checks:

  • MX validation: Checks if the domain has valid MX records.
  • Email type: Checks if the email address is a free, disposable or role-based email address.
  • Has Gravatar: Checks if the email address has a Gravatar image associated with it. This is useful for checking if the email address is a real person.

This metadata is returned as part of the Arcjet SDK response so you can decide what to do next. For example, you might decide to block signups from domains without MX records and from disposable email addresses, but add a flag to manually review those from free email providers.

Email types

The Arcjet SDK will provide an analysis of the email type, returning one or several of the following:

  • Disposable: The email address is disposable, which means it’s registered to a service that allows throwaway email addresses. Although these are sometimes used for privacy, they are also often used for spam signups or fraudulent activity when combined with a transaction e.g. attempting to use a credit card. We recommend blocking these in higher risk scenarios.
  • Free: The email address is registered to a free email service. These are very common, such as GMail or Yahoo Mail, so we do not recommend blocking these. However, you may wish to flag these for review the first time they attempt a transaction.
  • No MX records: This email address is registered to a domain name which has no MX records configured. This means it cannot receive email. We recommend blocking these.
  • No Gravatar: This email has no Gravatar attached to the email from which makes it slightly less likely to be a valid signup. This can be used for your own risk scoring or to trigger a manual review.

RFC reference

The email validation stage considers the following RFCs:

  1. RFC 1123: Requirements for Internet Hosts — Application and Support, IETF, Oct 1989.
  2. RFC 3629: UTF-8, a transformation format of ISO 10646, IETF, Nov 2003.
  3. RFC 3696: Application Techniques for Checking and Transformation of Names, IETF, Feb 2004.
  4. RFC 4291: IP Version 6 Addressing Architecture, IETF, Feb 2006.
  5. RFC 5234: Augmented BNF for Syntax Specifications: ABNF, IETF, Jan 2008.
  6. RFC 5321: Simple Mail Transfer Protocol, IETF, Oct 2008.
  7. RFC 5322: Internet Message Format, I ETF, Oct 2008.
  8. RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework, IETF, Aug 2010.
  9. RFC 6531: SMTP Extension for Internationalized Email, IETF, Feb 2012.
  10. RFC 6532: Internationalized Email Headers, IETF, Feb 2012.

Discussion