Weave Code
Resend Mailer Laravel Package
symfony/resend-mailer
Symfony Resend Mailer provides a Symfony Mailer transport for sending email through Resend’s API. Configure it with a Resend API key and use familiar Symfony Mailer messages, DSNs, and events to deliver transactional email from PHP applications.
Symfony Resend Mailer Bridge
Frequently asked questions about Resend Mailer
- Is symfony/resend-mailer a Laravel package or a Symfony package?
- It is an official Symfony package: a Symfony Mailer bridge that contributes a ResendTransportFactory and an HTTP transport for Resend's API. It is not a Laravel package and is not wired into Laravel's MailManager driver resolution, so a Laravel app needs custom glue. Laravel's Mail subsystem has been built on symfony/mailer since Laravel 9, which is why the bridge is architecturally adjacent but not drop-in.
- How do I install symfony/resend-mailer in a Laravel application?
- Install it with Composer, add your Resend API key as an environment variable, and register a custom mailer through Mail::extend or a small service provider that resolves the ResendTransportFactory and builds the transport. Then point a mailer in config/mail.php at that driver name. The surface is tiny, so a competent Laravel engineer can wire it up in hours, but budget extra time for tests, observability and secrets management.
- What DSN do I use to send mail through Resend with Symfony Mailer?
- The DSN format is resend+api://YOUR_API_KEY@default. In Symfony you set it as MAILER_DSN; in Laravel you pass the key to the transport factory or store the DSN on a custom mailer in config/mail.php. Treat the key as a secret from an environment variable or secret manager and never commit it inside a DSN in tracked config.
- Does Laravel 11 or 12 have a built-in Resend driver that makes this package unnecessary?
- Yes. Laravel 11+ ships a first-class Resend mail driver, and resend/resend-laravel exists as the vendor-blessed SDK path, so for a greenfield Laravel 11 or 12 service this bridge is redundant. Consider symfony/resend-mailer only for Laravel 9 or 10 projects, or when you deliberately want a Symfony-native transport and are comfortable owning custom MailManager glue. On modern Laravel, adopting it means maintaining bespoke code for a capability the framework already provides.
- Does symfony/resend-mailer support HTML and text bodies, attachments, CC/BCC and reply-to?
- Yes. The transport maps Symfony Email objects onto Resend's API, so HTML and text bodies, attachments, CC, BCC and reply-to headers work as they do with other Symfony Mailer transports. What it does not cover are Resend-specific extras such as batch sending, idempotency keys, tags and webhooks, which you would build on top of the Resend SDK separately.
- How do I test emails sent through the Resend transport with Mail::fake()?
- Mail::fake() replaces Laravel's mail manager, so messages sent through the Mail facade are intercepted before your custom Resend transport runs, and Mail::assertSent works as usual. Use a closure assertion to check recipients, subject, body and attachments. For real transport behaviour, use a scoped Resend test API key or a staging subdomain and assert the API response, and add one integration test that exercises the transport itself.
- Does symfony/resend-mailer handle Resend webhooks for bounces, complaints and opens?
- No. This package is a transport only: it sends mail. Resend's webhooks for delivered, bounced, complained and opened events, plus suppression-list management, batch sending, idempotency keys and tags, are not covered. Bounce and complaint handling must be built separately, typically as a signature-verified webhook endpoint with a persistence layer, and that is the part teams most often underestimate.
- What are the alternatives to symfony/resend-mailer for sending transactional email from Laravel?
- On Laravel 11 or 12 the built-in Resend driver is the lowest-effort option, and resend/resend-laravel wraps the official resend/resend-php SDK with Laravel-friendly APIs. You can also call resend/resend-php directly from a job or service if you want full control. Symfony applications should use symfony/resend-mailer directly, and if Resend's deliverability or feature set does not fit, keep a comparable transport from another vendor or SMTP as a fallback.
- Will upgrading Laravel or symfony/mailer break symfony/resend-mailer?
- It can. The bridge tracks symfony/mailer majors such as 6.4 and 7.x and PHP minor floors, and Laravel's Mail component depends on symfony/mailer, so a Laravel upgrade that bumps the Symfony Mailer version may force a bridge bump in lockstep. Pin an exact version, record the commit hash and license in your dependency register, and run the mail path in CI after every framework upgrade. Re-test your custom MailManager registration at the same time.
- Is symfony/resend-mailer maintained and safe to use in production?
- It is maintained inside the Symfony organisation and versioned alongside Symfony releases, but verify provenance yourself on Packagist and in the Symfony monorepo before approving it, since some directory metadata such as star counts and repository links is unreliable. Pin a version, keep the license file in your dependency register, and complete Resend domain verification with SPF, DKIM and DMARC in staging before production traffic. Because swapping transports changes sending reputation, keep a rollback transport behind a config flag such as MAIL_MAILER=smtp so cutover is a flip rather than a deploy.
Weaver
How can I help you explore Laravel packages today?