Resend API Tutorial 2026: React Email + SDK en 5 Pasos para Dejar de Escribir HTML en Strings

# Resend API Tutorial 2026: React Email + SDK en 5 Pasos para Dejar de Escribir HTML en Strings

El 90% de los Desarrolladores Sigue Escribiendo Emails como si Fuera 2015

Todavía veis código así en proyectos que empezaron en 2024:

Lo pegáis en SendGrid, o en SES, o en un provider cuyo dashboard abre más pestañas de las que usáis.

*El problema no es que funcione mal. Es que estáis tratando el email como un hijo bastardo de vuestra aplicación. *

Lo escribís en strings, lo testeáis a ojo, y rezáis para que el cliente de correo de turno no se cargue el diseño. Y cuando algo se rompe, nadie quiere tocar ese código porque saben que modificar una línea de HTML concatenado puede reventar el template entero en Outlook o en Gmail.

Yo he estado ahí. He enviado emails con HTML concatenado, con Handlebars, con MJML. Todos duelen. Cada uno a su manera: el HTML plano porque es frágil y anti-testable; Handlebars porque introduces un sistema de templates externo que rompe el flujo de desarrollo; MJML porque, aunque mejora el diseño responsive, sigues manteniendo el template fuera de tu repositorio principal y dependiendo de un compilador separado.

Resend cambia eso. Y no es hype. Es arquitectura.

Hay un patrón que se repite en la industria del software: los equipos adoptan soluciones porque "siempre se ha hecho así" y no porque sean óptimas. Con el email transaccional pasa exactamente eso. Llevamos quince años concatenando strings de HTML, pegándolos en dashboards de terceros, y tratando el sistema de emails como un apéndice incómodo de la aplicación en lugar de como un componente más.

Resend no es el primer ESP que intenta resolver esto, pero sí el primero que lo aborda desde una premisa radical: que el email debe ser un ciudadano de primera clase en tu codebase, no un inquilino en un dashboard ajeno.

---

La Tesis Contraria: Menos Features es Mejor

El mercado de ESPs está lleno de plataformas que compiten por meter más cosas en el dashboard. Editores drag-and-drop, analytics con gráficos de tarta, segmentación de audiencia, A/B testing, plantillas visuales, flujos automatizados...

Resend apuesta por lo contrario.

❌ Enfoque legacy: HTML en strings, SDK hinchado, dashboard con 50 opciones que usas 3.

✅ Enfoque Resend: API minimalista, componentes React con TypeScript, deliverabilidad configurable desde el DNS.

La decisión de diseño clave de Resend no es técnica. Es filosófica. En lugar de construir workflows dentro de la plataforma, te dan un API limpia y te dicen: "la lógica de tu email vive en tu código, no en mi dashboard".

Esto implica menos features visuales. Pero para un equipo de ingeniería, *eso es una feature, no un bug. *

Pensadlo así: cuando usáis un ESP legacy, estáis delegando la lógica de vuestro negocio a una interfaz gráfica que no versionáis, que no testeáis, y que no podéis revisar en una pull request. Cada vez que alguien cambia un template desde el drag-and-drop del dashboard, ese cambio queda fuera del control de versiones, fuera del code review, y fuera de cualquier proceso de CI/CD.

Resend invierte esa jerarquía. El dashboard existe, pero es secundario. Sirve para ver logs, métricas y eventos. La fuente de verdad de tus emails es tu repositorio. Y eso, para un equipo de ingeniería que ya tiene procesos de code review, tests automatizados y despliegue continuo, es un cambio fundamental.

El coste oculto de los dashboards complejos

Hay un fenómeno que pocos equipos cuantifican: el tiempo perdido navegando dashboards. Cada vez que un desarrollador tiene que ir al ESP a buscar un log, revisar un template, o comprobar si un email se envió, está haciendo un context switch. Y los context switches cuestan entre 15 y 25 minutos de productividad perdida por interrupción, según estudios de productividad en ingeniería.

Un dashboard con 50 opciones no es gratis. Es deuda cognitiva que pagáis cada vez que alguien del equipo tiene que usarlo. Resend no elimina los dashboards — los reduce a lo mínimo indispensable: logs, métricas, configuración DNS. Todo lo demás vive en tu terminal, en tu editor, en tu pipeline de CI.

---

Lo Que Tu ESP Actual No te Dice

La deliverabilidad es el #1 dolor de cabeza de los desarrolladores que envían emails transaccionales. Estudios muestran que entre el 15 y el 20% de los emails legítimos nunca llegan a la bandeja de entrada. En campañas mal configuradas, la tasa puede dispararse al 30% o más.

