GuíasAutenticación

No DMARC record found: la línea que le falta a tu dominio

Tu dominio aún no tiene registro DMARC. Aquí tienes la línea que hay que añadir, dónde va en tu DNS y qué cambia para tu correo una vez que está. Contrastado con el RFC 9989 y con las normas para remitentes de Gmail, Yahoo y Outlook.com.

Actualizado el 5 de octubre de 202610 min de lectura

En resumen

El mensaje significa que no hay ningún registro TXT en _dmarc.yourdomain.com. Tu servidor de correo no está estropeado.
Añade un registro TXT con el host _dmarc y el valor v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Con p=none, la entrega sigue exactamente igual que antes.
Gmail, Yahoo y Outlook.com solo exigen el registro a los remitentes masivos. Añádelo de todos modos: Google cuenta el dominio entero y nunca retira la condición de remitente masivo, y los informes solo empiezan cuando existe un registro.
Si un comprobador sigue sin encontrar nada, busca un proveedor de DNS equivocado, un nombre de host duplicado o dos registros DMARC. Dos registros se anulan entre sí.
El estándar cambió en mayo de 2026 con el RFC 9989: pct desaparece, t y np son nuevos. La ayuda de Google sigue describiendo pct a octubre de 2026.

«No DMARC record found» (no se ha encontrado ningún registro DMARC) significa que un comprobador pidió al DNS un registro TXT en _dmarc.yourdomain.com y no recibió nada. En tu servidor de correo no hay nada estropeado. La solución es un registro TXT con el host _dmarc y el valor v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Con p=none tu correo se entrega exactamente igual que antes. Solo indicas a los receptores que participas, y empiezas a recibir informes.

DMARC es el tercero de los tres registros del email, junto a SPF y DKIM. SPF enumera los servidores que pueden enviar en nombre de tu dominio. DKIM firma cada mensaje. DMARC indica a un receptor qué hacer cuando ninguno de los dos responde por el dominio de tu dirección From, y adónde enviar un resumen diario. Desde mayo de 2026 está definido en el RFC 9989, que sustituyó al anterior RFC 7489. Muchas guías siguen describiendo la versión anterior, y también lo hace la página de ayuda de Google a octubre de 2026.

El registro que hay que añadir

Inicia sesión donde se gestiona el DNS de tu dominio. Es la empresa a la que apuntan tus servidores de nombres, que no siempre es aquella a la que compraste el dominio. Añade un registro nuevo con estos valores:

