El Email API Parecía un Commodity Resuelto — Hasta que un Startup Open-Source una Librería de React y un Endpoint REST
En 2026, enviar un email transaccional está considerado un problema resuelto. AWS SES te da capacidad infinita. SendGrid te da décadas de infraestructura. ¿Por qué ibas a mirar a un proveedor nuevo?
*El problema no es la capacidad. Es el tiempo que pierdes antes de enviar el primer email. *
SES te obliga a pelear con IAM, verificación de dominio en una consola separada, y un sistema de plantillas JSON que nadie quiere tocar. SendGrid tiene un dashboard de hace dos legislaturas.
Resend apareció en 2023 y flipó el guion: en vez de competir en gigavatios de throughput, compite en minutos hasta tu primer email enviado. Una API key. Un SDK. Y una librería open-source, React Email, que sustituye el HTML en strings por componentes React tipados.
Este tutorial es el recorrido completo en 5 pasos: desde la verificación de dominio hasta los webhooks de entregabilidad. Sin humo.
El Error de Competir por Tamaño de Tubería
La sabiduría convencional dice que en infraestructura de email, gana quien tiene más capacidad bruta. Es la lógica de "mi cañería es más ancha que la tuya".
Resend demuestra lo contrario: la capa SMTP/API es cada vez más intercambiable. Lo que gana adopción es el workflow alrededor — onboarding instantáneo, SDKs limpios, y React Email como capa de plantillas.
Observad la jugada completa:
React Email es open-source y funciona con cualquier proveedor.
Pero establece un camino por defecto hacia la API de Resend.
La librería es el funnel. La API es la monetización.
Eso invierte el playbook de infraestructura clásico. No es un moat de capacidad. Es un moat de ecosistema.
Por Qué el Moat de Ecosistema Importa en Email
El email API es una decisión que los equipos toman una vez y no vuelven a tocar. El coste de cambiar es alto. ¿Quién va a re-verificar dominios, re-configurar SPF/DKIM y re-escribir plantillas?
El jugador que captura el workflow antes de que toques la API gana la adopción silenciosa. No gana porque su tubería sea más ancha. Gana porque es el primer yo que te encuentras.
Y el primer yo que te encuentras en Resend, es una experiencia sin fricción. Ahí está la diferencia.
Paso 1: Verificación de Dominio con SPF y DKIM
Antes de enviar el primer email, Resend te pide verificar un dominio. Es el mismo requisito que SES o SendGrid. La diferencia está en cómo se siente.
En Resend creas un recurso de dominio con una llamada:
```js
import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
const { data, error } = await resend.domains.create({
name: 'acme.com',
region: 'eu-west-1',
});
```
La respuesta te devuelve los registros DNS exactos que necesitas (SPF y DKIM). Los copies en tu DNS y esperas a que verifique.
El proceso es el mismo que en SES. Pero el tiempo para completarlo es de minutos, no de configurar roles IAM en paralelo. Ese tiempo es el impuesto real.
❌ El enfoque legacy: Configurar IAM, crear una identidad de email, verificar el dominio en una consola separada, lidiar con credenciales SMTP.
✅ El enfoque Resend: Una API key, un endpoint, los registros DNS listados para copiar.
La key con prefijo `re_...` se genera con un scope específico. No uses la key raíz para producción. Eso es básico, pero os sorprendería cuánta gente lo ignora.
Paso 2: SDK con Paridad Multi-Lenguaje
Aquí es donde Resend hace algo que la mayoría no aprecia lo suficiente. SDKs de primera clase en más de 7 lenguajes: Node.js, Python, Go, Ruby, PHP, Elixir y Java.
La mayoría de equipos no eligen un proveedor de email en el vacío. Eligen uno que funcione en su stack completo — el backend de Node, los servicios de Python, los workers de Go.
SendGrid y SES son potentes, pero su DX es históricamente dolorosa. Resend diseña para el tiempo de primer email, la métrica que realmente impulsa la adopción en un mercado de APIs.
En Node.js:
```js
import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
await resend.emails.send({
from: 'Acme <onboarding@acme.com>',
to: ['user@example.com'],
subject: 'Welcome',
text: 'Hello!',
});
```
En Python:
```python
import os
import resend
resend.api_key = os.environ['RESEND_API_KEY']
resend.Emails.send({
'from': 'Acme <onboarding@acme.com>',
'to': ['user@example.com'],
'subject': 'Welcome',
'html': '<p>Hello!</p>'
})
```
La API key va en variables de entorno, nunca en el código fuente. Ese es el único patrón que acepto.
Paso 3: React Email como Fuente de Verdad
Aquí está la jugada maestra. React Email (react.email) es la biblioteca open-source bajo el paraguas de Resend para construir plantillas como componentes React.
Con componentes, escribes una plantilla así:
```tsx
// emails/Welcome.tsx
import {
Html,
Head,
Preview,
Body,
Container,
Heading,
Text,
} from '@react-email/components';
export function Welcome({ name }: { name: string }) {
return (
<Html>
<Head />
<Preview>Bienvenido a Acme</Preview>
<Body>
<Container>
<Heading>Hola {name} 👋</Heading>
<Text>Gracias por registrarte en Acme.</Text>
</Container>
</Body>
</Html>
);
}
```
Y lo envías directamente desde el SDK de Resend:
```js
import { Resend } from 'resend';
import { Welcome } from './emails/Welcome';
const resend = new Resend(process.env.RESEND_API_KEY);
await resend.emails.send({
from: 'Acme <no-reply@acme.com>',
to: ['user@example.com'],
subject: 'Welcome',
react: <Welcome name="Ana" />,
});
```
El componente React se convierte en la fuente de verdad de la plantilla. Tipado. Testeable. Versionable con el resto de tu código.
El Contraargumento del Lock-In — y Por Qué Falla
"¿Y si me quiero ir de Resend y tengo todo en React Email?"
El punto clave: React Email renderiza a HTML estándar y funciona con cualquier proveedor. Esa es la brillantez — al bajar el coste de cambio de la librería misma, crea un camino por defecto hacia la API de Resend.
El riesgo que sí existe es el de la API de envío. Pero eso es el mismo riesgo que asumes con cualquier proveedor de email. Y una REST API es trivial de cambiar.
A los equipos que ya viven en el ecosistema React/Vercel, este workflow colapsa la autoría de plantillas, el testing y el envío en un solo stack. Eso es algo que SES, con su API de plantillas en JSON, nunca ofreció como experiencia.
Paso 4: Cerrar el Loop de Feedback con Analytics
Enviar es solo la mitad. La otra mitad es saber qué ha pasado con tus emails.
Resend incluye analytics de entrega y apertura en el dashboard. Y para los que quieren automatización, webhooks para eventos de entregabilidad.
El setup mínimo que todo el mundo debería tener:
```
Webhooks → email.delivered
→ email.bounced
→ email.complained
```
Cada evento llega a un endpoint tuyo. Así detectas problemas de deliverability temprano, en vez de silenciosamente.
El patrón: un webhook handler que procesa el payload y actúa.
```js
// app/api/webhooks/email/route.ts
import { NextRequest } from 'next/server';
export async function POST(req: NextRequest) {
const event = await req.json();
if (event.type === 'email.bounced') {
// Marca al contacto, detén envíos a esa dirección
}
if (event.type === 'email.complained') {
// Reporte de spam. Actúa ya.
}
return new Response('ok', { status: 200 });
}
```
Sin este loop, tus emails pueden estar cayendo en spam semanas enteras sin que te enteres. El dashboard te lo muestra. Los webhooks te lo automatizan.
Paso 5: El Marco de Decisión — Cuándo Elegir Resend
Mi framework, el Modelo de Moat de Ecosistema, dice que la pregunta no es "¿quién tiene la infraestructura más grande?" sino:
¿Cuán rápido puede mi equipo enviar y depurar email?
Para equipos que ya viven en React o que tienen stack poliglota (Node + Python + Go), Resend comprime el ciclo completo — plantillas, testing y envío — en un solo stack.
❌ Elegís SES si... vuestro único criterio es coste por email a escala masiva y ya tenéis toda la infraestructura AWS montada.
✅ Elegís Resend si... queréis escribir plantillas en React, probarlas localmente, enviar desde el SDK y olvidaros del resto.
Honestidad Sobre la Evidencia
Un apunte importante. Ninguna fuente en este análisis tenía métricas publicadas por el vendor sobre volumen de envío, uptime o tasas de entregabilidad. No hay datos verificables sobre rendimiento bruto.
Eso no es un fallo del artículo — es un punto analítico. En un mercado donde todos los proveedores reclaman un 99,99% de entregabilidad, los diferenciadores son observables en el DX, no en las páginas de marketing.
Y en cuanto a la reputación de IP: Resend opera sobre infraestructura cloud establecida, no sobre IPs frías recién compradas. Pero la reputación de IP se gana con el tiempo, y los datos a largo plazo no estaban disponibles. Sed sensatos: probad la entregabilidad vosotros mismos antes de lanzar campañas grandes.
Tu Primer Email en Menos de 10 Minutos
El resumen en forma de checklist (el Modelo de Moat de Ecosistema en acción):
1. Crea el dominio en Resend y copia los registros SPF/DKIM a tu DNS.
2. Genera una API key con scope acotado y guárdala en variables de entorno.
3. Instala el SDK — `npm install resend` o `pip install resend` — y envía tu primer email de prueba.
4. Mira el dashboard para el delivery y el open tracking.
5. Adopta React Email para plantillas tipadas y testeables.
6. Conecta webhooks para delivered, bounced y complained.
La industria asumió que en email marketing la entregabilidad y el scale lo son todo, y que el DX es un extra. La estrategia de Resend demuestra lo contrario: la capa de transporte es cada vez más un commodity, y quien gana es quien captura el workflow antes de que toques la API.
Los proveedores legacy siguen compitiendo por quién tiene la cañería más ancha. Resend ganó el derecho a participar compitiendo por algo más escaso que capacidad: el tiempo del desarrollador. En 2026, ese es el moat que importa.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF