Resend

Resend is an API service for sending email from an application. It describes itself as "Email API for developers" and covers both transactional email, the event-driven messages such as order confirmations and password resets, and marketing broadcasts sent to a contact list.

Getting started

Register and verify a domain you own, then issue an API key. Sending from a shared domain is not possible; at least one verified domain is required.

What you can configure on a sending domain

• DMARC and BIMI
• Open and click tracking
• Enforced TLS, so mail only goes over encrypted connections
• A custom subdomain for the Return-Path
• The geographic region to send from: North Virginia, Ireland, São Paulo or Tokyo

Resend recommends sending from a subdomain such as updates.example.com rather than the root domain, to keep sending reputation separated by purpose and to signal to recipients what kind of mail this is. Several subdomains of the same domain can be verified and used for different purposes.

The developer surface

SDKs for Node.js, Next.js, Python, Ruby, Rails, Go, PHP, Laravel, Rust, Elixir, Java and .NET, plus a CLI and an MCP server. Delivery events can be pushed to your application over webhooks, and inbound email is supported.

The same team maintains React Email (resend/react-email), an open source library for composing email templates out of React components.

A third option

For transactional email in e-commerce and SaaS, SendGrid and Amazon SES were the practical choice for years. SendGrid brings depth of features and a long track record, at the cost of a deep configuration surface. Amazon SES is cheap and robust, but assumes you will build domain authentication and bounce handling yourself.

Resend arrived as an option that leads with the experience of the API, the SDKs, the dashboard and the documentation. In payments, the impression is close to Stripe arriving alongside the incumbent providers. Rather than rearranging the same features, it is designed around shortening the distance to sending the first message.

What people are adopting it for

The growth comes less from the feature count than from replacing how an email is built and sent in the first place.

Emails written as React components

Building email traditionally meant nesting HTML table tags to keep a layout from breaking, then interpolating values through a template DSL such as Handlebars. React Email lets that part be written as JSX components instead, with Tailwind CSS for styling and a local live preview. The same tooling and the same idioms as the web UI, so component reuse and code review sit on the same ground as ordinary frontend work.

A TypeScript-first SDK

The SDK is designed around TypeScript, so the values passed into a template are type-checked in the editor. A missing variable or a wrong type is caught at compile time rather than discovered in production as a blank space in a sent email.

Comfortable on serverless and edge runtimes

The API and SDK are light enough to drop into Next.js Server Actions, Vercel edge functions or Cloudflare Workers. Region selection means an edge deployment can still send from somewhere close to its recipients, and a Tokyo region is a practical advantage for work aimed at Japan.

Code-first observability

There is no drag-and-drop editor for marketers; the weight is on logs and events instead. Each message's content and status can be followed in the dashboard, and sent, delivered, bounced, complained and opened arrive in your application as webhook events. Investigating "the email never arrived" tends to end at the log.

Little standing between you and the first send

Verify a domain, issue an API key, send. That ease is partly the inverse of frustration with the incumbents: feature bloat, dated dashboards and strict account review became common complaints among developers, and Resend picked up the people those frictions pushed away.

Choosing a provider does not move the domain's responsibility

Whatever service you pick, deliverability still rests on the sending domain's configuration. Getting SPF and DKIM right and bringing them under a DMARC policy does not go away because you use Resend. That Resend surfaces DMARC and BIMI settings in its own dashboard reflects the same reality.

More care is needed when several systems send from one domain. Marketing automation tools, billing services and a sending platform like Resend each add an SPF/DKIM source that has to be aligned under a single policy.

Where it sits on a Shopify store

Order confirmations and notification emails from a Shopify store are sent by Shopify itself, so Resend covers what lies outside that: a custom back office, your own apps, notifications from a contact form.

Adding Resend to a Shopify project therefore adds one more route sending as the store's domain. Shopify's sender domain authentication and Resend's domain verification both have to hold up under the same DMARC policy.

We use Resend for notification email in our own products. Client work has been built mainly on SendGrid so far, but Resend is now on the table for new builds.

Developer experience was not the only reason to widen the options. We have had new account applications to email sending services turned down more than once without a stated reason, which stalled the start of work. The review criteria sit inside each provider and there is no way to be sure of meeting them from outside. So we treat not depending on a single sending platform, and keeping more than one option genuinely usable, as operational risk management rather than a preference.

Whenever an external sending platform is involved, we check SPF/DKIM alignment per route and run spam-placement tests, together with the DMARC work rather than separately from it.