La mayoría de los equipos culpa al ESP. Error. El 90% de los fallos de deliverabilidad vienen de:

Registros SPF, DKIM o DMARC mal configurados en el DNS.
Direcciones IP compartidas con vecinos que mandan spam.
Procesos de warm-up rotos o inexistentes.
Contenido del email que activa filtros de spam (enlaces sospechosos, exceso de imágenes, ratio texto/imagen desequilibrado).
Falta de consistencia en el volumen de envío (picos repentinos que los servidores de destino interpretan como comportamiento anómalo).

Tu ESP no puede arreglar tu DNS. Resend lo sabe, y por eso su proceso de onboarding empieza con una guía clara de configuración DNS, no con un tour del dashboard. No te venden un asistente mágico de deliverabilidad. Te dan las herramientas para que tú mismo la controles.

Y hay un detalle que pocos ESPs mencionan: la deliverabilidad no es un estado binario (llega o no llega). Es un espectro. Un email puede llegar a la bandeja de entrada, caer en spam, o ser rechazado en la puerta del servidor destino. Los tres casos tienen causas distintas y soluciones distintas. Resend te expone métricas para cada uno, pero no pretende resolverlos por ti, porque no puede. Nadie puede hacerlo desde fuera de tu infraestructura.

---

Paso 1: Audita tu Setup Actual

Antes de instalar nada, haced una cosa: id a vuestro dashboard del ESP actual y contad cuántas features usáis realmente.

Si estáis usando menos del 50% de lo que pagáis — y es casi seguro que sí — estáis pagando complejidad que no necesitáis.

Para emails transaccionales (resets de contraseña, confirmaciones de pedido, notificaciones) lo que necesitas es:

Enviar rápido.
Que llegue.
Poder testearlo.

Nada más. Ni dashboards, ni segmentación, ni A/B testing, ni flujos visuales de arrastrar y soltar.

Haced la auditoría en serio. Sentaos con el equipo y responded estas preguntas:

¿Cuántos de los emails que enviamos son transaccionales (no marketing)?
¿Cuántas features del dashboard usamos semanalmente?
¿Cuánto tiempo pasa un desarrollador a la semana navegando el dashboard del ESP?
¿Dónde viven los templates de email — en el repo o en el dashboard?
¿Podríamos migrar una template a React Email en menos de un día?

Si la respuesta a la 5 es "sí" y a la 3 es "demasiado", ya tenéis vuestro caso de negocio para migrar.

---

Paso 2: Configura la Autenticación DNS

Resend te da instrucciones paso a paso para configurar SPF, DKIM y DMARC. No las saltéis.

Sin SPF, tus emails parecen spam aunque el contenido sea legítimo. Sin DKIM, los servidores de destino no pueden verificar que el email no ha sido modificado en tránsito. Sin DMARC, le dices al mundo "haced lo que queráis con mis emails".

Dedicad 15 minutos a configurar bien los tres. Es el paso que más impacto tiene en deliverabilidad, y el que más equipos ignoran.

Cómo verificar que lo has hecho bien

Después de añadir los registros DNS, no confiéis en que "ya está". Usad herramientas externas para verificar:

Resend tiene una herramienta integrada que verifica estos registros en tiempo real. Usadla. No asumáis que está bien configurado hasta que la herramienta os dé el visto bueno.

Un error común: configurar SPF pero olvidar que si usáis otros servicios que envían emails en nombre de vuestro dominio (Google Workspace, HubSpot, etc.), todos deben estar incluidos en el registro SPF. Cada include: adicional suma complejidad, pero es necesaria para evitar falsos positivos de spam.

---

Paso 3: Escribe tu Primer Template con React Email

Aquí está la magia. En lugar de HTML en strings, escribes un componente React:

Esto no es HTML plano. Es TypeScript, con autocompletado, tipos, y testing. El template vive en tu codebase, se versiona con Git, y se rompe en compilación si falta una prop obligatoria.

React Email tiene más de 40.000 estrellas en GitHub. Es el estándar de facto para construir templates de email en el ecosistema JS.

Por qué los componentes React cambian las reglas del juego

Los templates de email tradicionales tienen un problema estructural: el HTML que funciona en navegadores no siempre funciona en clientes de correo. Outlook usa Word para renderizar HTML. Gmail elimina ciertas etiquetas y estilos. Apple Mail es más permisivo pero tiene sus propias peculiaridades.

