Lara Email Laravel Package

Product Decisions This Supports

• Signup and lead-capture hardening: Gives a product team a low-effort lever to reduce disposable/throwaway signups, trial abuse, and fake accounts without building a blocklist or DNS lookup layer in-house. Sits alongside Laravel's email rule, so it can be scoped to specific flows (registration, trial start, promo redemption) rather than globally.
• Build vs. buy for email hygiene: The realistic alternative is a custom rule + maintained domain list + MX resolver, or a third-party verification API. This package makes the "build" option cheap enough to defer a paid vendor for the domain-level checks — it does not replace mailbox verification, so any decision to buy a verification vendor stays open and independent.
• Roadmap scoping for fraud/abuse work: Lets you split the problem into tiers: (1) syntax + disposable/example blocking (this package, this sprint), (2) MX/deliverability checks (this package), (3) mailbox existence and risk scoring (vendor or later work). Useful for arguing that tier 1–2 is a days-not-quarters investment, freeing roadmap room for the harder signals.
• Deliverability and sender-reputation decisions: Rejecting domains with no usable MX at the door reduces hard bounces, which protects sending domain reputation — a decision that otherwise shows up as a marketing-ops or infrastructure concern rather than a product one.
• Use cases that fit cleanly: self-serve SaaS free tiers, community/forum registration, waitlists and beta signups, lead magnets, and any funnel where per-account cost or abuse potential is real. Poor fit for B2B invite-only onboarding, enterprise tenant provisioning, or flows where a human reviews accounts anyway.
• Latency budgeting: Because MX checks run synchronously during validation and only successful lookups are cached (≤5 minutes, DNS-TTL bounded), this is a decision input for signup-form performance: expect added p95 latency on first-time domains and a retry path when DNS fails. Worth measuring before making it mandatory on a high-traffic form.

When to Consider This Package

Consider it when most of the following hold:

• The service is Laravel on PHP 8.4/8.5 with Illuminate Validation 13 — this release pins to Laravel 13, so it is only viable once your app is on that major version. On older Laravel, this is a non-starter today.
• You have a measurable disposable-signup or fake-account problem, or you are pre-launch and want a cheap default before abuse appears.
• You want zero configuration and no service provider — the appeal here is a one-line rule addition with no config surface, no migrations, no keys, no external API dependency.
• Your team is comfortable with DNS in the request path and can tolerate occasional lookup failures with a user-facing retry message.
• You want a permissively licensed (CC0) disposable-domain snapshot rather than depending on a vendor's opaque list or maintaining your own.
• You accept that blocklist updates arrive with package releases — you cannot add your own domains or exceptions without forking or wrapping the rule.

Look elsewhere (or defer adoption) when:

• You need configurability: no publishable config means no allowlist for customers/partners who happen to use a blocked domain, no per-environment toggles, and no custom domain additions. If your support team will need an override list, plan to wrap this rule yourself.
• You need mailbox verification or fraud scoring: this explicitly does not verify mailbox existence or ownership. Do not position it internally as an anti-fraud solution.
• Latency is tight or DNS egress is restricted: synchronous MX lookups on a high-volume or latency-sensitive form, or environments with locked-down DNS, are a poor fit. Async/queued validation or a vendor API may be better.
• You are pre-Laravel-13 or cannot yet run PHP 8.4+.
• False positives are expensive: consumer ISPs, shared hosting MX, and catch-all corporate domains create edge cases; if wrongly blocking a paying customer is costly, start in log-only mode or restrict to the riskiest flows.
• Maturity matters: v0.1.0 is pre-1.0, so expect API churn. Avoid hard-coding it as a platform-wide standard in the first quarter.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small, free, open-source Laravel component that rejects obviously fake signup emails — example domains, known disposable inboxes, and domains that cannot receive mail at all — at the moment of registration. It is a one-line addition with no vendor contract, no configuration, and no data-sharing with a third party, and it reduces the junk accounts and hard bounces that inflate costs and damage sender reputation. It is a hygiene improvement, not a fraud platform: it does not confirm a mailbox is real, and it is not a substitute for a paid verification service if we later need risk scoring. The main trade-off is a small amount of added latency on first-time domains and dependence on our Laravel upgrade timeline.

For engineering (summary): A single validation rule, UsableEmailDomain, intended to accompany Laravel's email rule. It normalizes case, handles internationalized domains, blocks reserved example domains plus a bundled disposable list (including subdomains), and requires a usable MX record for the exact domain, rejecting missing and null MX. Successful MX checks are cached, bounded by DNS TTL and capped at five minutes; failures are never cached, and DNS failures surface as a retry message rather than a silent pass or hard fail. No service provider or config publishing — install via Composer and instantiate the rule. Constraints to plan around: PHP 8.4/8.5 and Illuminate Validation 13 only, so it is gated on the Laravel 13 upgrade; lookups are synchronous inside validation, so put it behind bail and measure p95 latency; there is no extension point for a custom allowlist, so any override requirement means wrapping the rule in our own validator. Treat v0.1.0 as pre-1.0 and pin the version. Recommend a staged rollout: log-only or non-critical flows first, track block rate, false positives, and DNS failure rate, then make it mandatory on self-serve signup.