Tu Setup Básico de Resend Falla en Producción. Aquí Está Por Qué
Tienes la API key. Enviaste tu primer email. Funciona en local.
Luego llegas a producción y empiezan los problemas reales.
Emails que se pierden sin error visible. Webhooks que no se procesan. Templates que explotan con datos inesperados.
El problema real del email no es enviarlo. Es garantizar que llega, que se procesa, y que sabes cuándo falla.
Esto es lo que el tutorial básico de Resend no te cuenta.
---
Patrón #1: Webhooks con Verificación de Firma
La mayoría de developers conectan el webhook de Resend directamente a su API sin verificar la firma.
Cualquiera puede hacer un POST a tu endpoint y simular eventos falsos.
❌ Enfoque peligroso:
✅ Verificación de firma con Svix (que usa Resend internamente):
Instala `svix` como dependencia. Resend firma todos los webhooks con este estándar.
El secret lo encuentras en el dashboard de Resend bajo tu webhook endpoint.
---
Patrón #2: Cola de Emails con Reintentos Inteligentes
Enviar emails directamente desde una Server Action o API route es el error más común en producción.
Si la llamada a Resend falla, pierdes el email para siempre.
El patrón correcto usa una cola de trabajos.
Implementación con Inngest
Resultado: Si Resend devuelve un error 5xx, Inngest reintenta automáticamente con backoff exponencial. Cero emails perdidos.
---
Patrón #3: Templates con React Email y Type Safety
El real problema de los templates de email no es el diseño. Es que explotan silenciosamente con props inesperadas.
La solución es tipar completamente tus componentes de React Email.
Con este patrón, un cambio en la interfaz del template rompe en compilación, no en producción a las 3am.
---
Patrón #4: Monitorización de Deliverability con Webhooks
Saber que enviaste el email no es suficiente. Necesitas saber si llegó.
Resend emite estos eventos via webhook:
→ email.sent — El email salió de Resend
→ email.delivered — El servidor destino lo aceptó
→ email.opened — El destinatario lo abrió (requiere tracking pixel)
→ email.bounced — Rebote permanente — elimina este email de tu lista
→ email.complained — Marcado como spam — acción urgente requerida
Ignorar bounces y complaints destruye tu reputación de dominio. Los ISPs como Gmail y Outlook penalizan dominios con tasa alta de complaints. Un complaint rate por encima del 0,1% activa filtros automáticos.
---
Patrón #5: Batch Sending para Notificaciones Masivas
Cuando necesitas enviar emails a miles de usuarios, no hagas un bucle con resend.emails.send en cada iteración.
❌ Enfoque que agota el rate limit:
✅ Batch con control de concurrencia:
p-limit controla la concurrencia. Promise.allSettled captura fallos individuales sin abortar el batch completo.
---
Variables de Entorno para un Setup Completo
Nunca hardcodees la API key. Nunca la incluyas en client-side code — Next.js server-only o Edge Functions exclusivamente.
---
Resumen: El Setup de Producción Completo
→ Verifica firmas en todos los webhooks con svix — seguridad no opcional
→ Usa una cola (Inngest, Trigger.dev, o BullMQ) — cero emails perdidos por fallos transitorios
→ Tipa tus templates con React Email — errores en compilación, no en runtime
→ Procesa bounces y complaints — tu reputación de dominio depende de esto
→ Controla concurrencia en envíos masivos con p-limit — respeta los rate limits
El email transaccional bien implementado es infraestructura invisible: nadie lo nota cuando funciona. Todo el mundo lo nota cuando falla.
Resend te da las herramientas. Estos patrones garantizan que las uses correctamente en producción real.
