Soluciona los correos de Resend que van a spam

Resend no entrega a un destinatario real hasta que verificas un dominio, así que la trampa del dominio de envío compartido que atrapa a los usuarios de Klaviyo y Mailchimp aquí no existe. Lo que falla es más específico y más fácil de pasar por alto: los registros que Resend coloca en el subdominio de envío, una política DMARC que nadie crea por ti, una clave DKIM que no puedes mejorar y un dominio cuyo historial de envío entero empieza el día que lanzas. Esta guía cubre el DNS que Resend genera de verdad, la trampa del sandbox resend.dev, las IP dedicadas frente a las compartidas y cómo probar un envío real con Unspam.

Haz una prueba antispam gratis Cómo probar tus envíos

Por qué los emails de Resend acaban en spam.

Nadie publicó un registro DMARC, porque Resend no lo hace

Verificar un dominio escribe SPF y DKIM por ti y ahí se detiene. La propia página de resolución de problemas de spam de Resend dice que DMARC no se configura automáticamente pero es muy recomendable, y Deliverability Insights incluye una comprobación aparte de registro DMARC válido que falla en silencio en cada mensaje. Desde las reglas de remitentes masivos de Google y Yahoo, un dominio de remitente sin política DMARC es por sí solo una señal de filtrado. Publica v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; en _dmarc.tudominio.com antes de mirar cualquier otra cosa.

Tu primer envío en producción es el primer envío de tu dominio

Cada mensaje que enviaste mientras desarrollabas salió desde resend.dev, que lleva la reputación de Resend y no la tuya. El día que cambias la dirección de remitente a tu propio dominio, Gmail ve un remitente completamente nuevo con el volumen que genere tu lanzamiento. El plan de calentamiento de Resend empieza en hasta 150 correos el primer día y llega a hasta 2.000 el séptimo, y su calculadora estira la rampa hasta 42 días para objetivos mayores. Un lanzamiento que dispara varios miles de confirmaciones de registro desde un dominio verificado esa misma mañana es exactamente el patrón que el plan existe para evitar.

DKIM es de 1024 bits y no puedes cambiarlo

Resend firma el correo saliente con claves DKIM de 1024 bits y declara sin rodeos que no admite claves de 2048 bits. Ese es el mínimo que los servidores receptores siguen obligados a validar, así que las firmas se verifican con normalidad, pero no te deja margen ni forma de rotar a una clave más fuerte dentro del producto. También significa que DKIM no es una palanca que puedas accionar cuando un filtro corporativo como Mimecast o Proofpoint te puntúa a la baja. Invierte el esfuerzo donde sí tienes control: una política DMARC publicada, un subdominio con su propio historial y contenido que no necesite excusas.

Las campañas y los restablecimientos de contraseña salen del mismo dominio verificado

Resend separa el envío en la API de Emails para el correo transaccional y Broadcasts para el marketing, pero ambos salen del dominio que hayas verificado. Una newsletter que acumula quejas arrastra consigo tus restablecimientos de contraseña, porque para un filtro son el mismo remitente. La propia recomendación de Resend es enviar desde un subdominio para que los proveedores de correo tengan una indicación clara de dónde colocar tus mensajes. Verifica dos, por ejemplo notifications.tudominio.com para la API y updates.tudominio.com para Broadcasts, y mantenlos separados desde el primer día.

Tu recuento de quejas marca casi cero y no significa nada

La documentación de supresión de Resend indica que no todos los proveedores de correo devuelven un evento complained, sobre todo Gmail y Google Workspace. La cifra que miras en el panel omite por tanto al proveedor que decide la mayor parte de tu ubicación. Las supresiones son además de todo el equipo: una dirección suprimida tras un rebote de marketing se omite en todos los dominios y subdominios que tengas, transaccional incluido, así que un restablecimiento de contraseña puede no enviarse nunca sin aviso. Consulta tu tasa real de spam en Gmail con Google Postmaster Tools y trata la cifra de Resend como un suelo.

La plantilla enlaza a otro sitio distinto de tu dominio de envío, o pesa demasiado

Deliverability Insights de Resend comprueba que los enlaces de un mensaje apunten al mismo dominio desde el que se envía, y una plantilla cuyos botones resuelven todos a un sitio de marketing, a un acortador de enlaces o a un rastreador de terceros falla esa comprobación en cada envío. Usa un subdominio de tu dominio de envío para el seguimiento de clics en lugar de un acortador, y mantén al menos la llamada a la acción principal en tu propio dominio. El tamaño también cuenta: Resend señala que Gmail limita cada mensaje a 102 KB y, a partir de ahí, el resto del contenido se recorta y queda oculto tras un enlace para ver el mensaje completo, lo que deja tu enlace de baja a un clic de distancia.

