Product Decisions This Supports
- Signup abuse & trial-farming policy. Whether to add a disposable-email gate at registration, and how strict it should be (hard block vs. silent flag vs. require email verification). This package gives you the cheapest possible first version of that gate: an MIT-licensed, framework-agnostic PHP check with a bundled blocklist and optional MX/DNS validation — no vendor contract, no per-call cost, no PII leaving your infrastructure.
- Build vs. buy for trust & safety. Three options sit on the table: (a) roll your own regex/blocklist, (b) adopt an OSS library like this, (c) buy a commercial verification API (Kickbox, ZeroBounce, DeBounce, UserCheck). This package is the credible "option b" — it lets you ship a v1 and instrument real false-positive/false-negative rates before committing to a vendor's per-verification pricing or a maintenance burden you own forever.
- Where in the funnel the check belongs. Usable at registration, at trial start, at promo/referral redemption, on lead-gen and newsletter forms, or as a batch job over an existing user table. Because it's a plain library (not a SaaS API), you can run it inline at signup and backfill your historical user base in a queue job — useful for scoping whether the problem is historical or ongoing.
- Roadmap sequencing of an abuse-prevention workstream. If disposable-signup volume is a known but unquantified complaint, this is a low-cost spike to measure the problem (e.g., "what % of last quarter's free trials used a throwaway domain?") before you fund a larger identity/verification epic. It converts an anecdote into a number you can put in a planning doc.
- Free-tier and credit economics. Disposable addresses are a leading indicator of multi-accounting, credit abuse, and referral fraud. A pass/fail signal here feeds directly into decisions about whether to gate free tiers behind verified email or a payment method.
- Deliverability and list health. For marketing/CRM-owned decision-making: suppressing disposable addresses at capture protects sender reputation and reduces bounce rate, which is a shared metric with lifecycle/email ops.
When to Consider This Package
Adopt when most of the following hold:
- You're on PHP/Laravel and want the check in-process — no vendor account, no procurement, no per-call cost, no sending user email addresses to a third party. This matters if you're privacy-sensitive (GDPR-conscious data-minimization story is easy: only the domain is evaluated, and optionally resolved via DNS).
- You want a v1 filter, not a verdict. It's a filter: a blocklist of known disposable domains plus an optional MX-record check. That's the right tool for de-prioritizing or soft-flagging, not for permanently banning users.
- The requirement is narrow: "is this a throwaway domain?" If you also need role-account detection (
admin@, noreply@), catch-all/accept-all detection, typo/suggestion detection, or deliverability scoring, this doesn't cover it.
- You're comfortable shipping a thin integration shim. It's framework-agnostic — there's a Symfony bundle, but for Laravel you'll write a small custom validation
Rule wrapping the checker (roughly a few dozen lines) and register it in a service provider. Cheap, but it's your code to own, and it needs a test.
- List staleness is acceptable between releases. The blocklist ships inside the package, so freshness is tied to your Composer update cadence, not a live feed. If your team already runs scheduled dependency updates, this is fine. If it doesn't, the blocklist will quietly rot.
- You're willing to accept network-dependent latency if you enable MX checks — add a timeout, cache results per domain, and never put it on a synchronous path where DNS hiccups become signup outages.
Look elsewhere when:
- You need Laravel-native DX and a community-maintained, frequently refreshed list.
Propaganistas/Laravel-Disposable-Email is the more idiomatic Laravel choice and wraps an actively curated domain list; a purpose-built validation rule beats a generic library plus a shim. Weigh this seriously — with ~274 GitHub stars, an MIT license, a recent release, but effectively zero Packagist dependents reported, this package's ecosystem footprint is thin, and "thin footprint" means fewer people hitting the edge cases before you do.
- You need real-time accuracy at scale. Commercial APIs update continuously and add catch-all, greylist, spam-trap, and toxicity signals. If deliverability is the primary driver (e.g., a large outbound email program), a per-verification API is the right buy.
- You need a decision, not a signal. If the business wants "block all disposable emails, guaranteed," no static blocklist delivers that; only verification (send a code/link) does. Don't let a library purchase substitute for a verification-flow decision.
- Hard latency/availability constraints — a purely synchronous signup path with no tolerance for DNS lookups should disable MX checking, which reduces the library to a static blocklist comparison, at which point a 50-line local array check may be all you actually need.
- False positives are very expensive for you (e.g., a B2B product where a prospect's domain could plausibly appear on a list, or a market with heavy shared-domain usage). Treat adoption as a scoring input only.
How to Pitch It (Stakeholders)
For executives (one paragraph): We have a suspected but unquantified problem with throwaway email addresses inflating signups, free-trial consumption, and referral abuse. Rather than contracting an email-verification vendor at per-check pricing, we can validate the size of the problem for effectively zero marginal cost using an MIT-licensed open-source PHP library that runs entirely inside our own application — nothing is sent to a third party. It's a two-to-three-day integration including a custom Laravel validation rule, tests, and instrumentation. The deliverable isn't just a filter; it's data — the percentage of signups and trials using disposable domains, plus a false-positive count — that tells us whether to invest further (verification flow, vendor API, or gating free tiers behind a payment method) or declare the risk immaterial and stop. Decision requested: approve the spike, with the explicit understanding that we are not committing to this library as the long-term answer.
For engineering: Integrate as a Laravel validation rule + a queued backfill job. Keep the disposable check non-blocking by default — record a flag on the user/lead, and let product decide enforcement per surface. Disable or tightly timeout and cache the MX/DNS check; never let a resolver timeout fail a signup. Pin the package version, add it to the scheduled dependency-update rotation (the blocklist freshness is entirely a function of our update cadence), and write a test that asserts the rule's behavior against a handful of known-good and known-bad domains so a future Composer bump can't silently change enforcement. Wrap the library behind our own interface so swapping to Propaganistas/Laravel-Disposable-Email or a commercial API later is a one-file change. Note the maintenance risk up front: modest adoption footprint and a bundled (not live) domain list.
Instrumentation to agree on before launch: disposable-domain block rate at signup, trial-to-paid conversion for flagged vs. unflagged cohorts, false-positive reports from support, and bounce rate on marketing sends. If flagged users convert like everyone else, the flag is wrong and we should turn it off.