Mail Intercept Laravel Package

Product Decisions This Supports

• Risk tolerance for non-production email. The core decision this package informs is not "which tool" but "how much are we willing to risk a staging or demo email reaching a real customer?" Mail Intercept converts that from per-developer discipline ("careful with the SMTP settings") into a config- and environment-gated control that reroutes every outbound message — Mailables, notifications, password resets — to one configured inbox. That is a risk-appetite decision with a one-line implementation, and it's the strongest reason to adopt.
• Build vs. buy for email capture in non-production. The realistic alternatives are a hosted capture service (Mailtrap, Mailosaur), a Dockerized SMTP sink (Mailpit/MailHog), or building interception into our own app. This is the near-zero-effort path: a Composer dependency, no container, no vendor account, no per-seat cost, no changes to existing mail code. If the team already runs Mailpit and is happy, the marginal value is small — decide on that basis, not on novelty.
• Where the email review loop lives. Redirect-only interception gets the message into an inbox someone can open; it does not by itself shorten the sign-off loop for marketing, support, design, or localization reviewers, because they still need access to that inbox. The published material also describes persisted capture with a browsable UI and resend — if that capability is present in the version we adopt, it is the product-visible differentiator and worth the dependency. Verify this before committing to the value story; the package description emphasizes redirection only, and the two claims lead to different business cases.
• QA and acceptance-testing strategy. Supports a decision to exercise real mail flows end to end in non-production — queued jobs, console commands, multi-step notification sequences — without mocking the mailer. It complements Mail::fake() rather than replacing it: fakes stay the cheap choice for logic-only tests, this covers the manual and content-review gap fakes cannot reach.
• Roadmap and upgrade sequencing. Release 1.1.0 is a Laravel 13.x compatibility bump (via laravel-shift) with no stated API, config, or behavioural change. That's a genuine input to "can we schedule the Laravel 13 upgrade this quarter?" — it removes this package as a blocker. It does not, by itself, justify the upgrade.
• Use-case fit. Strong for staging/demo safety, seeded and demo data, transactional-email content review, and manual QA of mail triggered by background workers. Explicitly out of scope for deliverability, bounces, inbox placement, and spam scoring — those belong to the ESP.
• Dependency posture. 114 stars, zero dependents, single-maintainer organization, MIT. Treat it as a tactical convenience in non-production, not a load-bearing platform dependency, and keep it off any path where a support SLA or release-train guarantee matters.

When to Consider This Package

Adopt when most of the following hold:

• The application is Laravel and sends through the framework's native mail layer (Mailables, notifications, Mail::raw), so the interception point is actually on the send path.
• The primary need is safety: an enforced, environment-gated default that prevents staging and demo mail from reaching real recipients.
• You want zero new infrastructure — no Mailpit container, no Mailtrap account, no third-party egress from staging — and accept a redirect inbox as the trade.
• Someone owns the destination inbox and non-engineers can get to it, or you have confirmed persisted capture and a review UI exist and are usable by non-developers.
• You can commit to strict environment gating (interception impossible in production), authorization on any review surface, and a retention plan for anything stored.
• You want to exercise real, unmocked mail flows — queued mail through a real worker, notifications, console-triggered sends — without touching application code.

Look elsewhere, or treat as insufficient on its own, when:

• You need SMTP-level capture from non-Laravel services, external cron jobs, or third-party systems. This package only sees mail sent through Laravel's mailer; vendor SDK calls (Postmark, Mailgun, SES) bypass it entirely.
• Volume is high or the environment is shared. Persisting every message needs an index and a pruning job; a streaming SMTP sink handles churn with less operational overhead.
• Privacy or compliance exposure exists. Redirected or captured mail contains real-looking PII and live reset tokens. If staging data is production-derived or the review surface is broadly reachable, confirm acceptability first and put it behind authorization.
• You need deliverability tooling — bounce handling, SPF/DKIM validation, spam scoring, inbox placement.
• The team isn't on Laravel, has heavily customized transports, holds a policy against third-party packages in the mail path, or needs a vendor-backed support guarantee.
• Queue workers can't be relied on to carry the env flag. The failure mode is silent pass-through — real email to real addresses — discovered by customers, not by monitoring.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed addition that eliminates a recurring class of incident — test or staging email reaching real customers — by redirecting every outbound message to a single safe inbox in the environments we choose. It requires no infrastructure, no vendor contract, no per-seat fee, and no changes to existing application code. Release 1.1.0 is purely a Laravel 13 compatibility bump, so adopting it will not hold up our framework upgrade. Risk is low and contained to non-production, provided we gate interception strictly by environment, authorize any review surface, and set a retention policy on stored messages. I'd position it as a tactical quality-of-life control on the email surface — a safety default, not a strategic platform bet — and I'd validate the "reviewers can inspect emails themselves" benefit before repeating it, since the package's documented behaviour is redirection rather than a full review workflow.

For engineering: kirschbaum-development/mail-intercept hooks Laravel's outbound mail path in non-production and reroutes everything — Mailables, notifications, and framework-level sends — to a configurable address, toggled by config or an environment variable, with no application code changes. Composer install, publish config, set the gate explicitly: a few hours of real effort, most of it spent on policy and config review rather than code. 1.1.0 is a laravel-shift compatibility commit — no API changes and no migration from 1.0.1 — but diff the constraint and any published config before vendor:publish --force. Before rollout, do three things: (1) add a CI or boot-time assertion that the intercept flag is set on every queue worker and that real delivery is disabled wherever it's undesired — the failure mode here is silent pass-through, so it must fail loudly in CI rather than in a customer's inbox; (2) explicitly exercise the interception paths — synchronous mail, queued mail through a real worker, notifications, Mail::raw, CC/BCC, and multi-mailer setups, which may only wrap the default mailer; (3) confirm whether the package persists messages or only redirects, and if it persists, index the capture table, schedule pruning, and put any review UI behind auth. Pin to ^1.1, own the Laravel-major upgrade path, and keep a regression test proving interception works so a package defect surfaces in our pipeline, not in a customer's inbox.