Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

SteveCove's avatar

Laravel 5.8 override email validation / use 5.7 rules

So i have just discovered that laravel 5.8 uses a new email validation rule, that is technically correct, but functionally useless for our app.

The short version is that someone@domainwithoputextension is technically a valid email:

https://github.com/laravel/ideas/issues/1555

So laravel 5.8 lets this through. Our app uses mailgun, which throws an exception when encountering these emails.

I realize we can create a custom validation rule, and update all our validators to use this instead, but then we have to remind all developers not to use the built in, familiar, documented 'email' validation rule, which feels wrong.

I would prefer to overwrite this new behavior, but am not sure where to start

0 likes
5 replies
Cronix's avatar
Cronix
Best Answer
Level 67

I'd look at binding a new class into the container. You can basically tell laravel "when this class is requested, give it this other class instead." So you can make a new "email" validation rule, and whenever laravel tries to load it it will load your custom class instead of the original. So one alteration and everybody can keep using the same terminology they have been.

$this->app->singleton(
    'Laravel\Spark\Contracts\Interactions\Settings\Profile\UpdateContactInformation',
    'App\Http\SparkExtensions\UpdateContactInformation'
);

Here's one where I'm substituting one of Laravel Sparks classes (the first one) with my own (2nd one) in the app service provider's register() method. So the first class would be the original laravel validation email rule and the 2nd one would be your custom rule class. You can just copy the old email rule if you want.

https://laravel.com/docs/5.8/container#binding

1 like
SteveCove's avatar

@JEKINNEY - thanks for your reply. My issue is with how to overwrite the built in email validation filter, to avoid having to document (and enforce) our own custom rule.

As a side note, this really should have come with a warning in the release notes for 5.8. Yes its technically valid, but i image the vast majority of users will not want this behavior.

2 likes
Chris1904's avatar

You can actually use the email:filter validation rule and it will then validate emails without TLD as "false" / invalid emails.

3 likes

Please or to participate in this conversation.