5 Ways to Implement Email Validation in Spring Boot

Validating email addresses in Spring Boot is fundamental for data quality and user account integrity. We will explore five different approaches, complete with code examples, to handle this task. We will also examine the pitfalls of these traditional methods and show how Abstract API offers a more robust solution.

How to Implement Email Validation in Spring Boot

Here are four common methods to validate email addresses in a Spring Boot application. Each approach uses different libraries and techniques to check for syntactically correct email addresses.

Hibernate-Validator's @Email Annotation

The simplest method uses the built-in @Email annotation. Add the spring-boot-starter-validation dependency to your project, which pulls in Hibernate-Validator. You can then apply the @Email annotation directly to a field within a Data Transfer Object (DTO).

Spring Boot automatically configures a MethodValidationPostProcessor. This bean ensures the constraint check occurs whenever the DTO is bound from a request or when a method marked with @Validated is called. The default implementation uses a permissive regular expression that accepts domains without a top-level domain, as some developers note.

public record SignupCmd(
    @Email(message = "Address syntax is wrong")
    String email
) {}

A Hardened Annotation with @Email and a Pattern

To enforce a stricter format, you can enhance the default @Email annotation with a regular expression. This ensures the domain part of the email contains at least one dot, which rejects addresses like "user@localhost". There are two ways to accomplish this.

With Hibernate-Validator 6.x or newer, you can override the default regex directly inside the annotation. Alternatively, you can create a custom composite annotation that combines @Email with a @Pattern check. This approach, also found on Stack Overflow, keeps the built-in local-part validation but adds the top-level domain guard.‍


// Option A: Override the default regex
@Email(regexp = ".+@.+\\..+", message = "Missing top-level domain")
String email;

// Option B: Compose a custom annotation
@Email
@Pattern(regexp = ".+@.+\\..+")
@ReportAsSingleViolation
public @interface StrictEmail {}

Custom ConstraintValidator with Apache Commons-Validator

For more advanced validation logic, you can delegate to the Apache Commons-Validator library. This requires the commons-validator dependency. The process involves the creation of a custom annotation and a corresponding validator class, a common pattern in Java validation.

First, define a new annotation, for example @ValidEmail, and link it to a validator class. This class implements Spring's ConstraintValidator interface. Inside the isValid method, you delegate the check to an instance of Apache's EmailValidator. The library follows RFC 822 specifications for its checks.

// 1. The custom annotation
@Target({FIELD})@Retention(RUNTIME)
@Constraint(validatedBy = CommonsEmailValidator.class)
public @interface ValidEmail {    
  String message() default "Bad email";    
  Class<?>[] groups() default {};    
  Class<? extends Payload>[] payload() default {};
}

// 2. The validator implementation
public class CommonsEmailValidator implements ConstraintValidator<ValidEmail, String> {    
  private static final EmailValidator DELEGATE = EmailValidator.getInstance(false);    

  public boolean isValid(String value, ConstraintValidatorContext ctx) {        
    return value == null || DELEGATE.isValid(value);    
  }
}

Active MX Record Lookup

This runtime technique verifies that a domain is configured to receive mail. The process first checks the email's syntax with Java's InternetAddress class. If the syntax is valid, it performs a DNS lookup for the domain's Mail Exchange (MX) records.

The presence of at least one MX record indicates the domain can accept email. This logic is typically encapsulated within a Spring @Service. Because this involves a network call, it is best to wrap the operation in a CompletableFuture or a Reactor type to avoid block of the request thread. Caches also help reduce redundant DNS queries.

// Example DNS lookup logic
// Assumes 'domain' is extracted from the email address
DirContext ctx = new InitialDirContext(env); // 'env' holds JNDI environment properties
Attributes mx = ctx.getAttributes("dns:/" + domain, new String[]{"MX"});
boolean hasMxRecord = mx.size() > 0;

Challenges with Traditional Email Validation

While these methods provide basic syntax checks, they introduce several problems. These issues range from overly permissive rules to an inability to handle international addresses or confirm an inbox actually exists.

• The default @Email annotation from Hibernate-Validator accepts addresses without a top-level domain. Developers often add extra @Pattern rules to compensate, which creates brittle and complex validation logic that is hard to maintain.
• Standard validators like @Email and Apache Commons-Validator are ASCII-centric. They fail to parse internationalized email addresses that contain non-Latin characters, which limits a service's ability to support a global user base without extra libraries.
• Attempts to cover all RFC-legal edge cases with a custom regex often fail. These complex patterns become unreadable and introduce the risk of Regular Expression Denial of Service (ReDoS) vulnerabilities, which can cripple an application.
• Syntax validation, even with an MX record lookup, cannot confirm an inbox exists. An address may pass all checks but belong to a disposable domain or a spam-filtered mailbox, which makes the validation unreliable for deliverability.