Cómo autentica Resend tu correo.

Resend es poco habitual entre las plataformas de envío: no envía a nadie salvo a la dirección de tu propia cuenta hasta que verificas un dominio, y la verificación misma escribe SPF y DKIM. Eso elimina la desalineación de dominio compartido que sufren otras plataformas y deja exactamente dos cosas que acertar, el subdominio de envío y DMARC.

registro	por defecto	el problema	la solución
SPF	La verificación del dominio genera un registro TXT en el subdominio send del dominio que añadiste, con el valor v=spf1 include:amazonses.com ~all. Tanto el include como el host de rebotes apuntan a amazonses.com, así que SPF autentica la infraestructura de envío de Amazon.	Como el registro vive en send.tudominio.com, SPF autentica el subdominio y no tu dominio de remitente. La alineación relajada, la opción por defecto de DMARC, lo sigue contando como alineado. Quien no sabe esto añade un include de Resend a su registro SPF raíz, lo que no hace absolutamente nada, o pone aspf=s y deja DMARC apoyado solo en DKIM.	Publica el registro exactamente como se genera, con el host puesto solo en send, ya que tu proveedor de DNS añade el dominio. Deja intacto tu registro SPF raíz, incluido el include de Google Workspace o Microsoft 365, y no pongas aspf=s.
DKIM	La verificación genera un registro TXT en resend._domainkey en el dominio que añadiste, con una clave pública de 1024 bits. Resend firma con claves de 1024 bits y no admite 2048 bits.	El valor es lo bastante largo como para que los paneles de DNS lo trunquen, lo dividan en varias cadenas entrecomilladas o añadan comillas propias. Cuando eso pasa, el dominio no sale nunca del estado pendiente y no puedes enviar desde él, algo que los desarrolladores suelen interpretar como una caída de Resend. No hay ninguna vía a una clave más fuerte dentro del producto.	Copia y pega el valor en lugar de reescribirlo, usa resend._domainkey como host sin añadir el dominio y configura los registros de Cloudflare como DNS only en lugar de proxied. Confírmalo públicamente con dns.email o nslookup y comprueba después el valor d= en un mensaje real: debe ser tu propio dominio.
DMARC	Resend no crea ningún registro DMARC. Tu dominio se verifica, envía e informa de buena salud sin ninguna política publicada en ninguna parte.	La lista de comprobación de Resend pone la autenticación en primer lugar y señala DMARC como el único registro que no crea, y Deliverability Insights marca un registro ausente o inválido en cada mensaje. Saltar directamente a una política de aplicación es un fallo por derecho propio: quarantine o reject antes de que todos los remitentes legítimos estén alineados y filtras tus propias facturas y el correo de tu servicio de soporte.	Empieza en v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; en _dmarc.tudominio.com. Lee los informes, Resend mantiene un analizador DMARC gratuito y de código abierto en checkdmarc.email, confirma que todos los remitentes legítimos están alineados y pasa después a p=quarantine y p=reject.
Return-Path subdomain	Resend usa el subdominio send de tu dominio verificado para el Return-Path, y por eso tanto el registro TXT de SPF como el registro MX de rebotes están en send.tudominio.com. El valor MX depende de la región, feedback-smtp.us-east-1.amazonses.com para un dominio creado en Virginia del Norte y otro host para Irlanda, São Paulo o Tokio, así que copia el valor exacto de la pestaña Records del dominio.	Algunos clientes de correo muestran el Return-Path a los destinatarios, así que un valor inventado es un problema de credibilidad, y Resend advierte específicamente contra valores como testing. Publicar ese registro MX en el dominio raíz en lugar del subdominio es mucho peor: se apodera del correo entrante de todo el dominio.	Deja el valor por defecto. Si tienes que cambiarlo, pasa custom_return_path al crear o actualizar el dominio: máximo 63 caracteres, solo letras, números y guiones, empezando por una letra y terminando en letra o número.

Una vez actualizados estos registros, confirma que pasan con el comprobador de SPF, el comprobador de DKIM y el comprobador de DMARC gratuitos de Unspam.

Cómo probar una campaña de Resend con Unspam.

El panel de Resend te dice qué salió de la API y se detiene en Delivered, que según su propia definición solo significa que el servidor receptor respondió 250 OK. Después de eso el mensaje puede ir a la bandeja de entrada, a la carpeta de spam, a una cuarentena corporativa o a ninguna parte, y Resend nunca ve cuál. La única forma de saberlo es enviar un mensaje real por tu propia ruta de código a buzones semilla.