Campo	Qué introducir
Tipo	`TXT`
Host o nombre	`_dmarc`
Valor o contenido	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`
TTL	Deja el valor por defecto

Escrito como una línea de un archivo de zona, el registro terminado tiene este aspecto:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Sustituye example.com por tu propio dominio. Las tres partes hacen esto:

v=DMARC1 marca la línea como un registro DMARC. Tiene que ir en primer lugar, con DMARC1 en mayúsculas. Si no, los receptores ignoran el registro entero.
p=none es la política: trata mi correo como lo harías de todos modos. Nada se bloquea ni se mueve a spam por este registro.
rua=mailto:… es la dirección para los informes diarios. Crea esa dirección, o un alias que te los reenvíe, antes de publicar el registro.

Google recoge los mismos tres campos en Configurar DMARC. También pide que SPF y DKIM lleven 48 horas funcionando antes de añadir DMARC. Si tu comprobador señala también esos dos, arréglalos primero.

Cómo comprobar que ha funcionado

Pregunta tú mismo al DNS. En macOS o Linux, abre un terminal y usa dig. En Windows, usa nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Si el registro está activo, la línea vuelve entre comillas. Esto es lo que respondió el propio dominio de Google el 5 de octubre de 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Una respuesta vacía significa que el registro todavía no está, o no está donde lo buscan los receptores. Cuando tu propia consulta muestre la línea, vuelve a ejecutar el comprobador que te dio el mensaje. MXToolbox, por ejemplo, formula el problema como «No DMARC Record found» y explica que «tu dominio no tiene un registro DMARC publicado».

Qué significa cada parte de un registro DMARC

Un registro es una lista de pares tag=value separados por punto y coma. En el estándar solo v es obligatorio, y tiene que ir el primero. Pon p en segundo lugar: la ayuda de Google afirma que «las etiquetas v y p deben ir las primeras», y el estándar anterior esperaba el mismo orden. Estas son las etiquetas del RFC 9989, sección 4.7:

Etiqueta	Qué dice	Si la omites
`v=DMARC1`	Esto es un registro DMARC.	El registro se ignora.
`p`	Qué hacer con el correo que falla: `none`, `quarantine` o `reject`.	Se trata como `none` si hay un `rua` válido. Si no, el registro no se aplica. Defínela siempre.
`rua`	Adónde van los informes agregados diarios. Varias direcciones se separan con comas.	No se envían informes.
`sp`	Una política aparte para los subdominios que existen, como `news.example.com`.	Los subdominios reciben la política de `p`.
`np`	Una política aparte para los subdominios que no existen. Añadida con el RFC 9989.	Reciben `sp` o, en su defecto, `p`.
`adkim`, `aspf`	Hasta qué punto deben coincidir los dominios de DKIM y de SPF con tu dominio From: `r` para relajada, `s` para estricta.	Relajada.
`t`	`t=y` marca una política más estricta como prueba: se pide a los receptores que apliquen un nivel menos. Añadida con el RFC 9989.	`t=n`: la política vale tal como está escrita.
`ruf`, `fo`	Informes sobre mensajes fallidos concretos.	No se envía ninguno. Gmail no admite `ruf`, y Outlook.com no tiene previsto enviar esos informes.

Los registros antiguos terminan a menudo en pct=100. La etiqueta servía para aplicar una política a una parte del correo que falla. El RFC 9989 la eliminó, junto con rf y ri, y da el motivo:

La experiencia operativa mostró que la etiqueta «pct» no solía aplicarse con exactitud, salvo que el valor indicado fuera 0 o 100 (el valor por defecto), y que las inexactitudes con otros valores variaban mucho de una implementación a otra.

Los receptores tienen que ignorar las etiquetas que no conocen, así que un pct=100 antiguo no hace daño. Los registros de yahoo.com y microsoft.com todavía lo llevaban el 5 de octubre de 2026, y la página de ayuda de Google sigue recomendando pct para un despliegue gradual. En un registro nuevo, omítela.

¿Necesitas DMARC si solo envías unos pocos emails al día?

Según las normas publicadas por los grandes proveedores de correo, un registro DMARC es obligatorio cuando envías de forma masiva. Por debajo de eso es una recomendación.

Receptor	Todos los remitentes	Remitentes masivos
Gmail, cuentas personales	SPF o DKIM	A partir de 5000 mensajes al día: SPF, DKIM y un registro DMARC. La política «puede fijarse en none». El dominio From debe coincidir con el dominio de SPF o con el de DKIM.
Yahoo	«Implementa SPF o DKIM como mínimo»	SPF y DKIM, más «una política DMARC válida con al menos p=none». La página de Yahoo no da ninguna cifra para «masivo».
Outlook.com, Hotmail, Live	Ningún requisito declarado	Dominios que envían más de 5000 emails al día: SPF, DKIM y DMARC con una política de al menos `p=none`.

Las fuentes son las directrices para remitentes de correo de Google, las Sender Best Practices de Yahoo y el anuncio de Microsoft para remitentes de gran volumen, todas a octubre de 2026. Si envías treinta emails al día desde un buzón, ninguna exige el registro. Aun así hay tres razones para añadirlo ya.

El umbral se cuenta por dominio y no se reinicia. Google suma todos los mensajes a cuentas personales de Gmail que proceden del mismo dominio principal, subdominios incluidos. Sus preguntas frecuentes para remitentes dicen: «Los remitentes que cumplen los criterios anteriores al menos una vez se consideran remitentes masivos de forma permanente».
Tanto Google como Yahoo lo recomiendan para todos. Google escribe que «recomendamos configurar siempre SPF, DKIM y DMARC para tus dominios». Yahoo «insta encarecidamente a todos los remitentes a publicar una política DMARC para cada dominio que envía correo».
Sin el registro no recibes informes. Con ellos ves qué servidores envían correo con tu dominio en la línea From, tanto tus propias herramientas como desconocidos.

Para los remitentes masivos, la falta del registro tiene consecuencias. Las preguntas frecuentes para remitentes de Google recogen para ello el error temporal 4.7.31: «el dominio de envío no tiene un registro DMARC, o el registro DMARC no especifica una política DMARC». La misma página dice que desde noviembre de 2025 el correo que no cumple los requisitos se enfrenta a «rechazos temporales y permanentes».

¿Has añadido el registro y el comprobador sigue sin encontrar nada?

Entonces la causa suele ser una de estas. Repásalas con la consulta dig de arriba.

Editaste el DNS en el sitio equivocado. Si tus servidores de nombres están en una empresa distinta de tu registrador, los registros introducidos en el registrador nunca se consultan. dig +short NS example.com muestra quién responde por tu dominio.
El host es incorrecto. El registro está en el propio example.com o en un nombre duplicado, como se describe arriba. Los receptores solo preguntan por _dmarc.example.com.
Hay dos registros DMARC. El estándar es estricto en esto: «Si se devuelven varios registros de política DMARC para un mismo destino, se descartan todos». Únelos en uno. Dos direcciones de informes van en un solo rua, separadas por una coma.
La primera etiqueta no es exactamente v=DMARC1. Las minúsculas, una errata como DMARC 1 o un p= delante invalidan el registro.
El tipo de registro no es TXT, o el valor se pegó con comillas tipográficas desde un documento. Escribe el valor como texto sin formato, sin comillas salvo que la ayuda de tu proveedor de DNS las pida.
Sigue en caché una respuesta antigua. Los resolvedores recuerdan durante un tiempo que «no existe ese registro». Pregunta directamente a uno de tus propios servidores de nombres añadiendo su nombre a la consulta, por ejemplo dig +short TXT _dmarc.example.com @ns1.example.net. Si el registro aparece ahí, los comprobadores lo verán después.

Adónde van los informes y qué hacer con ellos

Cada receptor que recibió correo con tu dominio en la línea From envía un informe a la dirección rua. Según la página de Google Acerca de los informes DMARC, «normalmente se envían una vez al día por email». El informe es un archivo XML, normalmente comprimido, adjunto a un email. El RFC 9990 describe el formato.

Tres gaviotas llevan pequeñas notas enrolladas a un casillero de madera para cartas en la pared de una oficina del puerto — Cada receptor que recibió correo en tu nombre envía un informe breve al día a la dirección de `rua`.

Google advierte de que las organizaciones grandes «pueden recibir hasta cientos o incluso miles de informes al día» y recomienda un grupo o un buzón dedicado. La cantidad depende de cuánto envías y a cuántos dominios, así que uno o dos buzones generan muchos menos. Basta con un alias como dmarc@ y un filtro que los lleve a su propia carpeta.

La dirección debería estar en el mismo dominio que el registro. Si quieres los informes en otro sitio, el otro dominio tiene que dar su conformidad publicando un registro propio. Sin él, los receptores deben ignorar la dirección (RFC 9990, sección 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Por eso una dirección gratuita de Gmail no sirve como dirección de informes: gmail.com no publicaba ningún registro así cuando lo comprobamos el 5 de octubre de 2026.

En el archivo, cada bloque record representa un servidor de envío: su dirección IP, el número de mensajes y, en policy_evaluated, si DKIM y SPF pasaron para tu dominio. Buscas dos cosas. Los servidores que conoces y muestran fail hay que arreglarlos, y DMARC falla aunque SPF y DKIM pasan explica cómo. Los servidores que no conoces son o una herramienta que olvidaste o alguien que usa tu nombre.

Después de p=none: cuándo endurecer la política

p=none es un modo de observación. Cumple el mínimo que piden los proveedores de correo y no impide a nadie falsificar tu dirección. Eso solo lo hacen p=quarantine, que pide a los receptores tratar como sospechoso el correo que falla, y p=reject, que les pide rechazarlo.

Antes de endurecerla, todas las fuentes legítimas de tu correo tienen que pasar. El RFC 9989 dice que esas lagunas «DEBEN resolverse antes de cualquier intento» de aplicar la política, y que, según la frecuencia con que envíes, «puede llevar muchos meses» de informes estar seguro. La página de despliegue de Google considera que una semana de informes es «normalmente suficiente». Con un buzón y una o dos herramientas estás más cerca de la cifra de Google, pero dale unas semanas para que aparezcan también la facturación mensual y el formulario de contacto.

Para el paso en sí, las dos fuentes discrepan. Google sigue proponiendo p=quarantine; pct=5 e ir subiendo la cifra. El estándar ha eliminado pct y ofrece esto en su lugar:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y pide a los receptores que por ahora traten los fallos un nivel por debajo, es decir, como none. Cuando los informes sigan limpios, quita t=y. Ten en cuenta que un receptor que no conoce la etiqueta la ignora y aplica quarantine por completo, y que las páginas de Google no mencionan t a octubre de 2026. Si una política más estricta afectaría a correo que todavía no puedes arreglar, quédate en p=none.

Dónde entra WarmupBay

Cuando conectas un buzón, WarmupBay comprueba SPF, DKIM y DMARC de su dominio. Si falta el registro DMARC, te muestra uno terminado para copiar. Puedes empezar el calentamiento de todos modos. Si pasadas 72 horas los registros siguen faltando, el calentamiento se detiene.

WarmupBay no puede añadir el registro por ti, porque tu DNS es tuyo, y no recoge ni lee informes DMARC. Lo que hace es el paso posterior a los registros: tu buzón intercambia unos pocos emails al día con otros buzones de una red compartida, empezando con tres y subiendo uno cada día, de modo que la actividad de envío crece gradualmente. Es gratis para 10 emails al día. Mira qué abarcan la revisión y el calentamiento, o conecta tu buzón cuando el registro esté en su sitio.

Preguntas frecuentes

¿Un registro DMARC en example.com cubre también subdominios como news.example.com?

Sí. Un receptor pide primero un registro en _dmarc.news.example.com. Si no hay ninguno, recurre al registro del dominio organizativo, example.com. La política que se aplica al subdominio es la de sp si la has definido y, si no, la de p.

¿Puedo publicar v=DMARC1; p=none sin una dirección rua?

Sí. Es un registro válido y cuenta como una política publicada. No recibirás informes, así que no verás si tu propio correo pasa ni quién más usa tu dominio. Yahoo dice que una dirección rua que funcione es muy recomendable, y Google recomienda incluir siempre una.

¿Necesito un registro DMARC para un segundo dominio que solo uso para prospección?

Sí. Los receptores consultan el dominio de la dirección From de cada mensaje, así que un registro en tu dominio principal no cubre un dominio distinto. Usa la misma línea en el segundo dominio. Si sus informes deben ir a una dirección de tu dominio principal, el dominio principal tiene que publicar el registro de autorización descrito en «Adónde van los informes».

¿Qué debería publicar un dominio que nunca envía email?

La pareja estricta. M3AAWG recomienda el registro SPF v=spf1 -all y un registro DMARC con p=reject para los dominios que nunca envían correo, de modo que nadie pueda usarlos en una dirección From. Para DMARC es la línea v=DMARC1; p=reject en _dmarc.

¿p=none es peor para mi correo que p=quarantine o p=reject?

Las normas para remitentes publicadas por Gmail, Yahoo y Outlook.com piden al menos p=none y nada más estricto. La política decide qué pasa con el correo que falla DMARC, lo que incluye el correo falsificado en tu nombre. Una función necesita más: BIMI, el logotipo junto a tus mensajes, exige quarantine o reject según la ayuda de Google.