Product Decisions This Supports
- Signup and trial abuse policy. Whether to hard-block, soft-flag for review, or silently rate-limit signups from known disposable domains — and by extension, whether free trials need a work-email requirement.
- Build vs. buy on email risk. Deciding between a free static denylist (this), a paid verification API (Kickbox, NeverBounce, ZeroBounce), or a full identity/risk vendor — with a clear staging path: start static, graduate to API only when false-positive and abuse data justify the spend.
- Free-tier packaging and pricing. If disposable-email signups correlate with low activation and high support cost, this informs whether to gate features, shorten trials, or require payment-method verification instead of blocking signups outright.
- Segment-specific rules. B2B flows can treat disposable domains as near-certain abuse; consumer/privacy-sensitive flows may tolerate them. This data lets you make that a per-product configuration decision rather than a global policy.
- Roadmap for the abuse/risk surface. A cheap first increment for an internal risk service — domain reputation, device fingerprinting, velocity limits — where email domain is one signal among several.
- Metric definition. Establishes a trackable KPI ("% of signups on disposable domains," "abuse-attributed churn") so later investments have a baseline to beat.
Caveat worth carrying into every decision: this is a data list, not a maintained Laravel package. The PM decision is really "do we vendor this list and own its freshness," not "do we adopt a dependency." With 0 dependents and a low opportunity score, treat it as a starting dataset, not a platform commitment.
When to Consider This Package
Consider it when:
- You have existing, measurable signup abuse (trial farming, promo-code multi-claiming, spam accounts) and want a same-sprint mitigation.
- You need a zero-cost, zero-network baseline signal — no vendor contract, no PII sent to a third party, no per-call billing.
- Your enforcement model is soft-flag first (review queue, throttling, delayed feature access), where a false positive costs little.
- You're pre-product-market-fit and want to avoid signing an annual verification contract before you know your abuse rate.
- You want it as one input to a layered rule set alongside MX-record checks, SMTP validation, rate limits, card fingerprints, and device signals.
Look elsewhere when:
- You need freshness guarantees or an SLA — a static list ages, and provider domains churn constantly. You'd need a scheduled refresh job and an owner.
- You need catch-all detection, deliverability scoring, or B2B firmographic verification — that's a paid API, not a denylist.
- False positives are expensive (enterprise sales, regulated onboarding) and you can't afford to turn away a legitimate customer whose domain happens to be listed.
- You require vendor accountability, support, or audit trails for a compliance or trust-and-safety program.
- Disposable email isn't actually your abuse vector — virtual cards, VoIP numbers, and device farms often matter more, and buying this would be effort misplaced.
How to Pitch It (Stakeholders)
To executives: This is a free, MIT-licensed dataset of ~1,200 known burner email domains used by fraudsters to farm trials and promo codes. Integration cost is roughly a day of engineering and carries no vendor contract, no per-check fee, and no customer data leaving our systems. It is a cheap first layer, not a silver bullet — expect it to catch the lazy majority of disposable-signup abuse while we measure the real rate before committing budget to a paid verification API. Recommended as a low-risk experiment with a review-queue enforcement mode, not a hard block, until we have false-positive data.
To engineering: It's a static list, not a service — ship it as a versioned data file in the repo, loaded into config, exposed as a custom Laravel validation rule and a middleware-level soft-flag. No runtime dependency, no outbound calls, deterministic tests. Add a scheduled job (monthly) to diff against upstream and open a PR so the list doesn't silently rot. Keep the rule behind a feature flag and log matches rather than rejecting, so we can compute precision before we compute impact.