- How do I install and set up jeffersongoncalves/laravel-mail in a Laravel app?
- Install it with composer require jeffersongoncalves/laravel-mail, then publish the config and migrations with php artisan vendor:publish and run php artisan migrate. Laravel package discovery registers the service provider automatically, so no manual wiring is needed. Once logging is enabled in the config, outgoing mail is captured immediately and you can start adding database templates or webhook endpoints.
- Which Laravel and PHP versions does this package support?
- The package targets Laravel 10 and newer on PHP 8.1+, matching Laravel 10's own platform requirements. It depends on well-maintained libraries such as spatie/laravel-translatable for template translations and tijsverkoyen/css-to-inline-styles for CSS inlining. Run your test suite against your exact Laravel minor version before deploying to production.
- How does automatic email logging work in Laravel Mail?
- The package listens to Laravel's native MessageSent event and writes each outgoing message to the mail_logs table, including recipients, subject, and body metadata. Because it hooks the standard Mail facade, your existing Mailables and notification channels keep working without changes. You can turn logging off in the config if you only want templates, tracking, or suppression lists.
- How do database-backed email templates with translations and versioning work?
- Templates live in the database and are rendered through Blade, with multi-locale content powered by spatie/laravel-translatable. Every content change automatically creates a new record in the template versions table, so you keep a full history of what was sent and when. The trade-off is that existing Blade email views must be moved into the database, which is the main refactor cost of adopting the package.
- How do the webhook handlers track delivery for SES, SendGrid, Postmark, Mailgun, and Resend?
- Dedicated handlers receive provider callbacks and verify each request with HMAC signatures before touching your data. Duplicate deliveries are detected through the provider_event_id column, so retried webhooks are ignored instead of double-counting events. Processed events update the matching log record and dispatch Laravel events for delivery, bounce, complaint, open, click, and deferral.
- Can I track opens and clicks with plain SMTP instead of a provider?
- Yes. Pixel tracking is provider-independent: the package injects a 1x1 transparent pixel and rewrites links, so open and click tracking works with plain SMTP or any other mailer. That is useful when your provider exposes no webhooks or when you want consistent metrics across a mixed-provider setup. Keep in mind that pixel-based opens are approximate, since many mail clients block remote images by default.
- How does the suppression list prevent sending to bad addresses?
- Hard bounces and spam complaints automatically add the recipient address to a suppression list, and the package blocks further sends to any suppressed address. This protects your sender reputation without requiring custom checks inside every Mailable. You can review and manage entries directly in the database or build your own admin screen on top of it.
- What tracking events and sending features does the package provide?
- Laravel events are dispatched on delivery, bounce, complaint, open, click, and deferral, so you can attach listeners for custom logic without modifying package code. A built-in notification channel and retry support help keep sending resilient when providers hiccup. Inline CSS, List-Unsubscribe headers, attachment storage, browser preview, and statistics cover the rest of the day-to-day workflow.
- How do mail tags and campaign reports work in version 1.4.0?
- Version 1.4.0 persists mail tags, set with tag() or the Envelope, onto the mail_logs table, and php artisan mail:campaign [tag] aggregates sent, delivered, bounced, complained, distinct opens and clicks, rates, and most-clicked links per campaign. The feature is gated behind laravel-mail.campaigns.enabled and is off by default. Add an index on the tags column and keep tag names consistent, otherwise report queries will table-scan as volume grows.
- Is it safe to upgrade from 1.3.x and run this in production?
- Upgrading is additive: one migration that adds a tags column to mail_logs plus a new config block, with campaign features disabled by default. On very large mail_logs tables, confirm the column addition and index build are online-safe for your database engine, or schedule a maintenance window. Also regression-test any plain-text alternatives, since 1.4.0 fixed text bodies being set directly on the message rather than passed as a view name.