Laravel Email Domain Rule Laravel Package

Product Decisions This Supports

• Build vs. buy on signup gating: If the roadmap includes restricting signups to corporate domains (blocking free/disposable providers), banning competitor or abuse domains, or allow-listing partner domains, this package turns that from a custom validation class plus config surface into a small, tested dependency. The decision it informs is whether domain policy is a first-class product capability or a one-off rule.
• B2B onboarding and lead quality: Supports decisions about requiring work emails at registration versus allowing consumer addresses, which directly affects trial conversion, sales-qualified lead volume, and support load from unqualified signups.
• Trust & safety roadmap: Disposable-domain blocking is a lever against fraud, trial abuse, and spam. This package makes it cheap to test that lever (enable in staging, measure abuse rate delta) before committing engineering time to a fraud pipeline.
• Scope of the 3.2.0 update: This is a compatibility release — PHP 8.3 support and Laravel 11.x support — not a feature release. It unblocks (or de-risks) the platform upgrade roadmap rather than changing product behavior. If the team is planning a Laravel 11 migration, this package is no longer an upgrade blocker; that is the concrete decision it informs.
• Use cases it enables: invite-only tenant provisioning by email domain, enterprise allow-list onboarding, region/competitor restrictions, and a cheap experiment on disposable-email rejection before investing in a paid verification vendor.
• Not a substitute for deliverability: it validates domain policy, not mailbox existence. Decisions about email verification, bounce handling, or SMTP validation still need a separate answer.

When to Consider This Package

Adopt when:

• The requirement is narrow and declarative: allow or deny specific domains on an email field, ideally across several forms and API endpoints where duplicating a regex or a hardcoded array would drift.
• The team is on Laravel 11 and PHP 8.3 — 3.2.0 explicitly adds that support, so compatibility risk is low.
• You want the rule to be config-driven and shareable across registration, invite, and profile-update flows rather than reinvented per controller.
• You want to move fast on a policy experiment (e.g., block free-mail at signup for a B2B tier) without a schema or service change.

Look elsewhere when:

• Requirements extend to real-time reputation, catch-all detection, or SMTP/MX mailbox probing — that is a verification vendor's job, not a rule.
• You need per-user adaptive policy, ML scoring, or audit-grade abuse analytics.
• The domain list is large and fast-changing and needs an operational owner, admin UI, and hot-reload — a config-file rule becomes a deployment dependency.
• The list is a single static domain or two. A native Laravel ends_with/regex rule is simpler than a dependency, and dependency count itself has a cost.
• Long-term maintenance signals matter: this is a small single-maintainer package, and the 3.2.0 notes are maintenance (version bumps), not a growing feature set. Confirm the current version supports your Laravel line before adoption, and pin the constraint.
• Note a practical caveat: allow-listing by domain excludes legitimate users on shared or custom domains and can create a support burden that outweighs the spam savings — validate that trade-off before shipping.

How to Pitch It (Stakeholders)

One-line summary: A small Laravel validation rule that enforces email domain policy — allow-lists, block-lists, and disposable-domain rejection — as configuration instead of custom code. Release 3.2.0 is housekeeping: it adds PHP 8.3 and Laravel 11.x support, so it no longer stands in the way of the framework upgrade.

For executives: This is a low-cost, low-risk lever on signup quality. It lets us test whether restricting signups to work email domains improves lead quality or reduces abuse, without an engineering project. The 3.2.0 release is a compatibility update, not new scope — it keeps the package aligned with our PHP 8.3 / Laravel 11 upgrade path, which removes it from the list of upgrade blockers.

For engineering: It is a thin, config-driven validation rule, so the integration surface is one rule on existing form requests and API validation — no migrations, no new service, no queue. The 3.2.0 release adds PHP 8.3 and Laravel 11 support; treat it as a version-constraint bump, verify it in staging as part of the upgrade, and pin the constraint. Caveats to flag: small, single-maintainer package (so budget for a fallback of a native rule if maintenance lapses), it validates domains only — not mailbox existence — and allow-listing by domain has real edge cases for users on shared or custom domains that we should plan a support answer for.

Recommendation: Do not make it a platform dependency on the strength of a maintenance release. Adopt only where a domain policy requirement already exists, scope it to the specific validation points, and pair any signup restriction with a measured experiment rather than a permanent default.