Php Email Validator Laravel Package

Product Decisions This Supports

• Signup funnel integrity vs. conversion trade-off. The jump from 8,948 to 136,577 disposable domains (~15×) materially changes the blocking rate your funnel will see. This is a decision input for growth and support teams: how aggressive should signup filtering be, and what is the cost of a false positive versus a fake account. The release's false-positive protections (public-suffix exclusion, Tranco top-100k exclusion, typo detection, subdomain-of-allowlist exclusion, 237-domain allowlist covering ISPs, organisations and privacy relays like SimpleLogin and Proton Pass) are the actual product lever here — they let you adopt a much larger blocklist without blocking legitimate corporate or privacy-conscious users. That is a genuine "buy vs. build" argument: maintaining this filtering logic and allowlist yourself is a recurring, error-prone chore.
• Trial abuse and free-tier economics. Larger list coverage supports decisions about where to enforce disposable-email blocking: signup, trial start, promo redemption, or password reset only. isDisposableDomain() and block_subdomains let you apply different policies at different funnel steps without a second vendor.
• Fraud/security roadmap. isSpoofed() (homograph detection) opens up a security story beyond disposable addresses — impersonation in account recovery and support flows. getListStatistics() and the explainable checkDisposable() result (matched domain, source, subdomain match) give you observability for measuring filter quality, which is what you need to justify tightening or loosening policy later.
• Build vs. buy for list maintenance. Daily rebuilds on main with weekly patch releases, plus runtime sync (ListSynchronizer / email-validator sync) with atomic locked writes, append-only default, rejection of HTML/empty responses, and allowlist never written — this outsources an operational task (list curation) that would otherwise be an on-call burden. Adopting it is a decision to not staff that work.
• Platform scope. New CodeIgniter 4, CakePHP, Yii 2/3 and Phalcon 5 integrations mean this is no longer a Laravel-only dependency. If you run mixed PHP estates or anticipate a framework migration, this keeps the decision reversible and avoids per-framework email-validation logic diverging.
• Roadmap de-risking on performance. The OPcache-compiled index means the 15× larger list loads at no cost and adds no per-request memory — removing the usual objection that "bigger list = slower signup endpoint." Laravel 13 and Symfony 8 support signals the package tracks framework releases, which reduces the maintenance risk of depending on it.

When to Consider This Package

Adopt when:

• You have any self-serve signup, free tier, or trial, and fake/disposable accounts are a measurable cost (abuse, spam, deliverability damage, support load).
• You want disposable-email filtering as a first-class validation rule inside Laravel's validator (rule objects, Blade directive, Artisan commands, scheduled sync) rather than bolted-on API calls to a SaaS.
• You need an auditable, explainable decision (matched domain, source, subdomain match) for support and trust-and-safety workflows — a black-box API returning true/false is insufficient.
• You run multiple PHP frameworks and want one validation policy across them, including the framework-agnostic CLI (check|validate|sync|stats) for cron jobs and CI.
• You want to stop maintaining your own blocklist and allowlist, and are comfortable consuming weekly releases plus optional runtime sync.

Look elsewhere or defer when:

• You need real-time deliverability/SMTP verification, catch-all detection, or reputation scoring — this is domain-list matching plus homograph detection, not mailbox verification.
• Your risk model is primarily payment fraud or bot detection; this is one signal among several and shouldn't be the sole control.
• You can't operate a dependency that ships weekly. Adoption means owning an update cadence, and the ~15× larger list raises the probability of legitimate-domain false positives that will land in your support queue. If you cannot staff "add to lists.custom_allowlist, report upstream," you'll end up with a stale or over-permissive config.
• You are on a legacy PHP/Laravel version outside the supported matrix, or your deployment forbids the OPcache/file-based list (e.g., read-only containers without a writable sync path — evaluate sync.* config and file paths first).
• Regulatory constraints require a fully curated in-house list with contractual sign-off; the aggregator-derived portion, while filtered, may not satisfy that review.

Upgrade-specific cautions for the PM to flag to engineering: behavior changes are backward compatible at API level but not necessarily at product level — (1) custom_blocklist / addToBlocklist() now take precedence over the bundled allowlist, so your own additions can now override upstream protections; (2) the ~15× larger list will surface new blocks on real users; plan a canary/log-only rollout and monitor; (3) in Laravel, smtp.from_domain now reads EMAIL_VALIDATOR_SMTP_FROM_DOMAIN and custom typo mappings are now additive rather than replacing built-ins — both can silently change behavior in configured environments.

How to Pitch It (Stakeholders)

For executives: This upgrade makes our signup filtering substantially stronger at essentially zero marginal cost. Coverage of known disposable domains goes from ~9k to ~137k, and — critically — the package now systematically suppresses false positives: it excludes public suffixes, the most popular 100k domains, typosquats of major providers, and subdomains of a 237-domain allowlist covering ISPs, enterprises, and privacy relays like SimpleLogin and Proton Pass. That means we block more fake accounts without blocking real customers, which is the trade-off that has historically made teams avoid aggressive filtering. The list refreshes daily with weekly releases and can sync at runtime, so we stop paying engineers to curate blocklists. It's backward compatible, framework-agnostic (Laravel, Symfony, CodeIgniter, CakePHP, Yii, Phalcon), and adds no per-request memory or latency thanks to an OPcache-compiled index. Recommended decision: adopt with a logged-only canary for one to two weeks, then enforce at signup — and assign a named owner for allowlist exceptions so legitimate-user false positives get resolved quickly rather than becoming a support backlog.

For engineering: Low integration risk, high leverage. Detection is now explainable (checkDisposable() returns matched domain, source, and whether it matched via subdomain), plus isSpoofed() for homograph attacks and getListStatistics() for observability — instrument these so we can measure filter quality and defend policy changes with data. Laravel gives us rule objects, a Blade directive, Artisan commands, scheduled sync, and Laravel 13 support; the vendor/bin/email-validator CLI covers sync and stats outside the request cycle. Sync is append-only by default with atomic, locked writes, rejects HTML/empty responses, and never writes allowlisted domains — but we still need to pin versions and watch releases. Three behavior changes to verify before rollout: user-supplied blocklist entries now override the bundled allowlist; smtp.from_domain reads EMAIL_VALIDATOR_SMTP_FROM_DOMAIN; custom typo mappings are now additive. Plan the ~15× larger list as a behavior-change event, not a patch: log-only mode first, review the top blocked domains against our user base, then enforce.