El Agujero de Conejo de la Verificación de Dominio: SPF, DKIM y DMARC con Resend
Hace poco lancé una feature en una de mis aplicaciones que enviaba notificaciones por email usando Resend. Todo funcionaba en desarrollo. Los emails llegaban. Hermoso.
Luego pasó a producción.
Y desaparecieron.
No a spam. Desaparecieron directamente. El cliente no los recibía. Ni en spam. Ni en ningún lado. Era como si nunca hubieran existido.
Esa fue mi entrada al agujero de conejo de la verificación de dominio.
Por qué Resend es excelente (pero no es magia)
Resend es genuinamente bueno. La API es limpia, la documentación es clara, y los emails se envían rápido. Pero aquí está el secreto que nadie te dice: Resend no controla si tus emails llegan a la bandeja de entrada. Eso depende de ti.
Los servidores de correo de Gmail, Outlook, y otros todavía usan estándares que datan de hace décadas. Y esos estándares requieren que pruebes que eres quien dices ser.
Entra SPF, DKIM, y DMARC.
SPF: El Primer Guardián
SPF (Sender Policy Framework) es básicamente un registro DNS que dice: "Los emails legítimos de mi dominio vienen de estos servidores".
Cuando configuras Resend, ellos te dan un dominio o un registro SPF específico. Típicamente algo como:
``` v=spf1 include:resend.com ~all ```
Esto significa: "Confía en los servidores de Resend para enviar emails en mi nombre".
El problema: Si no configuras esto correctamente, Gmail y otros verán tus emails como sospechosos. Y "sospechoso" en email significa "carpeta de spam" o directamente "eliminado".
Lo que aprendí:
- El SPF debe estar en tu dominio raíz o en el subdominio desde el que envías
- Demasiados includes en SPF causa problemas (hay límite de búsquedas DNS)
- Si cambias proveedores de email, debes actualizar SPF o los nuevos emails fallarán
DKIM: La Firma Digital
DKIM (DomainKeys Identified Mail) es más sofisticado. Es una firma criptográfica que dice: "Este email fue realmente enviado por nosotros y no ha sido modificado".
Resend te proporciona una clave pública y una privada. La clave pública va en tu DNS (el registro DKIM), y Resend firma cada email con la privada.
Resend automatiza esto bastante bien, pero aquí está donde muchos desarrolladores se pierden:
``` default._domainkey.tudominio.com TXT "v=DKIM1; k=rsa; p=MIGfMA0BCKQE..." ```
El problema real: Resend te da múltiples registros DKIM (a menudo 3). Debes agregar TODOS. No solo uno. Si solo agregas uno y los otros están pendientes, los emails pueden fallar autenticación.
En mi caso, agregué uno, probé localmente, vio que funcionaba, y lo dejé. Luego en producción, con volumen real, algunos emails se autenticaban y otros no. Fue un debugging de 3 horas.
DMARC: La Política de Enforcement
DMARC (Domain-based Message Authentication, Reporting and Conformance) es donde todo se une. Es tu política: "Si un email no pasa SPF o DKIM, ¿qué haces?".
Típicamente empiezas con:
``` v=DMARC1; p=none; rua=mailto:dmarc-reports@tudominio.com ```
Esto significa: "No hagas nada si falla, pero envíame reportes".
Luego, cuando confías en tu configuración:
``` v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@tudominio.com ```
Esto pone emails sospechosos en quarantine.
Y finalmente, si realmente quieres ser estricto:
``` v=DMARC1; p=reject; rua=mailto:dmarc-reports@tudominio.com ```
Esto rechaza directamente cualquier email que no pase.
Mi recomendación: Empieza con `p=none`, lee los reportes por una semana, asegúrate de que tus emails legítimos están pasando, y luego sube a `p=quarantine`.
El Debugging Real: Dónde Falla Todo
Cuando configuré todo esto, usé herramientas simples:
1. MXToolbox - Verifica SPF, DKIM, DMARC en tiempo real 2. Google Postmaster Tools - Te muestra cómo Google ve tu dominio 3. 250ok o similares - Monitoreo continuo
Pero la herramienta más útil fue... enviarme emails a mí mismo y revisar los headers.
En Gmail, si haces click en el email y luego "Mostrar original", ves exactamente qué pasó:
``` Authentication-Results: mx.google.com; spf=pass (google.com: domain of xxx@tudominio.com designates xxx as permitted sender) dkim=pass header.d=tudominio.com dmarc=pass ```
Si alguno dice `fail`, ahí está tu problema.
DNSBL: El Guardián que Ignoré
DNSBL (DNS Blacklist) es donde muchos desarrolladores se quedan atrapados sin ni siquiera saberlo.
Tus servidores de email (o en este caso, los de Resend) tienen direcciones IP. Si esas IPs están en listas negras de spam, tus emails no llegarán sin importar cuán perfecto sea tu SPF/DKIM/DMARC.
Resend maneja esto bien porque usan infraestructura respetada, pero si alguna vez cambias a otro proveedor o usas tu propio servidor, necesitas:
1. Verificar que tu IP no está en DNSBL 2. Monitorear regularmente (algunos servicios ofrecen alertas) 3. Si estás en una lista, solicitar remoción (típicamente requiere prueba de que has arreglado el problema)
Lecciones Prácticas
1. Automatiza la verificación
No confíes en que "probé y funcionó". Configura alertas. Resend tiene webhooks. Úsalos para monitorear bounces y complaints.
2. Empieza con un volumen pequeño
Antes de enviar miles de emails, envía 100 a diferentes proveedores (Gmail, Outlook, etc.) y revisa que todos llegan.
3. Lee los reportes DMARC
Son aburridos, pero te muestran exactamente qué está fallando. Son tu mapa del tesoro.
4. Usa subdominios para testing
Crea un `testing.tudominio.com` con su propio SPF/DKIM/DMARC. Así no jodes tu dominio principal mientras experimentas.
El Código Real
En tu aplicación, la integración con Resend es simple:
```javascript import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
await resend.emails.send({ from: 'noreply@tudominio.com', to: 'usuario@example.com', subject: 'Test', html: '<p>Hola</p>', }); ```
Pero el 90% del trabajo está en DNS, no en código.
El Takeaway
La verificación de dominio no es sexy. No es el tipo de problema que quieres resolver a las 3 de la mañana. Pero es el tipo de problema que, si no lo resuelves bien, hace que tu aplicación parezca rota.
Resend maneja la parte técnica de envío. Tu trabajo es asegurar que el mundo confía en tu dominio.
SPF, DKIM, DMARC, y DNSBL. Cuatro estándares que juntos crean un ecosistema de confianza.
Y una vez que lo entiendes, nunca vuelves a perder emails en el void.
---
¿Estás lidiando con deliverability issues? La mayoría de las veces está en DNS, no en código.
