Email Guard Core Laravel Package

Product Decisions This Supports

• Signup fraud & fake-account reduction: quantifies the impact of blocking disposable/reserved-TLD emails on activation quality, trial abuse, and support tickets. PMs can A/B local-only vs. local+API escalation and measure the lift in "verified user" rate against the cost of false positives.
• Build vs. buy for email validation: this package is the build-vs-buy pivot point. It packages the "known junk" heuristic layer (syntax, reserved TLDs, 73k+ disposable domains) as a free default, and lets you buy the expensive bits (live MX, SMTP probe, catch-all/role detection) only when justified. That gives a clean cost-per-check vs. quality-per-check tradeoff to model in a roadmap.
• Checkout / lead-form gating strategy: exposes a three-state action model (Allow / Deny / Review) and policy config (block_on, review_on), which maps directly to product policy decisions — do we hard-reject catch_all, or route it to manual review? PMs can tune this per funnel (high-intent checkout likely stricter than newsletter signup).
• Escalation-tier roadmap: supports a phased plan — ship local-only in v1 (zero latency, zero API spend), then introduce API-key-powered verification for cohorts where it pays back (e.g., high LTV segments). Roadmap sequencing becomes a policy/config decision rather than a re-architecture.
• Multi-platform rollout: since the Symfony bundle and WordPress plugin build on this core library, one PM decision here propagates to web, CMS, and framework surfaces — useful when defining consistency of email handling across owned properties.
• Latency vs. accuracy budgeting: the "zero network calls, zero latency" local path is a concrete product constraint for signup UX; PMs can decide which funnels can tolerate the added latency of SMTP/MX probing.
• Not supported by adoption signal: with 0 stars, 0 dependents, and a single maintainer, this is far more useful as a reference implementation of the spec than as a dependency you assume the ecosystem has validated. Product decisions should not lean on community momentum here.

When to Consider This Package

Consider it when:

• You're on PHP 8.1+ and want an email guard with no framework lock-in (Laravel, Symfony, standalone, WordPress all viable).
• You want a free, offline baseline that catches the cheap cases — broken syntax, reserved/invalid TLDs, and a large bundled disposable-domain snapshot — before spending on verification.
• You're willing to own risk on a young dependency: it's MIT, small, auditable, and easy to vendor or fork — which matters more than stars for infrastructure-level libraries.
• You want a progressive-enhancement path: local-only now, API escalation later behind a key and a policy, without swapping libraries.
• You're already aligned with (or evaluating) the EmailSherlock verification API, or you want a spec-driven implementation you can reason about and extend.

Look elsewhere when:

• You need battle-tested, high-adoption tooling with a large contributor base and security-review track record — 0 dependents means you are the first production user.
• You require SLA/support contracts or vendor guarantees; a single-maintainer core library is a bus-factor risk.
• Your primary need is deliverability (bounce classification for outbound campaigns) rather than form-level input guarding — the problem space and tooling differ.
• You're not on PHP 8.1+, or you want the framework-native experience — in that case use the Symfony bundle / WordPress plugin directly, or a Laravel-native validator package.
• You need fully offline accuracy including MX validity and catch-all detection — those are explicitly behind the paid API key, so pure-local deployments accept a coverage ceiling.
• Your team treats future-dated releases / unverified maturity claims as a blocker rather than something to independently audit.

How to Pitch It (Stakeholders)

To executives (one paragraph): Fake and disposable email addresses cost us real money — trial abuse, junk leads, wasted sends, and support load. This package lets us shut off the cheap, obvious cases today at zero cost and zero added latency, using a bundled blocklist and syntax/TLD rules, and then optionally buy deeper verification (live MX, SMTP, catch-all and role detection) only where the ROI is proven. Because it's MIT-licensed, framework-agnostic PHP that runs on our existing stack, the initial commitment is small, and the architecture already supports a phased rollout from free local checks to paid API escalation — a rare combination of immediate upside and low switching cost.

To engineering: Framework-free PHP 8.1+ library with a clean policy API — construct with optional api_key plus block_on/review_on lists, call check(), and branch on Action::Allow | Deny | Review. Local path is deterministic and offline (syntax, reserved TLDs, ~73k disposable domains); the API key unlocks MX, SMTP probing, a fresher disposable list, and role/catch-all detection. No framework coupling means we can adopt the Symfony bundle or WordPress plugin as thin wrappers rather than reimplementing. Main engineering cautions: tiny dependency-footprint is a strength, but the project has no visible downstream adoption — plan to vendor or fork, pin a version, and add our own tests around it; treat the network path as an opt-in feature flag, not a default, so latency and third-party availability stay under our control.

To product & growth: The Allow / Deny / Review model lets us express policy rather than code — a stricter stance on checkout, a softer Review path for catch-all addresses, and tunable criteria per funnel. We can measure the decision empirically: run local-only vs. local-plus-API in an experiment and compare fake-account rate, activation quality, and false-positive rejections. Recommend launching local-only first, instrumenting what escapes, then enabling API escalation for the segments where blocked junk actually correlates with costly downstream behavior.

Risks to state plainly: single-maintainer dependency, zero current dependents, and accuracy for harder cases is gated behind a paid vendor API — so the adoption decision is really "adopt an offline heuristic library and an optional vendor relationship," not "adopt a proven market leader." That tradeoff should be an explicit, documented call, not an implicit one.