Crea un registro DMARC conforme al RFC 9989, con cada etiqueta explicada, un plan con fechas de p=none a p=reject y el registro adicional que necesita un buzón de informes en otro dominio. Carga y comprueba tu registro publicado. Gratis, sin registro.
Un registro DMARC es un registro TXT en _dmarc. delante de tu dominio. Indica a los servidores receptores qué hacer con un mensaje cuyo dominio «De» no confirman ni SPF ni DKIM: entregarlo, llevarlo a la carpeta de spam o rechazarlo. También indica una dirección que recibe cada día informes sobre quién envía correo con tu dominio. DMARC empieza por v=DMARC1 y está definido en el RFC 9989, que sustituyó al RFC 7489 en mayo de 2026.
DMARC es el único de los tres registros de correo que protege la dirección que el lector ve de verdad. SPF y DKIM comprueban algo cada uno; DMARC decide.
1. Empieza con p=none y una dirección de informes. Para tus destinatarios todavía no cambia nada. Los servidores receptores te envían informes agregados: qué servidores enviaron correo con tu dominio y si SPF y DKIM se superaron para ellos. Sin dirección rua este paso no sirve de nada, porque nadie ve el resultado.
2. Corrige cada remitente legítimo y después endurece. Los informes muestran la herramienta de newsletter que falta en SPF y el servicio de atención que no firma con DKIM. Cuando dos semanas de informes ya no muestren correo legítimo que falle, pasa a quarantine, primero con t=y y luego sin él.
3. Termina en reject. Con p=reject, un mensaje falsificado con tu dominio en «De» se rechaza antes de llegar a nadie. Ese es el objetivo; p=none por sí solo solo documenta el problema.
El generador convierte la fecha de inicio que introduces en un calendario con un registro listo para cada etapa: cuatro semanas de observación, dos de quarantine en modo de prueba, cuatro de quarantine y después reject. Acorta las etapas si los informes están limpios antes, y alárgalas si no.
| Campo | Valor |
|---|---|
| Tipo | TXT |
| Nombre / Host | _dmarc (el panel añade el dominio), o _dmarc.example.com. donde se exija el nombre completo |
| Valor | el registro del generador, sin comillas |
| TTL | el valor por defecto; 3600 segundos está bien |
El error más frecuente es el nombre: un registro DMARC puesto en el propio dominio en lugar de en _dmarc nunca se encuentra. El segundo es el duplicado. En _dmarc solo puede haber un registro TXT que empiece por v=DMARC1; con dos, los receptores ignoran DMARC por completo. «Cargar registro publicado» muestra cada registro encontrado con ese nombre.
Si la dirección de informes está en otro dominio, por ejemplo en un servicio de informes, ese dominio tiene que publicar un registro que acepte recibir tus informes. El generador lo escribe por ti: un registro TXT en example.com._report._dmarc.reports-provider.net con el valor v=DMARC1. Sin él, la mayoría de los receptores descartan los informes sin avisar.
| Etiqueta | Significado | Valor por defecto del generador |
|---|---|---|
p |
Política del dominio: none, quarantine o reject. Obligatoria. | none |
rua |
Adónde van los informes agregados, como direcciones mailto: separadas por comas. | lo que escribas |
sp |
Política para los subdominios existentes. Sin ella, los subdominios siguen p. | omitida |
np |
Política para subdominios que no existen. Nueva en el RFC 9989. | reject |
adkim |
Alineación DKIM: r (relaxed, cuentan los subdominios) o s (strict, coincidencia exacta). | r |
aspf |
Alineación SPF, mismos valores. | r |
t |
Modo de prueba: t=y aplica la política un nivel más suave. Nueva en el RFC 9989. | desactivado |
ruf |
Adónde van los informes de fallo. Opcional, ver abajo. | omitida |
fo |
Cuándo se generan informes de fallo: 0, 1, d o s. | solo con ruf |
np cierra un hueco que los atacantes aprovechaban: correo desde subdominios inventados como billing.example.com, que nunca existieron y por tanto no tenían política propia. Nadie envía correo legítimo desde un nombre que no existe, así que np=reject es seguro desde el primer día, aunque p siga en none. t=y es el nuevo interruptor de prueba. También llega psd, pero está pensado para operadores de sufijos públicos, no para dominios normales.
pct desaparece. Debía aplicar la política a una parte del correo y los receptores lo implementaron de formas tan distintas que nadie podía prever el resultado; lo sustituye t=y. También se eliminaron rf y ri. Los registros que aún los llevan siguen funcionando, porque los receptores ignoran las etiquetas que no conocen, pero ya no tienen efecto. Si importas un registro así, el generador te dice qué etiquetas ha quitado y por qué.
Los informes enviados a la dirección ruf pueden contener direcciones, asuntos y fragmentos de mensajes reales. Eso los convierte en datos personales según el RGPD, y la mayoría de los grandes proveedores de correo ni siquiera los envían. Por eso el generador deja ruf vacío por defecto y la comprobación de este sitio ya no lo recomienda. Los informes agregados de rua solo contienen recuentos por servidor remitente, y es lo que de verdad necesitas.
El 19 de octubre de 2026 leímos los registros DMARC de los 1.000 dominios .de mejor clasificados de la lista Tranco (lista 467YX).
| Resultado | Dominios |
|---|---|
| Sin registro DMARC | 214 |
p=none, es decir, sin protección |
333 |
p=quarantine |
214 |
p=reject |
238 |
| DMARC sin dirección de informes | 148 de 786 |
Todavía con la etiqueta eliminada pct |
250 de 786 |
Con la nueva etiqueta np |
4 de 786 |
| Dos registros DMARC a la vez | 1 |
547 de 1.000 dominios no tienen DMARC o se quedan en p=none, con lo que su dirección «De» queda abierta a cualquiera. 148 publican una política pero ninguna dirección de informes, así que no pueden saber cuándo sería seguro endurecerla. Y solo cuatro usan np, la protección más barata que ofrece el RFC 9989.
quarantine pide al receptor que trate el correo que falla como sospechoso, lo que en la práctica significa la carpeta de spam. Un mensaje legítimo que falla por un remitente olvidado todavía puede encontrarse allí. reject pide al receptor que rechace el mensaje durante la entrega; el remitente recibe una devolución y el destinatario nunca lo ve.
quarantine es el paso intermedio seguro y reject el estado final. Los grandes proveedores de correo exigen DMARC a los remitentes masivos desde 2024, y una política reject es para ellos la señal más clara de que el correo enviado en tu nombre está autenticado. Quédate en quarantine solo mientras los informes sigan mostrando fuentes legítimas que no has corregido.
DMARC se supera cuando SPF o DKIM se superan para un dominio que coincide con el dominio «De». Por tanto, no puede ser mejor que esos dos. Antes de salir de p=none, cada servicio que envía con tu dominio debería estar en el registro SPF con un dominio de sobre que coincida, o firmar con una clave DKIM de tu dominio. DKIM es el más robusto de los dos, porque la firma sobrevive al reenvío y SPF no.
Cuando DMARC está en quarantine o reject, el dominio también cumple el requisito de BIMI, el registro que muestra tu logotipo junto a tus mensajes.
Los informes agregados llegan como archivos XML comprimidos, normalmente una vez al día desde cada gran proveedor que recibió correo con tu dominio. Cada archivo indica, por dirección IP remitente, cuántos mensajes llegaron de ella, si SPF y DKIM se superaron y si los dominios para los que se superaron estaban alineados con tu dominio «De».
Tres preguntas lo aclaran casi todo:
El XML no está pensado para leerse a mano. Un buzón de informes en un servicio DMARC o un analizador autoalojado como parsedmarc lo convierten en una tabla. Si el buzón está en un dominio distinto del tuyo, publica el registro de autorización que escribe el generador, o los informes nunca llegarán.
Sin sp, cada subdominio hereda la política del dominio principal. Es lo que quieren la mayoría de los dominios. Define sp solo si un subdominio necesita otra política, normalmente más suave para un subdominio cuyos remitentes aún no has corregido: p=reject; sp=quarantine.
np es otra cosa: se aplica a subdominios que no existen en el DNS. Un service.example.com falsificado, que nunca se creó, recibe la política np; un newsletter.example.com real recibe p o sp. Como un nombre inexistente no puede enviar correo legítimo, el generador pone np=reject desde el principio, aunque la política principal siga en none.
Un subdominio también puede publicar su propio registro _dmarc, que entonces tiene prioridad sobre el sp del dominio superior.
v=DMARC1; p=none; np=reject; rua=mailto: seguido de una dirección que de verdad leas. Así recoges informes sin cambiar la entrega y bloqueas el correo de subdominios que no existen. Pasa a quarantine en cuanto los informes muestren que tus propios servicios superan SPF o DKIM.
Como registro TXT con el nombre _dmarc delante de tu dominio, es decir, _dmarc.example.com. En la mayoría de los paneles DNS escribes _dmarc como nombre y el panel añade el dominio. Ningún receptor lee un registro DMARC puesto en el propio dominio.
No. El registro se crea en el navegador. «Cargar registro publicado» lee el registro público en _dmarc del dominio a través de nuestro resolver, y «Comprobar con DNS en vivo» envía el registro creado al mismo validador que usa el Email Security Check. Ninguno de los dos lo guarda.
Con quarantine, los receptores llevan el correo que falla a la carpeta de spam; con reject, lo rechazan durante la entrega y el remitente recibe una devolución. quarantine es el paso intermedio más seguro y reject la protección que buscas al final.
Puedes publicar DMARC con p=none ya mismo: sus informes son la forma más rápida de saber quién envía por ti. Pero antes de quarantine o reject, cada remitente legítimo necesita SPF o DKIM alineado con tu dominio; si no, tu propio correo acabará en spam o será rechazado.
El RFC 9989 lo eliminó. Los receptores aplicaban el porcentaje de formas tan distintas que el resultado era imprevisible. Usa t=y mientras pruebas una política más estricta y quítalo cuando los informes estén limpios. Los registros antiguos con pct siguen funcionando; los receptores que siguen la nueva norma simplemente ignoran la etiqueta.
Casi siempre por uno de tres motivos: el registro no tiene etiqueta rua, la dirección está en otro dominio que no ha publicado el registro de autorización, o el registro está con el nombre equivocado. El generador escribe el registro de autorización para direcciones externas, y «Cargar registro publicado» muestra dónde está realmente tu registro.
El registro se monta en el navegador según el RFC 9989: nunca escribe las etiquetas que la norma eliminó, ofrece np y t, y los informes de fallo son opcionales. El plan de despliegue es simple aritmética de fechas a partir de la fecha de inicio que indicas; no puede ver tus informes, así que las fechas son una propuesta, no una promesa.
«Cargar registro publicado» consulta cada registro TXT en _dmarc del dominio y aplica el validador del Email Security Check, que valora la política, la dirección de informes y la alineación. «Comprobar con DNS en vivo» aplica el mismo validador al registro que has creado, sin ninguna consulta DNS. Las direcciones de informes se comprueban por su forma, nunca se les escribe, y el registro de autorización de una dirección externa se genera pero no se consulta.
DMARC por sí solo no puede decirte cuáles de tus remitentes fallan. Solo los informes agregados pueden, y leerlos es el verdadero trabajo de un despliegue de DMARC.