DEV Community


Laravel validation rule — fake email

mattkingshott profile image Matt Kingshott 👨🏻‍💻 Originally published at Medium on ・3 min read

Image courtesy of Unsplash

Laravel validation rule — fake email

In this new series, we’ll be exploring the concept of custom validation rules in Laravel and why you’ll want to use them. I’m aiming to release a new article each day containing a new rule which you can use in your own projects. I’m also collecting these rules into a package that you can pull in via composer.

In this article, we’ll be confirming that the user has provided an email address that is not fake / disposable (in other words, a real email address).


If you’re unfamiliar with the reasoning behind creating custom rules to handle data validation, check out the intro section from the first article in this series.

You may also want to review the section on creating a rule (in the same post), as we won’t be repeating the mechanics of each method in your validation classes, we’ll just be exploring the code required to make the rule work.


I’ve recently released Pulse — a friendly, affordable server and site monitoring service designed specifically for developers. It includes all the usual hardware monitors, custom service monitors, alerting via various notification channels, logs, as well as full API support. Take a look…

Server & Site Monitoring with Pulse

The check and response

First of all, it’s important to note that unlike other validation rules, verifying that an email address is genuine isn’t entirely possible. However, we can take steps to make it considerably more difficult to use a fake email address.

Obviously, we’ll need a list of disposable domains to make the rule work. We could periodically download and cache such a list, however, a much better option is to use an API. Fortunately, such an API exists on Kickbox and better still, it doesn’t require an API key to use!

If you’re interested in using the API elsewhere, check out the useful summary of how it works here:

Let’s go ahead and code our passes method to perform the check:

public function passes($attribute, $value)
    $url = '' .    
           Str::after($value, '@');

    try {
       return ! json\_decode(file\_get\_contents($url), true)
    } catch (Exception $ex) {
       return ($this->parameters[0] ?? false) ? false : true;
Enter fullscreen mode Exit fullscreen mode

The method constructs a url by plucking the email domain from the user-supplied value, it then passes it to the API and then decodes the response.

Since we’re accessing a third-party site, we wrap the operation in an exception handler, in case we are unable to obtain a response. If the operation fails, the rule will, by default, accept the email address. However, you can override this behaviour by submitting a boolean parameter during the rule’s instantiation.

TIP : I recommend that you also use the native email validation rule to ensure that the user has first provided a syntactically correct address. See the test below.

Next, we’ll need to write an error message to return when the user has not supplied a valid email address:

public function message()
    return 'The :attribute must be a valid, non-disposable domain';
Enter fullscreen mode Exit fullscreen mode

Testing it works

As before, we’ll write a quick unit test to confirm that the API works correctly and rejects fake / disposable email addresses:

public function a\_disposable\_email\_can\_be\_validated()
    // Define the validation rule
    $rule = ['email' => ['bail','email',new DisposableEmail(true)]];

    // Execute the tests
    $this->assertTrue(validator(['email' => ''], $rule)->passes());
    $this->assertFalse(validator(['email' => ''], $rule)->passes());
Enter fullscreen mode Exit fullscreen mode

Wrapping Up

We now have a reusable validation rule to ensure users supply a real, non-disposable email when we require it. We also respond with a suitable error message when the check fails, and we have a test to ensure the rule works.

You can see the complete class and pull it into your projects by visiting the repo on Github:

I have additional validation rules that I intend to share with you in the coming days, so be sure to follow me for those articles. If you’re interested, you can also follow me on Twitter to see everything I’m up to.

Happy coding!

Discussion (4)

Editor guide
defman profile image
Sergey Kislyakov 🇷🇺 🇺🇸

Why would one want to do such a validation? There are reasons why people use temporary e-mails, from unwanted e-mail newsletters to e-mail leaks.

The later one made me to spin up my own e-mail forward service, so I could easily block unwanted e-mails and detect e-mail leaks. Does my case counts as a disposable/fake e-mail as well?

mattkingshott profile image
Matt Kingshott 👨🏻‍💻 Author • Edited

There are indeed reasons, and I'm not advocating it as standard for all apps. I'm simply providing the option if you wanted / needed to use it. As for why you might want to...

Suppose your app suffered a breach, if you have disposable details on your system, you wouldn't be able to contact the user to let them know.

It can also depend on the nature of your application, e.g. if it is financial, legal, medical, governmental. In these situations, and depending upon the region, there may even be laws / regulations that require you to ensure you have a valid email address for the account holder.

defman profile image
Sergey Kislyakov 🇷🇺 🇺🇸

Well I didn't think about the second case, but I guess if it's financial/legal, there are some other validation steps (such as a copy of your ID) so I don't really see any reasons to validate an e-mail. Of course unless the only info you'd provide to the government/bank/medical clinic would be e-mail, then you should cut out any disposable e-mails.

If your app suffered a breach, then those who uses disposable e-mails does not care about that at all. That's why they used disposable e-mails: "If it leaks, it leaks. I'm safe."

Regardless, thanks for your answer :)

Thread Thread
mattkingshott profile image
Matt Kingshott 👨🏻‍💻 Author

With regards to your first point, you would think so, however I've dealt with systems that actually didn't require other forms of identification, yet still had regulations about email. Crazy, but it does exist!

Yeah, I reckon you're probably right about your second point, however, there is always the possibility of "data creep". You sign up with a disposable not intending to do much with the app, then over time you start adding more real data, but never remember to change the email address (particularly if you login with a username instead of an email). The breach occurs, important data of yours is stolen, but we can't contact you. Admittedly, this is more of a "what if" scenario, but there you go :)

And you're welcome :)