- How do I install laravel-mails in a Laravel application?
- Install it with Composer using composer require vormkracht10/laravel-mails. The service provider is auto-discovered, so you only need to publish the config file and migrations, then run php artisan migrate. There are no API keys, accounts, or external services to provision, so a working setup typically takes well under a day.
- Which Laravel and PHP versions does laravel-mails support?
- The package builds on Laravel's native mail events and a standard Eloquent model, so it targets current Laravel releases, but you should confirm the exact constraints in its composer.json and CI matrix before upgrading. Because it hooks into internal Illuminate\Mail event payloads, re-verify compatibility after every major Laravel upgrade. Pin the version in composer.json and run your test suite against the new framework version first.
- Does laravel-mails work with queued mailables and notifications?
- Yes. It listens to Laravel's mail events, which fire in queue workers exactly as they do in web requests, so queued Mailables and notifications are captured the same way. Most production mail is queued, so test both the synchronous and queued paths during your proof of concept. Also check whether the package's own listener implements ShouldQueue, since that affects how much work happens inside the send event.
- How does laravel-mails capture outgoing email?
- It registers a service provider that listens to Laravel's Illuminate\Mail\Events\MessageSending and MessageSent events and writes the metadata into an app-owned database table. That means anything sent through the Mail facade, Mailables, Mail::raw, or notifications is recorded without touching your sending code. Mail sent outside Laravel's mailer, such as direct SMTP from a job or an external system calling an email API, is not captured, so treat it as an application-level audit trail rather than a network-level one.
- Can I preview and resend an email that laravel-mails logged?
- Yes, previewing stored messages and resending them is a core feature of the package alongside logging. Resending goes back out through Laravel's mail system, so your configured transport and from-addresses apply as usual. Be deliberate about who can trigger a resend, because replaying a password reset or one-time code can confuse recipients or create security issues.
- Where are email bodies and attachments stored, and will the table grow forever?
- Records are persisted in your application's database, and HTML bodies plus attachments are the expensive part of that storage. Row count grows linearly with mail volume, so without a scheduled prune this becomes a silent capacity problem. Check whether the package ships a prune command and retention config; if not, add a scheduled job that deletes rows past your retention window, and consider offloading attachments to a filesystem or S3 disk.
- Is it safe to store sent emails that contain personal data under GDPR?
- Storing sent mail creates a brand-new data store containing password-reset links, one-time codes, and customer content, which puts it squarely in scope for GDPR and your retention policy. Before production, define what is captured, add redaction for sensitive fields, restrict access to the table and any UI, and enforce a retention window. If you cannot redact or encrypt at rest, consider logging metadata only, or exclude specific Mailable classes.
- Can laravel-mails slow down or break mail delivery if the database is slow?
- The package writes on the send path, so a slow or unavailable database can delay or fail mail delivery if persistence happens synchronously inside the mail event. Verify empirically whether the listener is queued and whether errors are fail-open, meaning the mail still sends if logging fails. A safe rollout keeps logging behind an env-driven config flag so you can disable it instantly in production.
- Does laravel-mails support multi-tenancy and access control?
- The package stores mail in a single app-owned table, so if you run a multi-tenant application you will likely need to extend the model or add a global scope for a tenant column. Preview and resend features need authorization too: do not assume the package ships gates, and put your own policies or route middleware in front of anything that exposes stored messages. Plan this before enabling capture, because backfilling ownership onto existing rows is painful.
- Is laravel-mails actively maintained, and what are the alternatives?
- It is a single-vendor, MIT-licensed package with a small code surface, which keeps bus-factor risk manageable because you could fork and maintain it yourself in hours. Before adopting, check the release cadence and whether the latest tag tracks current Laravel versions. Alternatives are writing your own MessageSent listener that persists to a table you control, or relying on provider-side logs from SES, Postmark, or Mailgun, which also cover bounces and deliveries the package may not record.