- Does emailsherlock/email-guard-bundle work with Laravel?
- No. This is a Symfony bundle whose two public surfaces are a Symfony Validator constraint (VerifiedEmail) and a verify_email form option on Symfony's EmailType. Laravel ships its own Validator and no first-party Form component, so the Flex auto-registration, config/bundles.php entry, and form extension are all inert on a Laravel stack. What is genuinely reusable is the underlying engine, emailsherlock/email-guard-core-php, plus the policy semantics the bundle encodes.
- How do I install and configure email-guard-bundle in a Symfony app?
- Run composer require emailsherlock/email-guard-bundle; Symfony Flex registers the bundle automatically, otherwise add EmailGuardBundle to config/bundles.php. Then optionally create config/packages/email_guard.yaml with api_key, fail_open, timeout_ms, block_on, and review_on. Every key is optional, and without any config the guard runs local checks with the spec defaults. Note that these YAML keys only apply to Symfony, not to a Laravel config file.
- What is the difference between the local checks and the EmailSherlock API verification?
- Local checks cover the syntax profile, reserved TLDs, and 73k+ disposable domains, all evaluated offline with zero latency and no PII leaving your server. Providing an EmailSherlock API key adds live MX lookup, an SMTP probe, and a fresher disposable list. For a Laravel app, the local layer is the durable value because it is deterministic and has no third-party dependency at request time.
- What does fail_open do and should I leave it enabled?
- fail_open defaults to true, meaning if the EmailSherlock API is unreachable the local checks keep working and everything else passes, so your signup form never breaks because of the vendor's API. That is sensible for availability, but it also means SMTP or MX failures degrade silently and you may never notice the paid layer is not running. Log every decision, for example via the GuardDecisionEvent, and alert on fallback rates if you rely on the API.
- How do I block disposable email addresses in a Laravel FormRequest?
- Do not try to boot the Symfony DI container in Laravel; implement Illuminate\Contracts\Validation\ValidationRule instead and depend on email-guard-core-php directly. One rule class plus a service provider binding a configured guard singleton and a small config file reproduces the bundle's behaviour, so 'email' => ['required', 'email', new VerifiedEmail] works inside a FormRequest. Re-encode the bundle's policy defaults (fail_open, block_on, review_on, timeout_ms) as your own config keys so behaviour stays predictable.
- Which PHP and Laravel versions does email-guard-bundle support?
- The README does not state PHP or framework constraints, and the package targets Symfony rather than Laravel, so no Laravel version is officially supported. Check the composer.json PHP requirement and confirm whether email-guard-core-php runs without Symfony components installed before you commit. Because the package is pre-1.0, also expect config keys and semantics to change between minor releases.
- How can I test the guard without calling the EmailSherlock API?
- Omit the API key entirely, which puts the guard in local-only mode where syntax, reserved TLD, and disposable-domain checks run deterministically offline, so assertions are stable in CI. In Laravel, bind a fake or stub of your adapter in the container and assert the validation message for known-bad addresses. Also add tests for the fail_open path by faking a timeout or a 429 response from the client.
- What are the production risks of SMTP verification and sending addresses to the API?
- SMTP probing needs outbound port 25, which is blocked by default on AWS, GCP, Azure, and most PaaS platforms, so expect the richest check to be unavailable in production and, with fail_open on, that loss is silent. A synchronous in-request call with a timeout of around 800 ms lands on your most latency-sensitive endpoint, signup, so cache results and consider moving enrichment to a queued job. Sending raw email addresses to a third party on every uncached submit is also a PII egress question: confirm GDPR/CCPA processor terms, retention, and residency, none of which the README addresses.
- How do review_on verdicts and the GuardDecisionEvent work?
- review_on verdicts add no violation because validation is strictly allow-or-deny by design. To build a second gate, inject the EmailGuard service, call check($email), and branch on $result->needsReview() to hold the signup or require confirmation. The bundle dispatches a GuardDecisionEvent for every allow, deny, or review decision, which is a clean hook for logging, metrics, or your own storage, and a design worth copying into a Laravel adapter.
- Should I use this bundle or fork it, and what are the alternatives?
- The recommended path for Laravel is to depend on emailsherlock/email-guard-core-php and write a thin adapter of roughly one to two engineering days including tests. The bundle is MIT licensed, so forking is allowed if you want its ergonomics, but you would then maintain a fork of a zero-adoption package with a single maintainer who also publishes the spec, the core library, and the API. That concentration risk means availability and roadmap depend on one party, so keep an offline-only fallback and do not put the vendor API on the critical path of registration.