Laravel Disposable Email: a validation rule for throwaway addresses

One validator rule backed by a community domain list

Laravel Disposable Email adds a validator to Laravel that checks whether an email address comes from a disposable email service, with Mailinator and Guerillamail given as examples. The domain data is not the package's own: it uses the disposable domains blacklist from the disposable/disposable project by default.

That division is the whole design. The package is the Laravel integration, a validator rule, a scheduled command and a configuration file. The knowledge of which domains belong to throwaway mail providers lives in a separate, frequently updated list, and the package consumes that list.

The consequences follow from that split. A domain that appears on the list tomorrow is caught tomorrow. A domain that appeared for an afternoon and disappeared is missed, and the README is explicit that a weekly patch release carries updates to the built-in list. So the question of whether the validator is accurate is really a question of how current your installed version is, and the package gives you two ways to handle that, one automatic and one you drive.

Installation is a composer require and a vendor publish

The install steps are short. The package is installed with Composer, and the service provider is discovered automatically, so there is no manual registration in the service provider list:

    composer require propaganistas/laravel-disposable-email

The second step publishes the configuration file so you can adapt it:

    php artisan vendor:publish --tag=laravel-disposable-email

There is an optional third step, which is a language file edit. Each language needs an extra line for the validator message, and the English text given in the README is:

    'indisposable' => 'Disposable email addresses are not allowed.',

That step being optional means the validator can be used without it, and the failure mode if you skip it is a missing translation rather than a broken rule. The top level of the repository is consistent with a focused package: a composer.json, a config directory, a src directory, a tests directory, and a domains.json file at the root, which is where the bundled list lives.

Using the rule means ordering it after the email rule

The validator is used by name in a validation rule array, and the README advises adding it after the email validator so that a well-formed address is checked first:

'field' => ['email','indisposable'],

The order matters in a small but real way. The email rule rejects malformed addresses, and the disposable rule asks a different question about an address that is already valid. Running the cheap syntactic check first means the more expensive, list-backed check only sees addresses that could pass.

The rule name is indisposable, and it is the only rule the package adds to the validation vocabulary. There is no separate service class to inject, no model trait, and no middleware, which keeps the integration surface small enough that using it does not require a particular project structure.

The mx parameter catches rotated front domains

This is the most interesting part of the package, and it addresses a specific evasion. Disposable services rotate their public front domains endlessly, with web-library.net given as an example, while their backend mail infrastructure stays constant, with mail.tm given as an example of that. A freshly rotated front domain is not on the list yet, so a plain domain-list check lets it through.

Enabling MX inspection closes that gap. The validator resolves the domain's MX records and flags the address when its mail servers point at a domain that is already on the list. The same backend, a different front, and the address gets caught.

It is enabled with a parameter on the rule:

'field' => ['email','indisposable:mx'],

The cost is stated in the README as well: this performs a live DNS lookup during validation, trading a little latency for broader coverage. If your validation path must stay strictly offline, leave the parameter off. That is a real constraint rather than a caveat, because a DNS lookup inside a validator turns a self-contained check into a network call, and the behaviour of your signup form then depends on the reachability of your resolver.

Keeping the list fresh means running a scheduled command

The package receives a weekly patch release containing updates to the built-in disposable domains list. If you cannot bump your installed version accordingly, or you simply prefer to stay ahead, the README says to update the domains list yourself at any interval you like by running or scheduling the disposable:update command.

The scheduling example is a routes/console.php snippet using the scheduler facade:

    // routes/console.php
    
    use Illuminate\Support\Facades\Schedule;
    
    Schedule::command('disposable:update')->daily();

The command is called disposable:update and the example runs it daily. The package therefore works in two ways at once, and the choice is about your update policy. If your deployment pipeline bumps dependencies regularly, the weekly patch release keeps the list current with no extra infrastructure. If your production version is pinned for long periods, the scheduled command is the way to keep the list fresh without waiting for a release.

The domains.json file at the repository root is the shipped list, and the command is what replaces it. Note that this means the list is state on your server, not a query against a remote service at validation time, apart from the optional MX lookup.

The default fetcher is file_get_contents, which matters behind a proxy

The last configuration point in the README is about how the list is retrieved. By default the package retrieves a new list by using file_get_contents(). If your application has different needs, for example when it sits behind a proxy, the README points at the disposable-email.fetcher configuration value.

That single knob is worth pausing on, because it determines whether the update command works at all in your environment. A plain file_get_contents() call does not use the HTTP client your application is configured with, and it does not automatically inherit a proxy setting, a timeout, or a custom CA bundle. In a deployment where outbound HTTP is filtered or proxied, the update command can fail quietly enough that nobody notices until the list is months old.

The fetcher is why publishing the configuration file matters even if you plan to change nothing else. The published file is the only place where that value is visible and adjustable, and the README frames the whole config section as something to adapt as desired.

A list check is a speed bump, not a fraud control

It is worth being blunt about what this package does and does not achieve, because the name suggests more than it delivers. It checks a domain against a list of known disposable mail providers. A person who wants to sign up with a throwaway address can trivially use a domain that is not on the list, and a service that exists only to serve mail addresses can add a new front domain faster than the weekly list update reaches it.

The MX inspection narrows that gap for providers with a stable backend, which covers a lot of real disposable services. It does not close it, and it introduces a network dependency into the validation path.

So the sensible use is as one layer. Combine it with other signals, and treat the list freshness as something you own. The package's own documentation is helpful on this point by being concrete about the mechanism: it names the two rotation behaviours that make the list alone insufficient, which is more than most packages of this kind tell you.

The release history also shows the shape of the maintenance. Tags 2.5.0, 2.4.25 and 2.4.11 went out in July 2026, March 2026 and February 2025, and the last push to the master branch was on 2026-10-01, so the project is still being worked on.

Editorial conclusion

Adopt this package if you run Laravel and want to reject throwaway email addresses at signup, and you are prepared to keep the domain list fresh with the disposable:update command or the weekly patch release. Do not adopt it as a complete fraud defence, since a domain list check only catches known providers, and decide deliberately whether to enable the mx parameter, since it adds a live DNS lookup to every validation. Before you rely on it, publish the configuration file with php artisan vendor:publish --tag=laravel-disposable-email and check the fetcher setting, because the default list retrieval uses file_get_contents() and may need changing behind a proxy.

Frequently asked questions

Official sources

1. Issues
2. Propaganistas/Laravel-Disposable-Email on GitHub
3. README
4. Releases