SPF, DKIM y DMARC para Resend.
Resend es una API de correo pensada para desarrolladores que autentica tu dominio con un pequeño conjunto de registros DNS generados por dominio, no con una línea SPF compartida que pegas. Cuando añades un dominio, Resend te muestra tres registros: un TXT de DKIM en resend._domainkey (una clave de firma que genera para ti), más un TXT de SPF y un registro MX que residen ambos en un subdominio send. que actúa como tu return path. Por debajo, Resend funciona sobre Amazon SES, pero oculta los CNAME de Easy-DKIM de SES tras su propia clave DKIM única. Una vez que esos tres registros resuelven, Resend firma el correo como tu propio dominio: DKIM se alinea de forma estricta con d=yourdomain.com, SPF se alinea de forma relajada a través del subdominio send, y DMARC pasa en ambos.
¿Por qué autenticar Resend?
Autenticar tu dominio en Resend es la diferencia entre la bandeja de entrada y la carpeta de spam, y hasta que lo hagas, solo puedes enviar desde el dominio de pruebas compartido de Resend onboarding@resend.dev, que no es tuyo en absoluto. Desde febrero de 2024, Gmail y Yahoo exigen que todo remitente masivo (aproximadamente 5.000+ mensajes al día) pase SPF, DKIM y DMARC con alineación, y Microsoft empezó a aplicar lo mismo al correo de alto volumen hacia Outlook/Hotmail en 2025. Resend suele estar conectado justo al tipo de correo que esas reglas juzgan con más dureza —restablecimientos de contraseña, recibos, códigos de verificación y, cada vez más, campañas de marketing— donde un solo viaje al spam rompe un flujo de registro. Resend lo pone inusualmente fácil: al situar el SPF/return path en un subdominio send. de TU dominio (en lugar de poseer un dominio de rebotes como hacen Mailchimp o la configuración heredada de SendGrid), el SPF sí se alinea en modo relajado, y el selector DKIM resend firma como tu propio dominio, de modo que DKIM se alinea de forma estricta. Publica los registros y un dominio de Resend pasa DMARC en ambos mecanismos: la configuración resiliente que sobrevive al reenvío. Sáltatelos y el correo o bien sale como resend.dev o bien queda sin autenticar, con la reputación agrupada en infraestructura compartida.
La realidad del SPF con Resend
Resend es un proveedor por cuenta construido sobre Amazon SES, así que NO hay ningún include compartido para tu dominio raíz, y eso es intencionado. Cuando añades un dominio, Resend aprovisiona un subdominio send. (el dominio de MAIL FROM personalizado / dominio del sobre de SES) y coloca el registro SPF ahí: send.yourdomain.com recibe v=spf1 include:amazonses.com ~all, y el MX correspondiente (feedback-smtp.{region}.amazonses.com) captura los rebotes y las quejas. El SPF de tu dominio raíz no se toca nunca: Resend le añade CERO búsquedas DNS. Dos cosas hacen que esto sea mejor que en la mayoría de los ESP. Primero, como el return path es un subdominio de tu propio dominio y no un dominio de rebotes propiedad de Resend, el SPF se alinea para DMARC en modo relajado (send.yourdomain.com comparte el dominio organizativo yourdomain.com). Segundo, Resend no usa los tres selectores CNAME de Easy-DKIM de SES: genera su propia clave DKIM y publica un único TXT en resend._domainkey.yourdomain.com, firmando con d=yourdomain.com, de modo que DKIM se alinea de forma estricta. Así que la realidad es: nada va en tu SPF raíz, el include:amazonses.com que ves pertenece únicamente al subdominio send, y es DKIM (no un include en la raíz) lo que aporta la alineación más fuerte. Si un tutorial antiguo te dice que añadas include:amazonses.com a tu raíz, ignóralo: no hace nada para Resend, consume una de las 10 búsquedas SPF de tu raíz y autoriza innecesariamente a todo SES a enviar como tu ápex.
Paso a paso
- 1
Añade tu dominio (y elige una región)
Inicia sesión en resend.com, abre Domains en la navegación izquierda y haz clic en Add Domain. Introduce tu dominio de envío —tu ápex (yourdomain.com) o, mejor, un subdominio de envío dedicado como updates.yourdomain.com— y luego elige la región de AWS más cercana a tus usuarios (N. Virginia us-east-1, Irlanda eu-west-1, São Paulo sa-east-1 o Tokio ap-northeast-1). La región queda incrustada en el host del MX y no se puede cambiar más adelante sin eliminar y volver a añadir el dominio, así que elige con criterio.
- 2
Abre la pestaña Records
Resend genera los registros DNS por ti y los lista bajo la pestaña Records/DNS del dominio: un TXT de DKIM (resend._domainkey), un TXT de SPF en el subdominio send y un MX en el subdominio send. Si ya tienes un servicio funcionando en send.yourdomain.com, usa la opción Custom Return Path para elegir un subdominio distinto antes de copiar los registros.
- 3
Añade el registro TXT de DKIM
En tu proveedor DNS crea un registro TXT con host resend._domainkey y el largo valor de la clave pública que muestra Resend (empieza por p=). Este es el registro que alinea de forma estricta tu correo con d=yourdomain.com, así que pega el valor exactamente: una clave pegada parcialmente o vuelta a entrecomillar es el motivo más común de que un dominio con buen aspecto siga fallando DKIM. Ten en cuenta que va en el selector de tu raíz (o subdominio de envío), no bajo send.
- 4
Añade el TXT de SPF en el subdominio send
Crea un registro TXT con host send (es decir, send.yourdomain.com) y valor v=spf1 include:amazonses.com ~all. Esto autoriza el sobre de SES para el return path: deja en paz tu SPF raíz y NO añadas include:amazonses.com a él. Si tu registrador añade el dominio automáticamente, introduce solo send, no send.yourdomain.com.
- 5
Añade el registro MX en el subdominio send
Crea un registro MX con host send, prioridad 10 y valor feedback-smtp.{region}.amazonses.com según la región que elegiste (p. ej. feedback-smtp.us-east-1.amazonses.com). Añade un punto final al valor para que tu registrador no le añada tu dominio. Este MX solo recibe la información de rebotes/quejas de SES: no cambia dónde se entrega tu correo entrante normal.
- 6
Publica un registro DMARC
Resend recomienda una política DMARC pero no la crea por ti. Añade un registro TXT en el host _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización, así que nada de la entrega cambia mientras confirmas la alineación. Mantén exactamente un registro _dmarc por dominio.
- 7
Haz clic en Verify DNS Records
De vuelta en Resend, haz clic en Verify DNS Records. La propagación suele ser de minutos, pero puede tardar hasta 72 horas; el estado cambia a Verified una vez que los tres registros resuelven. Si se atasca, vuelve a comprobar si hay un host duplicado, un MX con la región equivocada o un punto final ausente, y luego verifica de nuevo.
- 8
Envía una prueba real y lee las cabeceras
Verified en el panel no es prueba de que el correo esté alineado. Envía un mensaje desde una dirección de tu dominio verificado (no @resend.dev) a una cuenta de Gmail, ábrelo y elige ⋮ → Mostrar original. Quieres SPF: PASS (mailed-by un host send.yourdomain.com), DKIM: PASS con signed-by: yourdomain.com y selector resend, y DMARC: PASS, todo apuntando a tu dominio, no a resend.dev ni a amazonses.com.
Registros que añadir
Resend genera los valores exactos en su asistente de configuración; estos muestran la forma de lo que añadirás en tu proveedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | resend._domainkey | p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(long public key from Resend)Clave pública DKIM, selector resend, en tu dominio raíz/de envío: alinea de forma estricta el correo con d=yourdomain.com. Ilustrativo; la clave real de 1024 bits se genera por dominio y se muestra como una única cadena p=… (sin prefijo v=DKIM1); pégala exactamente como aparece. |
| TXT | send | v=spf1 include:amazonses.com ~allSPF para el subdominio send (el sobre / MAIL FROM de SES). Reside en send.yourdomain.com, NO en tu raíz: no añadas include:amazonses.com al SPF de tu ápex. |
| MX | send | feedback-smtp.us-east-1.amazonses.comReturn path para rebotes/quejas de SES: prioridad 10, en el subdominio send, con un punto final. Específico de región: la región coincide con la que elegiste al añadir el dominio (us-east-1 / eu-west-1 / sa-east-1 / ap-northeast-1). |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comEste lo añades tú: Resend muestra una política recomendada pero nunca la escribe en el DNS. Uno por dominio; empieza en p=none y luego aprieta. |
Mantén exactamente un registro TXT de SPF (v=spf1) en tu dominio raíz: fusiona en él todos los remitentes. Tener dos registros SPF es en sí mismo un error.
El presupuesto de 10 consultas
El SPF tiene un límite estricto de 10 consultas DNS: si lo superas, devuelve un permerror y deja de validar en todas partes. Esto es lo que la configuración de Resend consume de ese presupuesto.
La configuración recomendada de Resend añade 0 consultas: las 10 quedan libres para los remitentes que sí necesitan un include.
DKIM
DKIM es el registro más importante en una configuración de Resend, y es donde Resend se separa discretamente de Amazon SES puro. Aunque Resend funciona sobre SES, NO te entrega los tres selectores CNAME de Easy-DKIM de SES. En su lugar, Resend genera su propio par de claves DKIM por dominio y te da un único registro TXT: host resend._domainkey.yourdomain.com, valor la clave pública (una cadena p=… que muestra en la pestaña Records), selector resend. Resend conserva la clave privada correspondiente y firma cada mensaje con d=yourdomain.com; s=resend. Como ese d= es tu propio dominio —ni amazonses.com ni un dominio propiedad de Resend—, DKIM se alinea de forma estricta para DMARC, y sigue pasando incluso cuando un mensaje se reenvía (que es justo cuando el SPF tiende a romperse). Dos apuntes prácticos. Primero, este es un registro TXT que publicas tú, no una delegación CNAME, así que Resend no puede rotar la clave en silencio como hacen los proveedores de CNAME: si alguna vez rotas, vuelves a publicar el nuevo valor. Segundo, pega el valor exactamente como lo muestra Resend. Como Resend firma con una clave de 1024 bits, el valor de p= es una sola cadena de ~216 caracteres que cabe bajo el límite de 255 caracteres por cadena de los TXT en DNS, de modo que, a diferencia de las claves más largas de 2048 bits que te dan algunos proveedores, NO se divide en varias cadenas entrecomilladas; pégalo como un único valor sin cortes. Una copia parcial, un espacio insertado o un par de comillas extra que tu panel DNS envuelva alrededor de la cadena son la causa número uno de un dominio que parece configurado pero sigue fallando una comprobación de DKIM. El registro DKIM va en el selector de tu raíz (o de tu subdominio de envío), no bajo el subdominio send donde residen el SPF y el MX.
DMARC
DMARC es un registro de política aparte que Resend recomienda pero no crea por ti: lo añades tú en tu proveedor DNS. Publica un registro TXT en _dmarc.yourdomain.com que empiece por v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización: no cambia nada en la entrega, pero indica a los receptores que te envíen por correo informes agregados (rua) para que puedas confirmar que el correo de Resend pasa SPF y DKIM alineados con tu dominio. Resend se porta bien aquí: obtienes alineación SPF relajada a través del subdominio send Y alineación DKIM estricta a través del selector resend, así que deberías ver DMARC pasando limpiamente casi de inmediato, y puedes añadir con seguridad adkim=s (alineación DKIM estricta) si quieres, ya que d=yourdomain.com coincide exactamente con tu dominio From. Vigila los informes durante una o dos semanas, asegúrate de que todo remitente legítimo (Resend más cualquier proveedor de buzón u otras herramientas) se autentica, y luego sube la política de p=none a p=quarantine y finalmente a p=reject. Mantén exactamente un registro _dmarc para todo el dominio organizativo por muchos remitentes que tengas: nunca añadas un segundo registro DMARC solo para Resend.
Comprueba que de verdad funcionó
No te fíes solo del distintivo verde Verified de Resend: solo significa que los tres registros resolvieron, no que un mensaje real se alinee. Envía una prueba desde una dirección de tu dominio verificado (por ejemplo no-reply@yourdomain.com, NUNCA nada @resend.dev) a una cuenta de Gmail, ábrelo y elige ⋮ → Mostrar original. Quieres SPF: PASS con mailed-by mostrando un host send.yourdomain.com, DKIM: PASS con signed-by: yourdomain.com y selector resend, y DMARC: PASS, todo atribuido a tu dominio en lugar de a resend.dev o amazonses.com. Si DKIM aparece como tu dominio pero SPF muestra amazonses.com sin alinearse, comprueba que los registros del subdominio send estén en su sitio. Puedes verificar los registros en bruto con dig TXT resend._domainkey.yourdomain.com, dig TXT send.yourdomain.com y dig MX send.yourdomain.com. Por último, pasa el dominio por la comprobación de salud del dominio de Qualisend para confirmar que todos los registros resuelven y que tu SPF raíz se mantiene bajo el límite de 10 búsquedas, y una vez que empiecen a llegar los informes agregados de DMARC, mete uno en el analizador de informes DMARC: Resend/Amazon SES debería aparecer como una fuente alineada y que pasa.
Errores habituales
- Cobertura
Los registros de Resend residen en el subdominio send, no en tu raíz. Los registradores que añaden el dominio automáticamente convierten send en send.yourdomain.com.yourdomain.com y resend._domainkey en un host duplicado: introduce solo las etiquetas (send, resend._domainkey) y deja que el panel añada el dominio.
- Cobertura
El valor del MX es específico de región y debe coincidir con la región que elegiste al añadir el dominio. Un dominio eu-west-1 con un MX feedback-smtp de us-east-1 no verificará, y no puedes cambiar la región de un dominio tras crearlo; elimínalo y vuelve a añadirlo en la nueva región, luego actualiza el MX.
- Cobertura
Añade un punto final al valor del MX (feedback-smtp.{region}.amazonses.com.) para que tu registrador no añada tu dominio y genere feedback-smtp.us-east-1.amazonses.com.yourdomain.com.
- Rompe la autenticación
No añadas include:amazonses.com a tu SPF RAÍZ. El SPF de Resend va en el subdominio send; un include en la raíz no hace nada para Resend, desperdicia una de tus 10 búsquedas SPF de la raíz y autoriza a todo Amazon SES a enviar como tu ápex.
- Configuración de DNS
Resend está construido sobre SES pero NO usa los tres CNAME de Easy-DKIM de SES: publica un único TXT de DKIM (selector resend) que genera él mismo. No busques selectores CNAME; pega la única clave TXT exactamente, ya que una clave pegada parcialmente o vuelta a entrecomillar es el motivo principal de que DKIM siga fallando en un dominio 'configurado'. Es una clave de 1024 bits, así que el valor cabe en una sola cadena: no lo dividas.
- Cobertura
Las direcciones compartidas @resend.dev (onboarding@resend.dev, delivered@resend.dev, etc.) son solo para probar la API: no son tu dominio y te dan cero alineación de SPF/DKIM. Debes añadir y verificar tu propio dominio para enviar como tú mismo.
- Configuración de DNS
Estos son registros TXT y MX, no CNAME, así que no hay trampa de proxy con la nube naranja de Cloudflare; pero si Cloudflare ya creó automáticamente un SPF en tu raíz, déjalo en paz; el SPF de Resend es independiente y reside en el subdominio send.
- Cobertura
Si ya tienes correo o un servicio funcionando en send.yourdomain.com (un SPF, MX o subdominio existente), usa la función Custom Return Path de Resend para elegir un subdominio de return path distinto en lugar de colisionar con lo que ya hay.
Crea tu registro SPF
Resend no necesita un include: de SPF en tu dominio raíz: usa el generador para ensamblar un único registro limpio para tus otros remitentes y mantenlo en una sola línea.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF de Resend — Preguntas frecuentes
Lecturas relacionadas
Una vez publicado, confirma que todo se resuelve con el chequeo de salud del dominio y luego averigua quién envía en tu nombre con el analizador de informes DMARC. Explora todas las fuentes de envío en el generador. Eso sí, la autenticación es solo la mitad de la entregabilidad: una IP o un dominio de envío incluidos en una lista negra te llevan igualmente a spam por muy limpio que esté tu SPF, así que conviene vigilar las listas negras con monitorización de listas negras.
Autenticado: ahora mantén la lista limpia
Pasar SPF, DKIM y DMARC te lleva a la bandeja de entrada; una lista limpia te mantiene ahí. Verifica la tuya: empieza gratis con 100 créditos, sin tarjeta.