5 Ways to Implement Email Validation in Laravel

Ensuring email addresses are valid is a key part of maintaining data integrity in any Laravel application. We will walk through four native validation techniques, complete with code snippets, before highlighting their shortcomings and demonstrating how Abstract API provides a more robust solution.

How to Implement Email Validation in Laravel

Laravel offers several built-in methods to confirm email address validity. Here are four common approaches, from basic syntax checks to more advanced, custom rule creation for your application.

The Baseline Rule

Laravel includes a default "email" validation rule. This rule uses the `Egulias\EmailValidator` library to perform its checks. By default, it validates the email's syntax against the RFC 5322 standard. This process confirms the format is correct but does not check for deliverability.

$request->validate([
    'email' => ['required', 'string', 'email'],
]);

The Parameterized Rule

You can enhance the basic "email" rule with specific parameters. These parameters are added as a colon-separated string. They allow for more rigorous checks beyond simple syntax validation.

Egulias runs these checks sequentially. The available flags include:

• "rfc" or "strict": These flags switch between different levels of RFC compliance validation.
• "dns": This check looks for a domain's MX record. It requires the PHP "intl" extension to function.
• "spoof": This detects potential Unicode homograph attacks and also depends on the "intl" extension.
• "filter" or "filter_unicode": These options use PHP’s native "filter_var()" function as a fallback.

$request->validate([
    'email' => 'required|email:strict,dns,spoof',
]);

The Fluent Builder

Starting with Laravel 11.38, a fluent interface for the email rule is available. This approach uses the "Rule::email()" method to construct a typed validation object. It improves code readability and makes the developer's intent explicit.

This method also helps prevent common errors from string parsing. The fluent methods correspond directly to the parameterized flags, as noted in a Laravel News update. For example, "validateMxRecord()" is the same as the "dns" flag.

use Illuminate\Validation\Rule;

$request->validate([
    'email' => [
        'required',
        Rule::email()
            ->rfcCompliant(strict: true)
            ->validateMxRecord()
            ->preventSpoofing(),
    ],
]);

A Custom Rule

For more control, you can create a custom validation rule. This involves a new class that implements Laravel's "Rule" contract. This gives you the flexibility to define your own validation logic.

The "passes" method contains the core logic. It first uses `Egulias\EmailValidator` for a syntax check. If that passes, it checks for the domain's MX record. The "message" method defines the error text. You then use the rule by instantiating it in your validation array.

use Egulias\EmailValidator\EmailValidator;
use Egulias\EmailValidator\Validation\RFCValidation;

class DeliverableEmail implements \Illuminate\Contracts\Validation\Rule {
    public function passes($attr, $value) {
        $v = new EmailValidator;
        if (! $v->isValid($value, new RFCValidation)) {
            return false;
        }
        [,$domain] = explode('@', $value, 2);
        return checkdnsrr($domain, 'MX');
    }
    public function message() {
        return 'Address is not deliverable.';
    }
}

The Challenges of Native Laravel Email Validation

Laravel's built-in validation methods, while convenient, introduce significant drawbacks. These issues can compromise data quality, application performance, and the overall reliability of your email verification process.

• The baseline email:rfc rule accepts syntactically valid but undeliverable addresses. This includes emails with spaces or comments, which most mail providers reject, so you collect useless data.
• The email:dns flag adds latency with a blocking DNS lookup on every request. A known bug also accepts any A record, which creates false positives for domains without MX records.
• Native methods lack full Unicode support. Both filter_var and the default validator fail to parse valid international addresses with non-ASCII characters unless you implement custom punycode logic yourself.
• Validation behavior often differs between local and production environments. Discrepancies in database collation, PHP versions, or DNS resolvers can cause authentication failures and bugs that are difficult to reproduce.