01
Consigue tu dirección semilla de Unspam y el Test ID

Inicia una prueba antispam gratuita o una prueba de ubicación en bandeja de entrada en Unspam y copia la dirección semilla que genera. Una prueba de ubicación emite además un Test ID. Pégalo en el asunto o en el cuerpo antes de enviar, o el mensaje llegará a los buzones semilla sin quedar vinculado nunca a tu prueba. Las pruebas de ubicación entregan en buzones semilla de Gmail, Outlook, Yahoo y otros cinco proveedores, e informan de dónde aterrizó cada copia.
02
Envía desde tu dominio verificado, no desde resend.dev

Pon en from una dirección del dominio que verificaste, por ejemplo notifications@notifications.tudominio.com. Dejar el valor del quickstart devuelve un 403 que te dice que solo puedes enviar correos de prueba a tu propia dirección, y un dominio de remitente que no coincida exactamente con el verificado, subdominio incluido, devuelve un 403 por dominio no coincidente. El buzón en sí no necesita existir, aunque Resend recomienda direcciones que puedan recibir respuestas.
03
Dispáralo por la ruta de código real

Llama a la misma ruta de API, Broadcast o Automation que reciben tus clientes, con la misma plantilla, los mismos enlaces y las mismas cabeceras personalizadas. Un envío puntual escrito a mano se salta tus cabeceras List-Unsubscribe, tu marcado renderizado de React Email y la reescritura de enlaces si tienes el seguimiento de clics activado, así que no prueba lo que realmente envías.
04
Da a Unspam credenciales SMTP para las ejecuciones repetidas

Para pruebas de ubicación programadas, da a Unspam los datos SMTP de Resend: host smtp.resend.com, puerto 587, usuario resend y contraseña una API key de Resend. Crea una clave dedicada con permiso sending_access y una restricción domain_id para que no pueda hacer nada salvo enviar desde ese único dominio, y copia el valor de inmediato porque Resend no vuelve a mostrar una clave. Unspam usa esas credenciales solo para enviar sus propios mensajes de prueba; no lee tus contactos, registros ni panel de Resend.
05
Lee el informe y corrige lo que señale

Unspam informa de la puntuación antispam, de los resultados de SPF, DKIM y DMARC en el mensaje real, de qué carpeta eligió cada proveedor semilla, de las vistas previas por cliente y de un mapa de calor. Confirma que el valor d= de DKIM es tu propio dominio y que DMARC pasa en lugar de simplemente estar ausente. Corrige lo señalado y repite el mismo envío para confirmar que el cambio movió la ubicación.

La misma prueba renderiza tu campaña en más de 50 clientes de correo reales, entre ellos Gmail, Outlook, Apple Mail, iPhone y Android, cada uno en modo claro y oscuro, mediante vistas previas en clientes de correo, para que confirmes la llegada a la bandeja de entrada y el renderizado de una sola vez.

Funciones de Resend que afectan a la entrega sin que lo notes.

El registro MX de Resend en el dominio raíz secuestra tu correo entrante

Los registros de envío de Resend van en el subdominio send, y Resend señala que un registro MX solo afecta al subdominio en el que está, así que el registro en send.tudominio.com deja en paz tu bandeja de Google Workspace o Microsoft 365. Mueve ese valor a la raíz y estarás redirigiendo el correo de cualquiera@tudominio.com al host de rebotes de Resend en lugar de a tu proveedor de correo. Resend publica la misma advertencia sobre su función de entrada: añadir un registro MX de recepción en el ápice enruta todos los mensajes del dominio a Resend en lugar de a tu proveedor anterior, y por eso te dice que pongas la recepción en su propio subdominio (por ejemplo subdomain.tudominio.com). Mantén cada registro de Resend en el host exacto que muestra la pestaña Records del dominio y no cambies nada en el ápice.

El host de rebotes depende de la región y los paneles de DNS lo rompen

Un dominio se crea en Virginia del Norte (us-east-1), Irlanda (eu-west-1), São Paulo (sa-east-1) o Tokio (ap-northeast-1), y el valor MX tiene que coincidir con esa región. Dominan dos fallos: un registro que apunta a una región distinta de aquella en la que se creó el dominio, y un proveedor de DNS que añade tu dominio de modo que el valor acaba siendo feedback-smtp.eu-west-1.amazonses.com.example.com. Añade un punto final para marcar el valor como completamente cualificado. Cambiar de región no es una edición: significa borrar el dominio, añadirlo de nuevo y volver a publicar todos los registros.

