Resend Mailer Laravel Package

Product Decisions This Supports

• Transactional email provider selection (build vs. buy). This is the "buy" side of the decision: a thin, Symfony-maintained bridge that lets you point symfony/mailer at Resend with a DSN. It removes the "we'd have to hand-roll a Resend HTTP client" objection from the ESP evaluation and collapses a multi-sprint integration into a config change plus DNS/domain verification.
• ESP migration and pricing leverage. Because Symfony Mailer abstracts the transport, adopting this keeps the provider decision reversible. Supports a roadmap where email vendor is a configuration concern, not an architecture commitment — useful when renegotiating with an incumbent ESP or running a bake-off between Resend, Postmark, SES, and Mailgun.
• Deliverability / failover architecture. Symfony Mailer's failover and round-robin transports mean this bridge can sit alongside a second provider, so "single ESP outage takes down password resets" becomes a solved problem rather than a risk item on the roadmap.
• Use cases it unblocks: password resets, receipts, invites, alerts, and notification fan-out — the standard transactional surface. Async sending via Messenger and testability via Symfony's null/in-memory transports come along for free.
• Explicit scope boundary for planning. It is a transport, not a Resend platform client. Audiences/Contacts, Broadcasts (marketing email), Domains, API-key management, and webhook ingestion for bounces/complaints/suppressions are not covered. If the roadmap includes lifecycle/marketing email or bounce-suppression hygiene, budget separate work (resend/resend-php or a custom webhook consumer) and don't let this package's existence imply the capability is "done."
• Laravel-specific note: Laravel runs on symfony/mailer internally, so this bridge can be registered as a custom transport. But the idiomatic path for a Laravel-first team is resend/resend-laravel (Mailables, Notifications, Blade, broader API coverage). Treat this package as the Symfony-native option and the fallback for Laravel teams that want a single transport abstraction across multiple frameworks.

When to Consider This Package

Consider adopting when:

• You are on a supported Symfony release and Resend is the chosen or shortlisted ESP — or you're on Laravel and want Resend behind the standard Mailer abstraction rather than a bespoke SDK call site.
• You want email sending configured by DSN/environment, with zero provider SDK types leaking into domain code, and the ability to switch providers without touching business logic.
• Your team is small and has no appetite for owning HTTP client glue, retry semantics, and API-version churn for a mail provider.
• You need failover or round-robin across two providers, or async delivery via Messenger.

Look elsewhere when:

• You need the Resend platform API — Audiences/Contacts, Broadcasts, Domains, webhooks. This bridge won't get you there; use resend/resend-php or resend/resend-laravel and call the API directly.
• You're Laravel-first and want ergonomics — Mailables, Notifications, local dev tooling, and better documentation live in resend/resend-laravel.
• You need sending features beyond the Mime→API mapping — per-message tags/metadata, scheduled send, batch endpoints, unusual attachment or custom-header handling. Verify parity explicitly; you may need a custom transport or direct API calls.
• You're outside Symfony/Laravel, or you need SMTP-only, on-prem, or data-residency guarantees Resend can't meet.

Due diligence gates before adoption (do not skip these):

• Treat the 10 GitHub stars as noise, not a signal. Symfony bridges are split-repo artifacts of the monorepo; their visibility and star counts are near-zero by construction while their effective adoption is the entire Symfony user base. Validate instead against the Symfony monorepo history, the bridge's release cadence, and whether it's covered by Symfony's release/support policy (align with your LTS).
• Confirm the version constraint matches your Symfony version, and pin it.
• Smoke-test the actual Mime→Resend mapping for your message shapes (attachments, HTML+text alternatives, reply-to, custom headers, tags) — the bridge surface is small, but the failure mode is silent.
• Keep a second provider DSN configured as failover from day one; it's cheap insurance and validates the abstraction claim.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, MIT-licensed, Symfony-maintained adapter that lets us send transactional email through Resend without building or owning an integration. Total cost of adoption is roughly a dependency, a DSN, and domain verification — days, not a sprint — and because it sits behind Symfony's mailer abstraction, our email provider becomes a configuration choice rather than an engineering commitment. That gives us migration speed and real negotiating leverage at renewal, and lets us run a second provider in failover so password resets and receipts don't depend on one vendor's uptime. It is deliberately not a marketing-email or deliverability-analytics solution; if lifecycle email or bounce suppression lands on the roadmap, that's a separate, separately-scoped effort. Headline risk is low and reversible; the main thing to avoid is over-reading the low GitHub star count, which reflects how Symfony splits its repositories, not real-world usage.

For engineering (one paragraph): It's a thin TransportInterface implementation that maps a Symfony Mime\Email onto the Resend HTTP API — no SDK types in application code, no new patterns, standard symfony/mailer DSN configuration. It composes with existing Messenger async sending and with failover/round-robin transports, and it's testable via the framework's null/in-memory transports. Constraints to plan around: it covers sending only — no webhooks for bounces, complaints, or suppressions; no audiences, broadcasts, or domain management. Ask is: pin the version, write one integration smoke test against a real send covering attachments and headers, and register a secondary provider transport for failover. Verify version compatibility and feature parity against the Symfony monorepo release notes rather than the split repo's star count.