- How do I install and configure the MailerSend driver in Laravel?
- Run composer require mailersend/laravel-driver, which also pulls in the mailersend/mailersend PHP SDK as a transitive dependency. Then add a mailersend mailer block to config/mail.php, set MAILERSEND_API_KEY in your environment (ideally from a vault, not a committed .env), and switch MAIL_MAILER to mailersend. No application code changes are needed because the package registers a Symfony Mailer transport behind Laravel's existing MailManager.
- Which Laravel and PHP versions does mailersend/laravel-driver support?
- Check the composer constraint block in the repository's composer.json before installing, since the driver plugs into Symfony Mailer and Laravel's MailManager. Compare the required PHP range and Laravel minor against your own stack and confirm CI is green on your exact target versions. Also confirm whether the installed release implements Symfony's TransportInterface (the Laravel 9+ path) or the legacy Swift transport, because that determines compatibility with older applications.
- Does the MailerSend driver work with queued mail and notifications?
- Yes. Because the driver sits at the transport boundary, queued Mailables, markdown mail, and Notification mail all route through MailerSend without touching application code. You do need to redeploy or restart queue workers after changing mail configuration so they pick up the new mailer. Exercise your heaviest queued Mailables, including attachments, in staging before cutover.
- Do I need to change my application code to use MailerSend?
- No. The package registers a custom transport with Laravel's MailManager, so anything sending through the Mail facade or notifications keeps working unchanged. Per-message from and reply-to overrides should also survive the transport, but verify that with your real Mailables. It is a drop-in replacement at the transport seam, which keeps the decision cheap to reverse with a single environment change.
- Is mailersend/laravel-driver an official package and is it safe for production?
- Yes, it is the official MailerSend Laravel driver, maintained by the vendor and released under the MIT license, so issues can be escalated directly to MailerSend. Be aware the package has a small install base, roughly 92 GitHub stars and no dependents, so there is very little community blast radius to catch defects for you. The offsetting factor is that the code surface is small enough to audit in an afternoon, and the permissive license allows vendoring or forking.
- How does the driver handle API errors such as a 4xx from MailerSend?
- Errors from the API surface as transport exceptions, so a suppressed address or invalid recipient can look like a retryable failure on a queued message. Left unhandled, a queue worker may retry a permanently failing message until it exhausts its attempts. Validate the actual error taxonomy against MailerSend's response codes in staging and decide which failures should be non-retryable before going live.
- What is the fallback or alternative if the MailerSend driver causes problems?
- MailerSend publishes an SMTP relay, so you can route through the stock smtp mailer in config/mail.php with no extra dependency at all. That relay is also a sensible first migration step, proving SPF, DKIM, and DMARC and deliverability before you adopt the API driver. Because the driver is MIT licensed and small, forking or vendoring it is a third option if you need a patch.
- Does the driver batch recipients or make one API call per message?
- As an API transport it issues one HTTP call per message, so bursty or high-volume sending may not match MailerSend's batch endpoints or your current throughput. If volume matters, split mailers into separate streams, for example transactional versus lifecycle mail, so rate limits and sender reputations stay isolated. Measure actual throughput against your real send volumes during a low-volume canary phase.
- How do I test mail sending with the MailerSend driver?
- Keep the log or array mailer in your local environment, and note that Mail::fake() is transport-agnostic, so your existing test suite does not change at all. For integration confidence, point staging at a MailerSend sandbox domain and send a low-volume canary stream. That is where you check attachments, inline images, and from or reply-to overrides end to end.
- Does the driver support attachments, inline images, and templates?
- Attachments and inline images travel through Laravel's normal Mailable API, but how the transport passes them to MailerSend, streamed or base64-inlined, affects payload size, so test with your largest real files. Sending is the package's whole scope: stored templates, inbound routing, webhooks, and analytics live in the MailerSend API or SDK and need a separate integration. Scoping that template and webhook work as its own track keeps driver adoption from being blocked on it.