Delivered no significa bandeja de entrada

Resend marca un correo como Delivered en cuanto el servidor del destinatario lo acepta con una respuesta 250 OK. Todo lo que viene después, bandeja de entrada, carpeta de spam, cuarentena corporativa o descarte silencioso, ocurre fuera de la visibilidad de Resend. Un panel lleno de filas verdes de Delivered es perfectamente compatible con que todos esos mensajes estén en la carpeta de correo no deseado, y por eso los equipos persiguen esto durante semanas antes de probar la ubicación.

La API de Emails no añade ninguna cabecera List-Unsubscribe por ti

Broadcasts y Automations gestionan el flujo de baja automáticamente cuando incluyes un enlace de baja. Los envíos transaccionales por la API de Emails no lo hacen, porque Resend no gestiona listas de contactos para ellos, así que las cabeceras las pasas tú: List-Unsubscribe con tu URL entre corchetes angulares y List-Unsubscribe-Post con el valor List-Unsubscribe=One-Click. Tu endpoint tiene que responder tanto a GET como a POST, y actuar sobre la petición en un plazo de 48 horas.

Con qué se encuentran los remitentes reales de Resend.

Los problemas de entregabilidad que más sufren los remitentes de Resend, cada uno con la solución que lo resuelve.

El dominio aparece como Verified en Resend, SPF y DKIM pasan los dos, y Gmail sigue metiéndolo todo en la carpeta de spam.

La verificación solo produce SPF y DKIM. No publica DMARC, y Resend declara que DMARC no se configura automáticamente. Pasar SPF y DKIM sin ninguna política DMARC en el dominio de remitente es exactamente lo que apuntan los requisitos para remitentes masivos de Google y Yahoo, y el propio Deliverability Insights de Resend lo marca en cada mensaje que abras.

La solución Publica v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; en _dmarc.tudominio.com, abre después el panel de Insights en un envío real y resuelve todas las comprobaciones restantes, sobre todo la coincidencia de la URL de los enlaces y el remitente sin respuesta.

Recibo constantemente un 403 domain is not verified al enviar desde localhost, incluso a mi propia dirección.

Aquí chocan dos reglas distintas. El dominio de remitente tiene que coincidir exactamente con el dominio verificado, así que un dominio verificado como sending.example.com rechaza una petición que dice example.com. Por separado, si from sigue siendo onboarding@resend.dev, el único destinatario permitido es la dirección de tu cuenta de Resend, de modo que una errata en tu propia dirección produce lo que parece el mismo error.

La solución Abre la página Domains y copia la cadena del dominio verificado carácter por carácter en from, y comprueba después que la API key no está restringida a otro dominio por domain_id. Mientras desarrollas, envía a delivered@resend.dev, bounced@resend.dev, complained@resend.dev o suppressed@resend.dev en lugar de a tu propia bandeja.

Añadí todos los registros a Cloudflare hace dos días y el dominio sigue pendiente. No cambia nada cuando pulso verificar.

Tres causas explican casi todos estos casos. El proveedor de DNS añadió tu dominio al valor MX, produciendo feedback-smtp.us-east-1.amazonses.com.example.com. Los registros fueron al registrador mientras los servidores de nombres apuntan a otro sitio, así que nada de lo que publicaste está activo. O la región del MX no coincide con la región en la que se creó el dominio, a veces con dos regiones publicadas a la vez.

La solución Consulta los registros públicamente con dns.email o nslookup en lugar de fiarte del panel de DNS. Añade un punto final al valor MX para marcarlo como completamente cualificado, borra las filas de región duplicadas, pon los registros en DNS only en lugar de proxied y usa después Restart verification.

Después de apuntar el registro MX a Resend, nuestra bandeja de Google Workspace dejó de recibir nada.

El registro MX que genera Resend va en el subdominio send. Publicado en la raíz, se convierte en el servidor de correo de todo el dominio, así que cualquier mensaje dirigido a cualquiera@tudominio.com se enruta a Resend y se aleja de Google Workspace o Microsoft 365. Resend documenta este fallo exacto y recomienda un subdominio para evitarlo.

La solución Borra el registro MX de la raíz, restaura tus registros MX de Google Workspace o Microsoft 365 exactamente como estaban y vuelve a publicar el MX de Resend con el host puesto en send. Si send ya está ocupado, Resend sugiere send.sub.tudominio.com.

