Laravel Email Domain Rule Laravel Package

Product Decisions This Supports

• Waitlist / signup gating by domain. If the go-to-market strategy is B2B (sell to companies, not individuals), this package enforces "work email only" server-side rather than relying on client-side hints or manual review. That directly influences conversion-funnel design and lead quality.
• Free/disposable provider policy. Whether you block Gmail/Yahoo signups, allow them read-only, or route them to a separate onboarding path is a product policy decision. The package gives engineering a clean seam to implement that policy as a single validation rule instead of ad-hoc str_ends_with checks scattered across controllers, form requests, and API handlers.
• Abuse and fraud controls. Domain restrictions are a cheap first line of defence against trial farming, promo abuse, and bot signups from throwaway providers. Relevant when pricing or free tiers create an incentive to create multiple accounts.
• B2B2C / tenant onboarding. For invite flows, SSO-style domain matching, or "verify your company domain" steps, a single well-tested rule keeps the policy consistent across web, API, and admin-invite paths.
• Build vs buy. The core logic is genuinely small — a domain allow/deny check is a few dozen lines. The value here is not novel capability but a maintained, framework-versioned, testable implementation with an established API. Treat it as a low-cost convenience dependency, not a strategic one; the decision cost of adopting it is near zero and so is the cost of replacing it later.
• Roadmap implication. Release 3.2.0 (PHP 8.3 and Laravel 11 support) removes this package as a blocker for a framework upgrade. If engineering has been holding the Laravel 11 migration on third-party compatibility, this is now cleared for this dependency — worth confirming it was on the blocker list before it changes upgrade sequencing.

When to Consider This Package

Adopt it when:

• You need deterministic, self-hosted domain allow/deny validation with no external API call on the signup hot path.
• Your policy is explicit domain lists (e.g. block gmail.com, mailinator.com; allow *.acme.com), not heuristic classification.
• You are on Laravel 11 / PHP 8.3 or planning to be — this release is explicitly tested there, and the absence of breaking changes means adoption or upgrade carries no migration work.
• You want the rule to be unit-testable and consistent across FormRequests, API validation, and console commands, rather than duplicated per surface.
• You want the smallest possible dependency for a policy that product may want to change quickly (allowlist → denylist, per-plan variations) without a re-architecture.

Look elsewhere when:

• You need maintained, continuously updated disposable-domain intelligence (thousands of rotating domains, catch-all detection). That is a data problem, not a validation-rule problem — you likely need a hosted detection API or a curated list you own and refresh. Confirm whether this package bundles any list or expects you to supply domains; if it expects you to supply them, budget for list maintenance as a product cost, not just an engineering one.
• You need deliverability or existence signals — MX record lookup, SMTP probing, typo correction ("did you mean gmail.com?"). Different problem class.
• You need consumer signup with social/SSO where domain policy is irrelevant or actively harmful to conversion.
• You need enterprise-grade vendor support, SLAs, or security review artefacts. This is a small, single-maintainer open-source package; assess accordingly if it sits in a compliance-sensitive signup path. It is easily vendored or reimplemented if maintenance lapses — a genuine mitigating factor.

How to Pitch It (Stakeholders)

To executives: This is a small, zero-cost open-source utility that lets us enforce "who can sign up" rules — for example, work-email-only registration or blocking throwaway inboxes — consistently across every surface of the product. It is not a platform bet: the logic is simple, the licence is permissive, and we could replace it in an afternoon. The new 3.2.0 release adds PHP 8.3 and Laravel 11 support, which means it no longer blocks our framework upgrade and carries no breaking changes. The one thing to be clear on is that domain policy is a business decision we still own; the package enforces rules, it does not tell us which domains to block or supply a live fraud database. Approve as a routine engineering dependency, and route the actual signup-policy question — do we accept free-email signups? — through product.

To engineering: Use it as the single validation rule for domain policy instead of hand-rolled string checks so the rule is testable and consistent across FormRequests, API endpoints, and admin/invite flows. Pin to ^3.2 given the Laravel 11 and PHP 8.3 compatibility work; no breaking changes are introduced, so upgrading from 3.x is low-risk. Keep the domain lists in config rather than in code so product can tune them without a release, and add a test asserting the list is non-empty and loaded — an empty allowlist that silently permits everything is the realistic failure mode here. Also confirm whether the package ships a disposable-domain list or expects one from us; if the latter, decide early who owns refreshing it, because an unmaintained blocklist decays into a false sense of security.