Compruebe un registro DMARC y lea su política, alineación y direcciones de informes en palabras claras
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.Un comprobador de DMARC lee el registro TXT en _dmarc seguido de un dominio y dice qué hacen los receptores con el correo que falla SPF y DKIM. Las 3 políticas son none, quarantine y reject; solo las 2 últimas frenan el correo falsificado. Las direcciones de informes en otro dominio necesitan allí un registro de permiso.
Esta página se ha traducido automáticamente del original en inglés. Ninguna persona ha revisado todavía la traducción, así que la versión en inglés es la que debe consultar. Leer el original en inglés
Escriba el dominio en el campo Dominio y pulse Comprobar DMARC.
Lea el encabezado: indica la política que se aplica al correo que falla para ese dominio.
Lea Qué dice este registro para ver la política, la alineación y las direcciones de informes en palabras claras.
Revise los hallazgos por si hay direcciones de informes en otro dominio que no han aceptado recibir informes.
Pulse Copiar junto al registro para copiarlo.
Escriba un dominio y la página pide a un resolver público de DNS sobre HTTPS el registro TXT en _dmarc. seguido de ese nombre. El registro se lee etiqueta por etiqueta y luego se explica en frases: qué pasa con el correo que falla, qué pasa con los subdominios, con qué rigor deben coincidir SPF y DKIM con la dirección From y adónde van los informes.
Las reglas proceden de RFC 9989, publicado en mayo de 2026, que sustituyó a RFC 7489 como estándar de DMARC. Dos cambios importan al leer registros antiguos. Se ha eliminado la etiqueta pct: los receptores antiguos aún la usan para actuar solo sobre parte del correo que falla, los nuevos la ignoran. Una etiqueta t=y ahora significa modo de prueba, en el que los receptores aplican un paso menos que la política. Ambas se señalan en palabras.
Cuando un subdominio no tiene registro propio, los receptores buscan en su lugar el registro del dominio organizativo. Esta página lo hace con el recorrido del árbol DNS que define la sección 4.10 de RFC 9989, preguntando _dmarc en cada nombre más corto, como máximo 8, y muestra cada nombre consultado. No se usa ninguna lista de sufijos públicos, así que nada depende de que una copia de esa lista esté al día.
Se comprueba el permiso de las direcciones de informes en otro dominio. La sección 4 de RFC 9990 pide a los receptores enviar informes a otro dominio solo cuando ese dominio publica un registro TXT en el dominio de la política seguido de ._report._dmarc. y el host que recibe los informes. Que falte es el motivo habitual por el que un servicio de DMARC no recibe nada.
La pestaña del generador escribe un registro a partir de sus elecciones e indica el host bajo el que publicarlo. Omite las etiquetas que coinciden con sus valores predeterminados y no escribe pct.
Lo que no hace: lee el registro, no su correo, así que no puede decir si sus mensajes pasan. Eso se lo dicen los informes diarios.
El dominio que escribe se envía al resolver que elija, porque una consulta lo necesita. Nada más sale de su dispositivo.
Una política p=none pide a los receptores entregar con normalidad el correo que falla DMARC y solo enviar informes. El correo falsificado con el dominio sigue llegando a las bandejas de entrada. Los propietarios la usan unas semanas para encontrar en los informes a todos los remitentes legítimos, y luego pasan a quarantine y finalmente a reject.
No necesariamente. Cuando un subdominio como mail.example.com no tiene registro, los receptores usan el del dominio organizativo, example.com, y aplican su política sp= si la tiene y p= en caso contrario. Un subdominio puede publicar su propio registro para anular eso.
Tres causas habituales: el registro no tiene dirección rua=; la dirección está en otro dominio que no ha publicado el registro de permiso en sudominio._report._dmarc.dominiodeellos; o el propio registro no es válido, por ejemplo dos registros DMARC en un mismo nombre, que los receptores descartan. Este comprobador revisa las tres.
RFC 9989, que sustituyó a RFC 7489 en mayo de 2026, eliminó la etiqueta pct. Los receptores que siguen el nuevo estándar la ignoran y aplican la política a todo el correo que falla; los antiguos aún la respetan. La nueva etiqueta t=y es la sustituta para probar con suavidad una política más estricta.
Quarantine pide al receptor tratar el correo que falla como sospechoso, lo que en la práctica significa la carpeta de spam o correo no deseado. Reject pide al receptor rechazar el mensaje durante la entrega, así que nunca llega al destinatario. Ambas cuentan como aplicación de la política; reject es la protección más fuerte contra el correo falsificado.
Solo al resolver de DNS público que elija, Cloudflare o Google, porque consultar un registro DNS necesita el nombre. El resolver ve los nombres consultados y su dirección IP. Nada más sale de su dispositivo, y la pestaña del generador no envía nada en absoluto.
¿Sigue sin resolverlo? Pregunte sobre Comprobador de DMARC y cualquiera que lo sepa puede responder. No se necesita cuenta.