- How do I install and configure the Mandrill mail driver in Laravel?
- Install it with composer require therobfonz/laravel-mandrill-driver; the service provider is registered through package auto-discovery, so no manual provider binding is needed. Add your credentials to config/services.php under a mandrill key with a secret value read from an environment variable such as MANDRILL_SECRET. Then set MAIL_MAILER=mandrill for the environments that should send through Mandrill and clear your config cache. Finally, verify and authenticate your sending domain in Mandrill (SPF/DKIM) before sending live traffic.
- Which Laravel and PHP versions does this Mandrill driver support?
- The driver targets Laravel 10 through 13 applications, with the 6.2.0 release adding Laravel 13.x compatibility. Because that support is forward-looking relative to framework GA, check the package's composer.json constraints with composer why-not before upgrading. If you are not yet on Laravel 13, 6.1.x remains a viable and lower-risk option. Also confirm the underlying mandrill/mandrill SDK resolves cleanly on your PHP runtime.
- Where should I store the Mandrill API key in a Laravel app?
- Keep the key out of source control and put it in config/services.php as the mandrill secret, sourced from an environment variable like MANDRILL_SECRET. The driver reads credentials from that config entry, so it works normally with config caching in production. Use separate Mandrill API keys per environment so staging cannot send to real recipients. Rotate the key in Mandrill and update the environment variable if it is ever exposed.
- Do I need to change my Mailables, notifications, or queued mail to use Mandrill?
- No. The package registers a Mandrill-backed transport inside Laravel's MailManager, so existing Mailable classes, notifications, and queued mail keep working unchanged. Only the configured mailer transport switches, which is why migration is mostly a configuration change plus a verified sending domain. If you are replacing another Mandrill integration, reconcile custom headers and tags before cutover.
- How do I roll back to SMTP if Mandrill has an outage?
- Keep the mailer selection environment-driven so rollback is a configuration change rather than a deploy. Define a fallback SMTP mailer in config/mail.php and retain valid credentials for it in every environment. If Mandrill fails, switch MAIL_MAILER to the fallback, clear the config cache, and re-verify delivery. Note that queued jobs already dispatched with the Mandrill mailer will still use it, so drain or retry those jobs deliberately.
- Can I send Mandrill templates, tags, and merge variables with this driver?
- The driver is a transport that hands messages to Mandrill's send API, so standard message features such as recipients, subject, headers, and attachments are handled through Laravel's normal Mailable API. Mandrill-specific extras like tags, merge variables, templates, subaccounts, and send-at timing depend on what the driver version exposes, so review its source and release notes rather than assuming full coverage. Where the driver does not expose an option directly, custom headers or a thin API call alongside it are common workarounds. Validate your specific feature set in staging before committing to the migration.
- Does the package handle Mandrill webhooks for bounces, opens, and clicks?
- No. This package is a send-side mail transport and does not implement Mandrill webhook handling. If you need bounce, open, click, or rejection events, configure Mandrill webhooks separately and handle them in your application or an event pipeline. Plan that work as a distinct task when scoping the integration, since deliverability monitoring usually depends on it.
- Is the mandrill/mandrill PHP SDK a maintenance risk?
- There is some risk: the driver depends on the legacy mandrill/mandrill SDK, which is released infrequently. Confirm the SDK installs and runs on your PHP version, and pin versions in composer.lock so an upstream change cannot surprise production. Mandrill itself is Mailchimp's transactional product with modest feature investment, so treat long-term platform commitment as a consideration alongside the technical fit.
- How should I test the Mandrill driver before switching production traffic?
- Start in development with a non-production Mandrill API key and send real messages to internal inboxes to validate delivery, headers, attachments, tags, and queued sending. Promote to staging with the same configuration shape you plan to run in production, then do a limited production canary before full cutover. Keep the mailer environment-driven throughout so you can revert instantly. Expect roughly one to two engineer-days including staging validation.
- Is this Mandrill driver actively maintained, and who supports it in production?
- It is a community-maintained package with a small contributor base and no vendor SLA, so bus factor and release cadence are worth weighing. Maintenance work is mostly tracking Laravel major versions and the upstream Mandrill SDK, so pin with a caret constraint and review release notes before minor bumps. Escalate deliverability, quotas, and API behavior to Mandrill/Mailchimp support, and driver bugs to the upstream repository. Document that split so on-call engineers know where to go.