Lanzamos, enviamos unas cuatro mil confirmaciones de registro en un día desde un dominio que verificamos esa misma mañana, y la mayoría acabó en la carpeta de no deseados.

Todo lo anterior al lanzamiento salió desde resend.dev, así que tu propio dominio no tenía ningún historial de envío. Resend deja en tus manos la responsabilidad de calentar un dominio, a diferencia de las IP dedicadas, que calienta automáticamente. Su plan empieza en hasta 150 correos el primer día y llega a hasta 2.000 el séptimo, y la calculadora extiende la rampa hasta 42 días para objetivos mayores.

La solución Verifica el subdominio de envío semanas antes del lanzamiento y empieza a mandar tráfico real de bajo volumen por él. Sigue el plan de calentamiento, mantén la tasa de rebote por debajo del 4% y la de spam por debajo del 0,08%, y limita los envíos no transaccionales a quienes abrieron o hicieron clic en los últimos seis meses, como recomienda la guía de higiene de audiencia de Resend.

La entregabilidad en Resend, tus dudas resueltas.

¿Por qué recibo un 403 al enviar a un cliente desde onboarding@resend.dev?

resend.dev es un remitente solo para pruebas. Únicamente puede entregar a la dirección de correo de tu cuenta de Resend, y cualquier otra devuelve un 403 diciendo que solo puedes enviar correos de prueba a tu propia dirección. El quickstart y la mayoría de los andamiajes de framework llegan con ese valor en el código, así que sobrevive hasta el entorno de pruebas más a menudo de lo que nadie admite. Verifica un dominio y cambia luego from a una dirección de ese dominio.

¿Resend configura SPF y DKIM por mí?

Sí. La verificación del dominio genera el registro TXT de DKIM en resend._domainkey y el registro TXT de SPF en el subdominio send, más el registro MX del Return-Path, y tú publicas los tres en tu proveedor de DNS. DMARC es la excepción: Resend no lo crea y así lo dice. La verificación suele completarse en los 15 minutos siguientes a la publicación de los registros, aunque los cambios de DNS pueden tardar hasta 72 horas en propagarse globalmente.

¿Necesito una IP dedicada con Resend?

Solo por encima de cierto volumen real. Los criterios que declara Resend son una suscripción activa a Transactional Scale o Marketing Pro y un volumen de envío superior a 3.000 correos al día, y advierten de que por debajo de 90.000 correos al mes puede no bastar para mantener las IP calientes. Por debajo de eso, las IP compartidas son la mejor opción porque llegan ya calentadas por otros remitentes. Resend tampoco expone las direcciones de un pool, así que una IP dedicada no sirve para incluirla en listas blancas.

¿Debo verificar mi dominio raíz o un subdominio?

Un subdominio. Resend lo recomienda por dos razones: aísla la reputación de envío, de modo que un subdominio comprometido puede ponerse en cuarentena sin tocar tu dominio principal, y da a los proveedores de correo una señal clara sobre qué tipo de mensajes son estos. Su ejemplo es notifications.acme.com en lugar de acme.com. Contra lo que advierten es contra un dominio parecido como acme-alerts.com, que a los filtros les suena a phishing.

Resend no muestra casi ninguna queja de spam, entonces ¿por qué mi correo está en la carpeta de no deseados?

Porque el mayor proveedor de buzones nunca se lo dice a Resend. La documentación de supresión de Resend indica que no todos los proveedores devuelven un evento complained, sobre todo Gmail y Google Workspace. Tu panel infravalora la cifra en la proporción de tu lista que esté en Gmail. Date de alta en Google Postmaster Tools para ver la tasa real de spam, y haz pruebas de ubicación en bandeja de entrada para ver la carpeta en lugar de deducirla del engagement.

¿Puedo usar una clave DKIM de 2048 bits con Resend?

No. Resend firma el correo saliente con claves DKIM de 1024 bits y no admite 2048 bits. Si una revisión de seguridad o una política interna exige firma de 2048 bits, eso es un bloqueo duro y no un ajuste, y la respuesta es otra ruta de envío para ese correo. Para la entregabilidad corriente no es el problema a resolver: las firmas de 1024 bits siguen verificándose en todos los grandes proveedores.

Los detalles de la plataforma Resend se verificaron con la documentación disponible públicamente en agosto de 2026 y pueden haber cambiado desde entonces. Resend es una marca comercial de su respectivo propietario. Unspam no está afiliada a Resend ni cuenta con su respaldo.

Prueba tu próxima campaña de Resend antes de que lo hagan tus suscriptores.

Empieza una prueba antispam gratis Prueba de Inbox Placement