Weave Code
Filament Mail Log Laravel Package
asignua/filament-mail-log
A Filament plugin that records outgoing emails in your database and gives you a browsable log inside the admin panel, so you can inspect messages, recipients, and content without digging through server mail logs.
Filament Mail Log is a Filament plugin that captures every outgoing email sent by your Laravel application and makes it browsable from your admin panel. It stores recipients, subject, HTML and plain-text bodies, attachments and headers, so you can inspect exactly what was delivered without digging through logs.
- Filament resource to browse, search and filter logged emails
- View full HTML/text body, recipients and attachments
- Resend any logged email with one click
- Configurable retention and automatic pruning of old entries
- Works with Laravel's mailer and queues out of the box
Ideal for debugging transactional mail in production and staging.
Frequently asked questions about Filament Mail Log
- What does asignua/filament-mail-log actually do?
- It records every outgoing Laravel mail and exposes it as a read-only Filament 5 resource, so admins can browse, search and inspect messages that were queued, sent or failed. Each entry includes recipients, subject, HTML and plain-text bodies, and headers. Secrets such as signed links, tokens and passwords are redacted before storage, and HTML is rendered in a sandboxed preview.
- How do I install filament-mail-log in a Laravel app?
- Install it with Composer using composer require asignua/filament-mail-log, then publish and review the package config before enabling it in your Filament panel. Because it is a Filament plugin, the application must already have Filament 5 installed and configured. Check the repository README for the exact service provider or panel registration snippet for your version.
- Which Laravel and Filament versions are supported?
- The package targets Filament 5 and Laravel applications that run it; v1.0.1 specifically improved compatibility with stock Filament panels by switching iframe styling to inline styles. The provided release notes do not publish a formal compatibility matrix for PHP, Laravel or mail transport versions. Verify the constraints in composer.json and test in a staging panel before rolling out to production.
- How does redaction of tokens and signed links work?
- Redaction is configurable through redaction.path_prefixes and redaction.patterns, and it is applied before content is stored. In v1.0.1 a defect was fixed where Laravel verification URLs could keep the secret {hash} segment after redaction; path prefixes now strip every segment after the prefix. The ?email= query parameter is intentionally kept as personal data, not treated as a secret, so add your own patterns if that is unacceptable for your compliance posture.
- Where are the logged emails stored and is that storage encrypted?
- Mail is persisted in your application database through the package migrations, which is why database growth and retention planning matter. The release notes and overview do not state whether bodies are encrypted at rest, so treat that as an open question and confirm with your own review. If encryption is required, apply it at the database or column level rather than assuming the package does it.
- Can I control how long emails are kept?
- Yes, the package includes retention pruning so old log entries can be removed on a schedule you define. Email HTML bodies can grow storage quickly, so pair pruning with a documented retention policy and monitoring of table size. Run pruning as a scheduled command and confirm it fits your audit and privacy requirements.
- Is the HTML email preview safe from XSS?
- The preview is described as sandboxed and v1.0.1 moved iframe styling to inline styles for better stock Filament compatibility, but the supplied materials do not confirm CSP or sandbox attribute specifics. Email HTML can contain hostile markup, so review how the iframe is rendered and add Content-Security-Policy headers where possible. Treat preview hardening as part of your own security review, especially if untrusted external mail is ever logged.
- What should I do about records stored before the v1.0.1 redaction fix?
- Records captured before v1.0.1 may still contain leaked secrets such as verification link hashes, because the fix only affects new captures. Inventory existing rows, decide whether to purge them or re-redact them, and document the decision. After upgrading, validate password reset and email verification mails in staging before trusting the new behavior.
- Will logging slow down mail sending or bloat the database?
- The package captures queued, sent and failed status, which implies an ongoing write per message; the materials do not confirm whether capture is synchronous or queued. High-volume applications should test write overhead and preview performance with large HTML bodies. Plan retention, archival and database growth limits early so the log table does not become the bottleneck.
- How is access to the mail log controlled, and does it support multi-tenancy?
- The log is exposed as a read-only Filament resource, so access follows your existing panel authorization setup such as policies or gate checks. The provided release notes do not describe built-in multi-tenancy scoping or audit logging of who viewed which email. Because entries can contain PII and redacted secrets, restrict the resource to trusted ops and support roles and add your own audit trail if needed.
Weaver
How can I help you explore Laravel packages today?