Validating Email Addresses in Laravel

When a Laravel endpoint accepts an email address, the built-in email rule checks whether the address follows a chosen format. You can also check DNS, the Domain Name System, for a mail-exchange record. That record tells other mail servers where to send mail for the domain.

Those checks do not prove that a particular mailbox exists, that the person submitting the address can access it, or that a message will arrive. External verification services check other details about the address. Laravel’s email-verification feature asks the user to follow a link sent to the address. Choose a check based on the question your code needs to answer.

Use Laravel rules for format and domain checks

Laravel 13’s email rule uses the egulias/email-validator package. By default, it checks the address structure against Internet standards published as RFCs. You can select other checks by adding options to the rule, as described in the Laravel validation documentation.

For example, this rule requires a value and checks its format and domain:

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

Here, required checks that the field has a value. rfc applies the address-structure check, and dns looks up the domain’s mail-exchange (MX) record through DNS. Laravel documents that the dns and spoof checks require PHP’s intl extension.

You can add strict to reject certain syntax warnings, including trailing periods and consecutive periods. The spoof option checks for deceptive Unicode characters that resemble other characters. Laravel also offers filter and filter_unicode, which use PHP’s native email filter with different Unicode handling. These options evaluate the address; whether someone can receive mail there remains unconfirmed.

Know what each check establishes

Each check answers a different question. A format check looks at the address structure. A DNS check looks at the domain’s mail-routing information. Neither checks whether a specific mailbox exists.

Email syntax and mail delivery are related but separate. RFC 5322 describes Internet message format, including address syntax. Laravel’s syntax checks examine that structure. Its DNS option checks a mail-routing record for the domain. Neither result guarantees that mail will arrive.

External services assess additional signals

An external email-verification service can check details beyond Laravel’s built-in rules. The checks vary by provider. For example, Amazon SES documents checks for syntax, DNS records, mailbox existence, role addresses such as admin@ or support@, disposable domains, and random-looking input. It returns high, medium, or low confidence verdicts for its evaluations.

Those verdicts show how confident the service is in its assessment. They do not guarantee that a message will arrive or that a specific person owns the address. If you use an external service, read which checks the provider documents and follow its stated limits when interpreting the results. Laravel’s dns option remains narrower: it checks the domain’s MX record and does not determine whether an individual mailbox exists.

Use a verification link to confirm access

To confirm that someone can access the submitted address, send a verification link and require the user to follow it. Laravel’s email verification feature handles this workflow through its verification contract and route. After successful verification, Laravel stores a timestamp in the user’s email_verified_at field.

This shows that someone who could receive the message followed the link at that time. It does not prove the person’s identity or guarantee delivery of future messages. Keep this step separate from input validation: use the email rule to reject unacceptable formats, and use the verification link to confirm access.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com