React Email resuelve esto de dos formas:

Componentes que encapsulan las peculiaridades de cada cliente. El componente <Button>, por ejemplo, genera el HTML específico que funciona en Outlook, Gmail y Apple Mail. No tienes que saber que Outlook necesita <!--[if mso]> para tablas. El componente lo hace por ti.
Un compilador que optimiza el output. El comando email build genera HTML plano optimizado para clientes de correo, con los estilos inline que cada cliente necesita.

Además, React Email incluye un servidor de preview (email dev) que recarga en caliente y te permite ver el template en diferentes clientes simulados. Esto solo ya elimina el ciclo de "subo el template al ESP, envío un email de prueba, espero 5 minutos, veo que está roto, vuelvo a subir".

Testing con componentes

Otra ventaja que no tenéis con strings de HTML: podéis escribir tests unitarios para vuestros emails.

Esto es impensable con HTML concatenado o con templates en dashboards externos. Podéis integrar los tests de email en vuestro pipeline de CI y asegurar que cualquier cambio en un template no rompe la salida esperada.

---

Paso 4: Envía con Resend SDK en 5 Líneas

Así de simple es enviar ese template con Resend:

5 líneas. Comparadlo con el setup de SendGrid (10+ líneas de configuración de cliente + helpers de template + manejo de errores) o SES (firmar requests, configurar región, construir el objeto de destino, gestionar credenciales IAM).

El SDK de Resend soporta JavaScript/TypeScript, Python, Go, Ruby, PHP, Elixir y Rust. Todos con el mismo contrato de API. Todos con el mismo minimalismo.

El patrón de diseño: API como contrato

Lo interesante del SDK de Resend no es solo que sea minimalista, sino que expone el mismo contrato de API en todos los lenguajes. Si sabes usar el SDK en TypeScript, sabes usarlo en Python, Go, o Ruby. Esto simplifica enormemente los equipos poliglota o las migraciones.

Por ejemplo, en Python:

Misma estructura. Mismo modelo mental. La diferencia es que en TypeScript puedes pasar el componente React directamente; en otros lenguajes generas el HTML con el CLI de React Email y lo pasas como string.

---

Paso 5: Implementa Webhooks para Bounces

El último paso crítico. Resend envía webhooks con verificación de firma criptográfica:

Los webhooks con firma verificada son más seguros que los secretos básicos. Y os permiten reaccionar en tiempo real a fallos de entrega, sin tener que esperar a que alguien abra el dashboard.

Por qué los webhooks firmados importan

Muchos ESPs implementan webhooks con un secreto compartido que se envía como query parameter o header. Eso es vulnerable a ataques de replay y a spoofing. Si alguien intercepta la URL de tu webhook, puede enviarte eventos falsos.

Resend usa firma criptográfica HMAC-SHA256. Cada evento incluye un header resend-signature que es un hash del cuerpo del evento más un timestamp. Tu endpoint verifica esa firma antes de procesar el evento. Si no coincide, descartas el evento.

Esto os permite, además, reenviar eventos fallidos sin miedo a procesar duplicados: cada evento tiene un ID único, y podéis implementar idempotencia en vuestros handlers.

Eventos clave que deberías manejar

Resend expone varios tipos de eventos. Estos son los que importan para emails transaccionales:

| Evento | Cuándo ocurre | Qué hacer |

|--------|---------------|-----------|

| email.sent | El email se entregó al servidor destino | Nada, loguear |

| email.delivered | El servidor destino confirmó recepción | Nada, métrica |

| email.bounced | El email fue rechazado | Marcar bounce, no reenviar |

| email.complained | Usuario marcó como spam | Revisar contenido, considerar opt-out |

| email.opened | Usuario abrió el email | Métrica (solo si habilitas tracking) |

El webhook de bounced debería estar conectado a vuestro sistema lo antes posible. Cada bounce que ignoráis daña la reputación de vuestro dominio. Si un email rebota por dirección inexistente, eliminad esa dirección de vuestra base de datos inmediatamente. Si rebota por contenido (spam detection), revisad el template.

---

La Única Objeción que Vale la Pena Considerar

"Resend es demasiado nuevo. No tiene la reputación de deliverabilidad de SendGrid o SES."

Esto es lo que llamo el mito del ESP como guardián de la reputación.

Tu deliverabilidad depende de tu dominio y tu IP, no de la marca del ESP. Resend ofrece IPs dedicadas y alineación DMARC que te dan control total sobre tu reputación. Si configuras bien el DNS y haces warm-up, tu deliverabilidad con Resend es igual — o mejor — que con cualquier legacy.

