Send email from Next.js
Server actions and route handlers are the natural send points. Edge-runtime support varies by provider SDK.
Next.js apps span Vercel Edge, Vercel Node, Cloudflare Workers, and self-hosted Node. The right SDK depends on which runtime owns the send.
Send patterns
- Server actions for form-driven sends.
- Route handlers for webhooks and reusable send endpoints.
- React Email co-located with the send action.
- Idempotency keys derived from a stable form-submission ID.
Common mistakes
- Sending from client components leaks API keys.
- Edge-runtime incompatible SDKs fall back to Node functions silently.
- Long-running send loops in route handlers hit serverless timeouts.
- React Server Component env exposure if env vars are not server-only.
provider picks for Next.js
- 01
Resend
TransactionalBest React Email integration; first-party Next.js examples.
3,000/mo permanent, capped at 100/day, one domain · $20/mo for 50,000 emails - 02
Postmark
TransactionalStable SDK across runtimes; full webhook helpers.
100/mo developer plan · $15/mo for 10,000 emails - 03
Loops
Marketing TransactionalUnified transactional and lifecycle from one client.
1,000 contacts and 4,000 sends/mo on the Free plan · $49/mo for 5,000 contacts - 04
MailerSend
TransactionalModern API, edge-runtime friendly.
500/mo permanent · $7/mo for 5,000 emails
reading this as developers picking email infrastructure
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to sending email from Next.js, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.