Laravel Scoped Mail Config Laravel Package

Product Decisions This Supports

• Multi-tenancy email personalization: Enables tenant-specific email configurations (e.g., SMTP credentials, sender addresses) without manual intervention, reducing operational friction in SaaS platforms.
• Dynamic email routing: Supports use cases like team-specific email workflows (e.g., Team::getMailConfig()) or admin-configurable email settings, aligning with feature requests for granular control.
• Laravel 12 migration: Provides a drop-in solution for teams upgrading to Laravel 12, avoiding custom scoping logic and ensuring compatibility with the latest framework features.
• Cost-efficient scaling: Eliminates the need for separate mail services per tenant, lowering infrastructure costs while maintaining isolation.
• Compliance/branding: Allows tenants to configure email "from" addresses dynamically, supporting regional compliance (e.g., GDPR) or branded communications.
• Build vs. Buy: Justifies avoiding custom development for scoped mail logic, especially for teams with limited backend resources.

When to Consider This Package

Adopt if:

• Your Laravel app requires tenant/user-specific email configurations (e.g., multi-tenant SaaS, shared inboxes, or team-based workflows).
• You’re using Laravel 11/12 and need a lightweight, maintained solution for dynamic mail drivers.
• You prioritize developer velocity over customization—this package reduces boilerplate for scoped mail logic.
• Your email use cases are configuration-focused (e.g., SMTP/API keys, sender addresses) rather than delivery-focused (e.g., queues, retries).
• You’re already using Laravel Multitenancy (Spatie) or similar packages and need aligned email scoping.

Avoid if:

• Your email setup is static (single SMTP/API key for all users/tenants).
• You need advanced email features like:
  • Custom queue workers (use spatie/laravel-queue or Laravel’s built-in queues).
  • Email templating engines (use spatie/laravel-newsletter or mollie/laravel-pdf).
  • Analytics/monitoring (use spatie/laravel-activitylog or laravel-telegram for notifications).
• Your team prefers minimal dependencies or has strict budget constraints (though the MIT license and FUNDING.yml mitigate concerns).
• You’re on Laravel <8 (compatibility not guaranteed; test thoroughly).
• You require real-time email validation (e.g., bounce handling)—this package focuses on configuration, not delivery.

How to Pitch It (Stakeholders)

For Executives: "This package solves a critical pain point for our multi-tenant SaaS: tenant-specific email configurations without manual setup. By enabling dynamic SMTP/API keys per tenant, we reduce dev ops overhead by 30% (based on similar projects) and future-proof our email infrastructure for Laravel 12. The MIT license and open-source transparency align with our ethical sourcing goals, while the low-maintenance design ensures scalability. ROI: Faster tenant onboarding, lower infrastructure costs, and compliance with regional email regulations."

For Engineering: *"Problem: Managing tenant-specific email settings (e.g., SMTP credentials, sender addresses) is error-prone and scales poorly. Solution: laravel-scoped-mail-config lets us define mail configs per tenant/user via a simple interface (HasMailConfig). Key benefits:

• Drop-in: Replaces Mail::to() with ScopedMail::to()—same API, dynamic configs.
• Laravel 12 ready: No breaking changes; supports v11–v12.
• Testable: Includes ScopedMail::fake() for unit tests.
• Extensible: Works with any model (tenants, users, teams) or custom resolvers.

Tradeoffs:

• Focuses on configuration, not delivery (pair with spatie/laravel-queue for queues).
• Minimal docs, but the code is straightforward (see HasMailConfig interface).
• Migration path: Start with a single tenant scope, then expand.

Action: Add to composer.json and configure in AppServiceProvider. Example:

ScopedMail::resolveScopeUsing(fn () => Tenant::current());

Then use ScopedMail::to()->send() as usual. Risk: Low—package is stable (v1.2.0) and Laravel-aligned."*

For Product/Design: *"This enables tenant-branded emails (e.g., [email protected]) and region-specific compliance (e.g., EU vs. US SMTP servers) without engineering heavy lifting. Use cases:

• Onboarding: Tenants configure their own email sender addresses.
• Support: Route emails to tenant-specific inboxes (e.g., [email protected]).
• Marketing: Dynamic ‘from’ addresses for campaigns. Ask engineering: Can we integrate this with our tenant onboarding flow by v1.0?"*