Lo que realmente importa es que mandes emails que la gente quiere recibir, desde un dominio bien configurado, a un ritmo constante. El ESP es solo el conducto.

La evidencia empírica

He visto equipos migrar de SendGrid a Resend y mejorar su tasa de deliverabilidad. No porque Resend tenga magia, sino porque el proceso de migración les obligó a hacer lo que nunca habían hecho: configurar bien SPF, DKIM y DMARC, limpiar su lista de destinatarios, y establecer un volumen de envío consistente.

El ESP no es el factor determinante. Lo es:

La configuración DNS de tu dominio. Smartsheet, un proveedor de gestión de proyectos, migró a Resend y documentó públicamente una mejora del 4% en deliverabilidad. La razón principal: la configuración DNS alineada correctamente.
La higiene de tu lista de destinatarios. Cuantos más bounces tengas, peor reputación. Da igual si usas Resend, SendGrid o tu propio servidor SMTP.
La calidad del contenido. Emails con enlaces sospechosos, demasiadas imágenes, o texto que parece spam activarán filtros independientemente del ESP.

Resend no resuelve mágicamente estos problemas. Lo que hace es no interponerse en tu camino para resolverlos.

---

El Marco de Migración en 5 Pasos

Lo llamo El Puente de una Template. No necesitas migrar todo de golpe:

Audita: identifica si usas menos del 50% de tu ESP actual.
Configura DNS: SPF, DKIM, DMARC en tu dominio. Verifica con herramientas externas.
Migra una template: empieza con el email más simple (confirmación de registro). Escríbela como componente React, testéala con @react-email/render, y compárala visualmente con la versión actual.
Envía y verifica: manda por ambos proveedores y compara entregabilidad con una herramienta como Mail-Tester o MXToolbox.
Automatiza bounces: conecta los webhooks de Resend a tu sistema. Implementa idempotencia y manejo de errores.

Una template. Un fin de semana. Y validas el workflow completo antes de migrar el resto.

Estrategia de migración por fases

No necesitas mover todo de golpe. Puedes dividir tus emails en tres categorías:

Fase 1 (bajo riesgo): Emails transaccionales simples (bienvenida, confirmación de registro, cambio de contraseña).
Fase 2 (riesgo medio): Emails con datos dinámicos (facturas, notificaciones de pedido, alertas).
Fase 3 (alto riesgo): Emails con lógica condicional compleja, adjuntos, o múltiples idiomas.

Cada fase debe validarse con envíos reales durante al menos una semana. Monitorizad las tasas de apertura, bounces y quejas de spam comparándolas con el proveedor anterior.

---

El Email Debería Ser el Componente Más Aburrido de tu App

No el más odiado. No el que nadie quiere tocar. El más aburrido.

Con Resend y React Email, el email transaccional se convierte en una llamada API con tipos. Nada de dashboards externos. Nada de HTML en strings. Nada de rezar para que el diseño no se rompa en Outlook.

Tu código de email vive donde debe vivir: en tu repositorio. Testeable. Versionado. Con TypeScript.

El principio de "aburrimiento" en ingeniería

Hay un principio no escrito en ingeniería de software: los mejores sistemas son los aburridos. Un sistema aburrido es predecible, estable y no sorprende. Un sistema de emails aburrido es aquel que envía el mensaje correcto a la persona correcta en el momento correcto, sin fallos, sin sobresaltos, sin necesidad de que nadie lo supervise.

El email no debería ser una fuente de ansiedad en vuestro equipo. No debería ser ese código que nadie quiere tocar porque "si lo rompemos, dejamos de enviar notificaciones y el producto se para". Debería ser un componente más, con tests, con tipos, con logs, y con un pipeline de CI/CD que te diga si algo está mal antes de llegar a producción.

Resend y React Email no hacen milagros. Siguen siendo herramientas. Pero resuelven el problema de raíz: tratar el email como código, no como configuración.

Si todavía estáis concatenando strings de HTML para enviar emails, este es el momento de parar. No porque Resend sea la única opción. Sino porque merecéis una herramienta que trate el email como lo que es: una parte más de vuestra aplicación, no un problema aparte.

---

Este tutorial asume que trabajas con JavaScript/TypeScript y React. Los mismos principios aplican si usas Python, Go, Ruby, PHP, Elixir o Rust — todos tienen SDK oficial mantenido por Resend con el mismo contrato de API minimalista.