Tu Plantilla de Email Está Secuestrada y No lo Sabes
Abre tu dashboard de SendGrid. Mira cualquiera de tus templates activos.
*No puedes mover esa plantilla a Mailgun sin reescribirla desde cero.*
No es culpa tuya. Es el modelo de negocio. SendGrid, Mailgun, SES — todos os atan a su formato de plantillas porque la retención es más rentable que la calidad. Los proveedores legacy no compiten en entregabilidad — la entregabilidad es un commodity desde 2023 si configuras SPF, DKIM y DMARC bien. Compiten en lock-in.
Resend rompe ese juego. No te vende plantillas propietarias: te vende código. Componentes de React Email que viven en tu repositorio, se versionan con Git y se despliegan con tu app. Cuando tu proveedor sube el precio o te falla un rate limit, te llevas tus plantillas contigo y cambias de API en un finde.
Este es el tutorial que me hubiera gustado tener cuando monté el sistema de email de conversoriaecnae.es — y el que aplico en cada proyecto nuevo que uso Resend.
Por Qué Todos los Proveedores Entregan Igual (y Cómo Lo Compruebas)
Aquí va la verdad incómoda del sector: *la entregabilidad ya no es un diferenciador entre proveedores de email transaccional. *
¿Por qué? Porque la entregabilidad depende de tres cosas que controlas tú, no el proveedor:
1. SPF — qué servidores están autorizados a enviar por tu dominio.
2. DKIM — la firma criptográfica que verifica que nadie ha tocado el correo.
3. DMARC — la política que dice a Gmail y Outlook qué hacer si fallan las dos anteriores.
Configúralas bien y desde cualquier proveedor serio llegas al 99% de entregabilidad en correos transaccionales. Configúralas mal y ni el mejor proveedor del mundo salva tu dominio.
Gmail y Outlook ya exigen DMARC desde 2024 para remitentes masivos. La barrera de entrada subió, y eso aplana el campo de juego: los que sobreviven tienen la infraestructura igualada.
Entonces, ¿por qué Resend importa si SES cuesta menos?
Porque el coste real del email no es el envío. Es el desarrollo.
El Problema Real: SES Te Cobra el Envío y Te Hace Pagar el Desarrollo
Os propongo un experimento mental. Monta un email transaccional con AWS SES y uno con Resend.
Con SES necesitas:
La SDK de AWS en tu proyecto (o firmar peticiones manualmente con SigV4).
Un sistema de template propio o te encajas con el formato de SES.
Configurar el feedback loop manualmente.
Debuggear un cuerpo de petición que parece escrito por alguien que odia a los desarrolladores.
❌ Esto es lo que pasa con SES: pasas 3 horas intentando entender el SDK, otra hora peleando con el formato de template, y acabas con un sistema que solo funciona en tu máquina.
Con Resend:
```typescript
// Tu pipeline de email completo en ~40 líneas
import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
// La plantilla es un componente React. Vive en tu repo.
import { WelcomeEmail } from '@/emails/WelcomeEmail';
await resend.emails.send({
from: 'Acme <onboarding@tu-dominio.com>',
to: ['usuario@ejemplo.com'],
subject: 'Bienvenido a Acme',
react: <WelcomeEmail username="carlos" />,
});
```
✅ Lo que tienes con Resend: un endpoint en TypeScript, la plantilla como componente tipado con props, y el envío en una línea.
SES vende infraestructura. Resend vende experiencia de desarrollo. La primera te cuesta horas. La segunda te las devuelve.
El Modelo de 3 Capas para No Morir en el Intento
Me preguntáis siempre lo mismo: "¿Cómo montas el email en producción sin volverte loco?".
La respuesta es el modelo que llamo el Modelo de 3 Capas para No Morir en el Intento. Tres capas separadas que no se mezclan:
Capa 1: React Email — Las Plantillas como Código
Tu primer error es tratar las plantillas como artefactos del proveedor. Resend elimina ese error de raíz: usa React Email, que compila componentes JSX a HTML compatible con los 8 clientes de correo principales.
```tsx
// emails/WelcomeEmail.tsx — una plantilla portable
import { Html, Body, Container, Heading, Text, Button } from '@react-email/components';
export function WelcomeEmail({ username }: { username: string }) {
return (
<Html>
<Body style={{ fontFamily: 'Arial, sans-serif', padding: '20px' }}>
<Container>
<Heading>¡Bienvenido, {username}!</Heading>
<Text>Gracias por registrarte en tu-dominio.com.</Text>
<Button href="https://tu-dominio.com/dashboard" style={{ background: '#22c55e', padding: '12px 24px' }}>
Ir al dashboard
</Button>
</Container>
</Body>
</Html>
);
}
```
Esa plantilla es un fichero más de tu repo. Haces commit, code review, tests con Vitest y despliegas. Si mañana migras de Resend a otro proveedor, los componentes se quedan — solo cambia la capa de envío.
Otra cosa que me encanta: la librería de preview de React Email. Recibes el correo renderizado en tu navegador sin mandar un solo email real. Delegas el diseño al desarrollador, no al marketer que edita templates en un drag & drop roto.
Capa 2: La API — Un Endpoint en tu Edge Function, no un Servicio Aparte
Resend se integra de forma nativa con Vercel Edge Functions y Next.js Route Handlers. Eso significa que tu lógica de email vive en el mismo runtime que tu app.
```typescript
// app/api/send-welcome/route.ts — Next.js App Router
import { Resend } from 'resend';
import { WelcomeEmail } from '@/emails/WelcomeEmail';
const resend = new Resend(process.env.RESEND_API_KEY);
export async function POST(request: Request) {
const { email, username } = await request.json();
// Validas con Zod, no con un if gigante
const { data, error } = await resend.emails.send({
from: 'Tu App <hola@tu-dominio.com>',
to: [email],
subject: 'Bienvenido a Tu App',
react: WelcomeEmail({ username }),
});
if (error) {
return Response.json({ error }, { status: 400 });
}
return Response.json({ id: data?.id }, { status: 201 });
}
```
Capa 3: Los Webhooks — Donde Se Gana la Batalla de la Reputación
Todo el mundo configura el envío. Casi nadie configura el feedback loop. Ese es el error que te hunde el dominio a los tres meses de escalar.
Resend manda webhooks por cada evento: `email.sent`, `email.delivered`, `email.opened`, `email.clicked`, y el más importante de todos — `email.bounced` y `email.complained`.
Un correo que rebota no es un problema puntual: es un martillazo a tu reputación de dominio. Si no lo purgas de tu base de datos en minutos, el siguiente envío masivo perjudica a todos los demás.
Montar el webhook es directo:
```typescript
// app/api/webhooks/resend/route.ts
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
const body = await request.json();
// Eventos: email.bounced, email.complained, email.delivered
if (body.type === 'email.bounced') {
await updateUserStatus(body.data.email, 'bounced');
// Lógica de purga del usuario de tu base de datos
}
if (body.type === 'email.complained') {
// Marcar como spam — bloquea TODOS los envíos futuros a ese contacto
await blockContact(body.data.email);
}
return NextResponse.json({ ok: true });
}
```
Con este webhook activo, la purga de rebotes es automática. Tu reputación de dominio se mantiene intacta mientras escalas. Es la diferencia entre tener 100 contactos sucios y que Gmail te meta en spam, o purgarlos en tiempo real y mantener entregas limpias al 99%.
El Patrón que Falló en Producción: Lo Que No Debes Hacer
Vale, os he dado el camino correcto. Ahora el atajo que os va a morder el culo.
❌ Patrón roto: enviar emails desde el request principal.
```javascript
// ❌ NUNCA hagas esto
app.post('/registro', async (req, res) => {
await db.createUser(req.body);
await resend.emails.send({ ... }); // Bloquea la respuesta 400ms
res.json({ ok: true });
});
```
Cuatrocientos milisegundos de bloqueo por cada registro. Con 10 registros concurrentes, tu API ya huele a humo.
✅ Patrón correcto: desacopla el envío.
```typescript
// ✅ La respuesta vuelve al instante. El email viaja en cola.
app.post('/registro', async (req, res) => {
await db.createUser(req.body);
await notificationsQueue.publish('welcome-email', req.body.email);
res.json({ ok: true }); // ~50ms, no 400ms
});
```
El email transaccional no es transaccional en el sentido estricto: es asíncrono. Trátalo como tal y tu API escala. Trátalo como parte del request y tu backend muere con tu primer pico de tráfico.
Resend Te Da la Salud del Pipeline, no Solo el Envío
El dashboard de Resend no es un radiador de números bonitos. Es diagnóstico clínico.
Cada envío te da un rate limit claro y configurable por dominio o por campaña. Te muestra health score por dominio, streaks de entregabilidad y advertencias tempranas cuando tu reputación empieza a degradarse.
Eso es lo que ningún proveedor legacy te da por defecto: visibilidad operativa sin tener que montar un pipeline de observabilidad paralelo. Con SES necesitas CloudWatch, presupuestos personalizados y un ingeniero a media jornada solo para entender qué está pasando.
En Resend, el feedback loop está integrado en la experiencia. Los webhooks llegan a un endpoint que montas en veinte minutos, y el dashboard te cuenta la historia antes de que se convierta en un incidente.
La Migración no Duele si Tu Plantillas Viven en Tu Repo
Vamos directos a la conclusión incómoda: si uses el proveedor que uses, *tus plantillas deben vivir en tu repositorio, no en el dashboard del proveedor.*
React Email no es exclusivo de Resend. Puedes usar los componentes con cualquier proveedor que acepte HTML — que son todos. La diferencia es que Resend lo hace trivial: pásale el componente directamente como prop `react` y se encarga de compilarlo por ti.
Mi recomendación práctica:
1. Empieza con React Email en cualquier proyecto nuevo. Todas las plantillas como componentes en una carpeta `emails/`.
2. Usa Resend como proveedor por defecto — no por la entregabilidad, sino porque el DX te ahorra semanas de fricción con SDKs y formatos propietarios.
3. Monta los webhooks el día uno, no cuando ya has perdido la reputación de tu dominio.
4. Desacopla el envío del request con una cola o un job. El email es asíncrono, no importa lo que diga tu intuición de backend.
El email no es sexy. Es la columna vertebral de cualquier producto SaaS — y la mayoría de equipos lo monta como si fuera una ocurrencia de última hora.
Resend te da el marco para montarlo bien desde el principio. La entregabilidad es un commodity que se configura una vez y se olvida.
*El developer experience es el único moat que importa — porque el tiempo de tu equipo es el único coste que el proveedor no puede bajar por ti.*
Cada hora que no peleas con un SDK o un template propietario es una hora que dedicas a tu producto. Ese es el verdadero retorno de Resend. Y en 2026, con marcos como Next.js empujando todo hacia frameworks opinados, la apuesta por un proveedor que se alinea con tu stack — en vez de imponerte el suyo — es la única que no te va a dejar atrapado en 2030.
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