Lara Email Laravel Package

Getting Started

Install the package with Composer:

composer require leancaptain/lara-email

No service provider registration or config publishing is required. Look first at the LeanCaptain\LaraEmail\Rules\UsableEmailDomain rule class and the bundled disposable-domain snapshot/metadata if you need to understand which domains are blocked.

The first practical use case is signup or registration email validation: reject reserved example domains, bundled disposable domains (and their subdomains), and domains without a usable MX record.

use LeanCaptain\LaraEmail\Rules\UsableEmailDomain;

'email' => [
    'bail',
    'required',
    'string',
    'email',
    new UsableEmailDomain,
],

Use it alongside Laravel’s normal email rule. It does not verify mailbox existence or ownership, so keep your normal email confirmation flow.

Implementation Patterns

FormRequest usage. Put the rule after format validation and use bail so DNS/MX checks only run for otherwise valid input.

public function rules(): array
{
    return [
        'email' => [
            'bail',
            'required',
            'string',
            'email',
            new UsableEmailDomain,
        ],
    ];
}

Inline validator usage. The rule is a standard Laravel validation rule object, so it works with Validator::make() and other rule arrays.

Validator::make($request->all(), [
    'email' => ['bail', 'required', 'email', new UsableEmailDomain],
]);

Reusable rule sets. For multiple signup, invite, newsletter, or lead-capture forms, define the email rule set once in a shared class/helper rather than repeating the stack. This keeps disposable-domain and MX behavior consistent across entry points.

Avoid duplicating DNS work. The package performs MX checks itself. Do not casually stack email:dns on top unless you intentionally want multiple DNS-related checks; keep the built-in email rule for syntax and this rule for domain/MX policy.

Caching expectations. Successful MX checks can be cached, bounded by DNS TTL and capped at five minutes. Failed checks are never cached. Treat this as short-lived protection only; it is not a long-lived DNS cache. The release notes do not document a published config file, so inspect the rule constructor/package source if you need to confirm how caching is enabled or tuned.

High-volume flows. Validation runs synchronously and performs DNS lookups, so use bail and consider rate limiting or other abuse controls on public signup endpoints. This rule is best used at account creation or lead capture, not on every request for an already-known email address.

Gotchas and Tips

• Strict runtime requirements. This release requires PHP 8.4 or 8.5 and Laravel / Illuminate Validation 13. Confirm your app and CI matrix meet this before adopting; older Laravel/PHP versions will be blocked by Composer.
• DNS is a runtime dependency. DNS failures can produce the package’s retry message. Treat that as transient infrastructure trouble, not necessarily an invalid user email. Failed checks are not cached, so repeated DNS outages can cause repeated lookups.
• No mailbox verification. The rule validates domain-level usability only. It does not prove the mailbox exists or belongs to the user; keep double opt-in or verification emails for security-sensitive flows.
• Exact-domain MX lookup. MX validation is for the exact email domain. A subdomain address checks that subdomain, not the root domain. This matters for hosted domains and custom subdomains.
• Null MX rejection is intentional. Domains that publish a null MX record to declare they do not accept mail will be rejected. That is usually desirable for signup, but it can surprise you when testing with domains configured that way.
• Disposable-domain data ages. The package bundles a disposable-domain snapshot with source metadata and a CC0 license. The list will become stale over time; plan to update the package periodically rather than assuming the initial snapshot stays current.
• No published config means limited customization. There is no service provider or config publishing step, which keeps setup simple but means custom blocked-domain lists or cache policy likely require wrapping/subclassing the rule or changing package internals.
• Test without relying on live DNS where possible. DNS-dependent tests can be flaky in CI. Use known stable domains for integration checks, and check whether the rule can be mocked/faked in your test setup if you need deterministic validation tests.
• Check UX for the retry message. If the package’s DNS retry message is not suitable for your UI or localization strategy, wrap the rule or provide your own validation flow rather than assuming the default message is fully customizable.