Laravel Disposable Email Laravel Package

Product Decisions This Supports

• Build vs. buy for abuse prevention. Disposable-email blocking is a commodity guardrail: a curated domain list, a validation rule, and a refresh job. Buying costs one Composer line and a scheduled command; building costs an owner, a list-maintenance pipeline, an MX-resolution subsystem, and a permanent backlog item. Unless disposable signups are a top-three abuse vector with bespoke detection needs, buy.
• Feature prioritization for signup integrity. This lets you ship a measurable integrity control inside an existing signup epic rather than opening a new "trust & safety platform" workstream — one rule string added alongside email, rate limiting, verification, and captcha.
• Gating and rollout strategy. Because the rule is scoped per-form, you can decide where it applies (consumer signup vs. B2B invite vs. enterprise lead capture) and how hard it applies (hard-block, soft-block with a verify-first path, or warn-only and log). These are product calls this package makes cheap to test.
• Conversion vs. fraud tradeoff. Every anti-abuse rule has a false-positive cost. The :mx option and hard-block enforcement are the two dials that move both abuse coverage and legitimate-user rejection — a decision to model with real traffic rather than an engineering detail.
• Roadmap sequencing. Adoption is cheap now and gets no cheaper later: the version support window is actively trimmed (Laravel 8/9 and PHP 8.0 dropped in 2.3.0), so deferring adds upgrade friction rather than saving effort.
• Success metrics to instrument. Disposable-domain rejection rate, share of rejections later confirmed legitimate (false-positive proxy), trial-to-paid quality, duplicate-account and promo-abuse rates, and signup latency delta if :mx is enabled.

When to Consider This Package

Adopt when:

• You run a Laravel app with self-serve signup, free trials, or credit-based onboarding where throwaway inboxes are a known abuse vector.
• Your stack is on a currently supported Laravel/PHP pair (Laravel 11–13, PHP 8.1+) and disposable-email blocking is a hygiene control, not the core of your fraud strategy.
• You can schedule disposable:update (daily) — the project ships weekly list patches, and pinning without refreshing means detection coverage silently decays.
• You want a sub-day integration with no new infrastructure, datastore, or vendor contract.
• You're willing to own a fallback: vendoring the bundled domains.json or accepting the rule degrades gracefully if the dependency is dropped.

Look elsewhere when:

• You need risk scoring, device fingerprinting, velocity rules, or identity graph analysis — this is a domain-list check, not a fraud platform. Pair it with (do not substitute it for) a dedicated risk vendor.
• Your validation path must be strictly offline or latency-budgeted below a DNS round trip — skip the :mx parameter, and accept that rotated front domains will leak through.
• You operate in an environment where a single-maintainer dependency with 0 dependents and no security review process is unacceptable as load-bearing infrastructure.
• Legitimate users in your market commonly use shared mail infrastructure that trips MX heuristics — expect elevated false positives and prefer list-only enforcement.
• You need an SLA, contracted support, or a compliance attestation.

How to Pitch It (Stakeholders)

To executives: A one-day integration that shuts down a common, low-effort abuse channel — throwaway inboxes used to farm free trials, referral credits, and promo codes. Cost is negligible and reversible; the measurable return is fewer fake accounts inflating signup numbers and degrading funnel metrics. Framing matters: this is signup hygiene that makes growth metrics trustworthy, not a security product, and not a replacement for our existing verification, rate limiting, and risk scoring.

To engineering: An idiomatic Laravel package — auto-discovered provider, indisposable rule added to the existing validator pipeline, publishable config, and a schedulable disposable:update command. No new runtime, schema, or service. Two decisions need owners: (1) scheduling the list refresh so coverage doesn't decay between weekly upstream patches, and (2) whether to enable :mx, which adds a live DNS lookup to the validation hot path and requires an explicit fail-open policy plus a timeout so a bad resolver never blocks legitimate signups.

To support and marketing: Blocked users need a visible, polite recovery path — a localized indisposable error line and clear guidance to use a permanent address. Roll out to the highest-abuse surfaces first, monitor the false-positive rate against support tickets, and keep an override available before expanding enforcement.

Known risks to state up front: detection quality is bounded by the upstream disposable/disposable list and rotating front domains can slip through; the dependency has one primary maintainer and no support commitments; and its Laravel support window is actively trimmed, so it must sit on the framework-upgrade checklist rather than drift.