Email Guard Bundle Laravel Package

Product Decisions This Supports

• Feature decision — email quality gating at signup: Adds a validation layer beyond Symfony's Email constraint, catching addresses that are syntactically valid but non-deliverable (disposable domains, reserved TLDs like .invalid, junk profiles). This directly affects signup form acceptance, activation rates, and downstream email deliverability metrics.
• Build vs. buy: The local check engine (syntax profile, reserved TLDs, 73k+ disposable domains) runs with zero latency and no API dependency. That is the reusable core of a "good email" policy. Buying this replaces building and maintaining your own disposable-domain list — a maintenance burden that decays quickly if unowned.
• Roadmap sequencing — enforcement posture: block_on: ['invalid', 'disposable'] with review_on: [] lets you ship a soft policy first (block only the obvious junk, queue ambiguous cases for review) and tighten later without a rewrite. This is a configuration decision, not an engineering project.
• Risk decision — API dependency posture: fail_open: true and timeout_ms: 800 are defaults that encode a product stance: never let a third-party verifier break your signup funnel. That is a deliberate trade of false-negative tolerance for uptime.
• Vendor concentration: The live checks (MX lookup, SMTP probe, fresh disposable list) are gated behind an EmailSherlock API key. Choosing this package is effectively choosing that vendor for real-time verification. Worth a conscious call, not a default.

When to Consider This Package

Adopt when:

• You are on Symfony. This is a Symfony bundle (Flex auto-registers it, config/bundles.php, EmailType form option). On Laravel it does not drop in — the verify_email form option and constraint wiring are Symfony-specific. For a Laravel codebase, evaluate emailsherlock/email-guard-core-php directly and write a thin Laravel validation rule around it, or look elsewhere.
• Signup/lead-capture forms are a meaningful funnel and junk addresses are measurably polluting your database, CRM, or email sender reputation.
• You want the local-only path first (no API key, no vendor onboarding, no cost) and the option to add live verification later behind the same interface.
• You can tolerate fail-open behavior: unreachable API means addresses pass rather than fail.

Look elsewhere or defer when:

• Maturity signals are thin: 0 stars, 0 dependents, single maintainer, and a release dated 2026-06-19. Low star count is not disqualifying for an internal utility, but it means no community backstop — budget for reading the code and owning the integration yourself.
• Your real need is bulk list hygiene (verifying an existing database of 200k addresses) rather than at-submit gating. That is a batch job, not a form constraint.
• You require a fail-closed policy (reject when verification is unavailable) — the defaults and framing here are explicitly the opposite.
• Your threat model includes sophisticated signup abuse (bots, SMS/email farms). Disposable-domain lists help, but this is not a fraud or rate-limiting solution and should not be pitched as one.

How to Pitch It (Stakeholders)

For executives: A small, low-risk integration that stops junk email addresses at the form, before they enter our CRM and sender reputation. Local checks are free, instantaneous, and require no vendor contract; live verification is opt-in via an API key. The default configuration fails open, so it cannot take down signup. Cost is near zero and the blast radius is a single form field.

For engineering: A Symfony bundle layering on emailsherlock/email-guard-core-php. Provides a VerifiedEmail constraint and a verify_email form option. Config is one YAML file; adding it to a field is one line. Local checks (syntax profile, reserved TLDs, ~73k disposable domains) run in-process with no network call; MX/SMTP probing is gated behind an optional API key with an 800ms timeout and fail-open default.

Honest caveats to state up front: The project is early — zero stars and zero dependents means we are the first real adopter and should expect to read the source and possibly pin a version. It is Symfony-only; if any of our surfaces are Laravel, we would need the underlying core package instead. And it is email quality, not abuse prevention — do not let it substitute for rate limiting or bot defenses.