Mailcheck Laravel Package

Product Decisions This Supports

• Signup-funnel UX: nudge vs. block. The package's core value is not "is this email valid" but "this looks like a typo — did you mean gmail.com?" That's an inline suggestion decision: do we hard-reject malformed domains, or show a one-click "Did you mean…?" prompt and let the user proceed? This package makes the soft-nudge pattern cheap to test.
• Deliverability and sender-reputation investment. Bounce rate is a shared cost across the whole sending domain. A typo-catching step at capture reduces hard bounces from gnail.com/hotmial.com-class mistakes, which protects IP/domain reputation for every other email you send.
• Cost per acquired user. Fewer undeliverable addresses means fewer wasted welcome emails, fewer SMS/email verification calls to a paid API, and fewer accounts that are silently dead on arrival.
• Data quality for CRM/analytics. Fewer typo addresses entering the warehouse means cleaner funnel metrics, fewer "unreachable" segments, and less churn noise attributed to the wrong cause.
• Build vs. buy vs. skip. The underlying logic is a small, well-understood heuristic (edit distance against a list of common domains). The realistic options are: adopt this wrapper, vendor ~a few hundred lines in-house, or skip and rely on double opt-in. This package is the cheap "try it" option before committing engineering time either way.
• Onboarding friction budget. Whether to spend a micro-interaction at signup to protect downstream email metrics — a trade-off you can now measure with an A/B test rather than argue about.
• Where in the stack the check lives. Client-side (instant feedback, easily bypassed) vs. server-side validation rule (authoritative, no layout shift). Supporting a Laravel validation rule makes the server-side option a configuration change rather than a frontend project.

When to Consider This Package

Good fit when:

• You have a consumer/high-volume self-serve signup form where typo'd domains are a meaningful share of failures, and you're on a Laravel stack already.
• You want the suggestion UX, not verification — you're optimizing for a friendly nudge and you still intend to send a confirmation email.
• You want a low-blast-radius experiment: a validation rule you can feature-flag, A/B against control, and roll back in a deploy.
• Your team is small and one afternoon of integration beats a design + frontend + server ticket.
• Your current baseline is weak (regex-only validation, no double opt-in) so even a crude domain heuristic is a clear improvement.

Look elsewhere / deprioritize when:

• You need actual deliverability or existence checks (MX/SMTP probe, disposable-domain blocklists, role-account detection, spam-trap detection). This package does not do that; you need a verification vendor (NeverBounce, ZeroBounce, Kickbox, etc.) or an SMTP-level check — ideally at or after signup, not in the form.
• You're B2B/enterprise: users type their corporate domain, which is by definition not in any "common domains" list, so the suggestion engine adds noise and risks false corrections on legitimate unusual domains. False positives here are worse than typos.
• Maintenance risk is unacceptable. Six stars and zero dependents means effectively no community, no de facto security review, and no guarantee of Laravel-version compatibility. If your org requires a supported dependency with an SLA, this fails procurement.
• You need auditable, deterministic behavior — you'll want to own the domain list and the distance threshold yourself rather than inherit someone else's.
• Locale/international exposure: domains with IDN/Unicode, country-specific providers (*.co.uk, *.com.br), and non-Latin local-parts need a maintained list; a stale list produces confident wrong suggestions.
• You already have a strong verification pipeline with double opt-in and bounce webhooks — the marginal gain here is small relative to the added dependency.

Mitigation if you adopt: treat it as a replaceable heuristic, not infrastructure. Wrap it behind your own EmailSuggestionService interface so you can swap in a vendored copy or a paid API without touching call sites, and pin/audit the dependency.

How to Pitch It (Stakeholders)

To executives (30 seconds): At signup, a predictable slice of users mistype their email domain — gmail becomes gnail, hotmail becomes hotmial. Those accounts never receive a welcome email, never activate, and the bounces degrade the reputation of the domain we use to email everyone else. This package adds a "Did you mean gmail.com?" prompt at the moment of typing. It's a UX change, not a new vendor: no PII leaves our systems, no new contract, minimal engineering. Expected impact is a measurable reduction in signup bounce rate and fewer dead accounts; we can A/B it in a week.

To engineering: It's a small Laravel package wrapping a well-known typo-suggestion heuristic — edit distance against a curated list of common email domains — exposed as a validation rule / helper. Two integration paths: a server-side rule (simple, authoritative, no frontend work) or an endpoint the form calls for live suggestions (better UX). Recommendation: start server-side behind a feature flag. Caveats to flag: low community adoption (6 stars, no dependents), so budget an hour to review the source and the license; if it's more than a few hundred lines, consider vendoring it into app/ and owning it. Do not treat its output as validation-of-existence — it's a suggestion, and it must never hard-block a user whose domain we simply don't recognize. Wire it so failure is non-fatal and falls through to normal validation.

To design/UX: The suggested interaction is a non-blocking inline hint with a one-tap "use suggested address" — never a modal, never a rejection. Users with legitimate unusual domains must be able to submit unchanged in one click.