Comprobador de registros DMARC

El análisis de un registro TXT de DMARC es un paso fundamental para los administradores de correo que necesitan verificar la estructura, las políticas y las direcciones de reporte de sus dominios antes de publicarlos en el DNS o durante tareas de resolución de problemas. El Comprobador de registros DMARC procesa el valor del registro directamente en el navegador del usuario; no sube ni guarda la información, no escribe en el almacenamiento del navegador ni realiza peticiones externas relacionadas con el registro.

Funcionamiento del análisis de DMARC

La herramienta procesa una cadena de texto que representa el registro DMARC TXT proporcionado por el usuario, con un límite estricto de menos de 20.000 caracteres. Si el registro contiene fragmentos DNS TXT entrecomillados, estos se aceptan y se unen de forma automática antes de iniciar la evaluación.

Para que el análisis sea válido, el registro debe cumplir ciertas reglas estructurales estrictas:

• Debe comenzar obligatoriamente con el valor sensible a mayúsculas y minúsculas v=DMARC1.
• Este parámetro v=DMARC1 tiene que ser el primer término del registro.

El analizador desglosa cada componente (etiqueta o término) separado por puntos y comas, evalúa su sintaxis y determina su estado de vigencia según los estándares actuales.

Estructura de resultados y resumen DMARC

Una vez procesado el texto, la herramienta genera un desglose detallado estructurado en varias secciones específicas:

Resumen DMARC

Esta sección sintetiza la configuración operativa clave del registro:

• p: Muestra la política de acción para el dominio principal. Si no se incluye la etiqueta p, el sistema aplica por defecto el comportamiento de caída (fallback) a none.
• sp: Define la política aplicable a los subdominios.
• np: Especifica la política para subdominios que no existen. En ausencia de etiquetas específicas, las políticas de subdominios caen en cascada desde np hacia sp, y finalmente hacia p.
• DKIM / SPF: Detalla la configuración de alineación para SPF (aspf) y DKIM (adkim).
• rua / ruf: Indica la cantidad de direcciones de correo configuradas para recibir reportes.
• pct (RFC 7489): Muestra el porcentaje de mensajes a los que se aplica la política, un valor que se considera heredado (legacy).

Destinos de reportes (rua / ruf)

Muestra de forma específica los buzones receptores de datos:

• rua: Direcciones destinadas a recibir los informes agregados de actividad. Si no se define una dirección rua válida, no se solicitarán estos informes.
• ruf: Direcciones para el envío de informes de fallo forenses.

Términos analizados

Una tabla detallada que clasifica cada etiqueta encontrada bajo tres columnas:

1. Término: El nombre de la etiqueta DMARC.
2. Valor o calificador: El valor asignado a dicha etiqueta.
3. Tipo: El estado técnico de la etiqueta, que puede ser RFC 9989 (activo), RFC 7489 (histórico), Desconocido o ✕ DMARC (inválido).

Notas de sintaxis y política

El analizador evalúa la semántica del registro y genera advertencias o notas informativas basadas en las siguientes reglas de comportamiento y compatibilidad:

• Políticas de monitorización: Una política p=none se limita a monitorizar fallos de autenticación, pero no solicita a los servidores receptores que apliquen cuarentena o rechacen los correos que fallen.
• Modo de prueba (t=y): La presencia de la etiqueta de prueba t=y reduce la severidad de las políticas activas durante la fase de pruebas; rebaja la acción de quarantine a none, y la de reject a quarantine.
• Dependencias de reporte de fallos: La etiqueta fo (opciones de reporte de fallos) se ignora por completo si no se ha configurado una dirección de reporte de fallos ruf válida.
• Elementos obsoletos e históricos: El sufijo de tamaño !size en las URI de reporte se considera obsoleto y los servidores de correo actuales deben ignorarlo. Asimismo, los valores de la etiqueta pct son históricos y solo limitan la cobertura de la política en aquellos servidores receptores que todavía se rigen por especificaciones DMARC antiguas. Las etiquetas catalogadas como históricas pueden ser ignoradas por los sistemas receptores que siguen el estándar actual.

Errores y advertencias de validación

Durante la comprobación, la herramienta puede emitir mensajes de error específicos ante fallos de formato o de estructura:

• Pegue primero un registro DMARC. (si se intenta procesar un campo vacío).
• Ese registro es inusualmente grande. Manténgalo por debajo de 20.000 caracteres..
• El registro debe empezar por v=DMARC1..
• Término ‹position›: v=DMARC1 debe ser el primer término..
• ×2: ‹tag› (‹position›) (cuando una etiqueta aparece duplicada).
• name=value ✕ (‹position›) (si el término está malformado y no sigue el patrón de pares clave-valor separados por puntos y comas).
• ‹tag›=∅ (‹position›) (si la etiqueta carece de valor).
• ‹tag›=‹detail› ✕ (‹position›) (cuando el valor asignado no es válido para esa etiqueta).
• URI ✕: ‹tag› (‹position›) (si la dirección de reporte contiene un formato incorrecto).
• Desconocido: ‹tag› (‹position›) (etiquetas no registradas que los receptores DMARC ignorarán).
• RFC 7489 → RFC 9989: ‹tag› (‹position›) (etiquetas consideradas históricas en el estándar actual).

Preguntas frecuentes

¿Notas de sintaxis y política: p / sp / np?
La política principal (p) determina la acción por defecto. Si no se define, se asume p=none. Las políticas específicas de subdominios siguen una jerarquía de caída automática: si un subdominio no tiene una política de subdominio no existente (np) explícita, busca la política de subdominio general (sp), y si esta tampoco existe, aplica la política del dominio principal (p). El uso de t=y mitiga temporalmente estas políticas durante las pruebas.

¿RFC 9989: pct / rf / ri?
Bajo el estándar actual RFC 9989, parámetros como pct, rf y ri se clasifican como históricos. Las etiquetas activas bajo la norma vigente incluyen np, psd y t, mientras que las históricas provienen del marco de la RFC 7489.

¿Un resultado sin incidencias demuestra que mi configuración DMARC funciona?
No. Esta página solo comprueba el texto que pega. No consulta DNS, no amplía los registros del proveedor, no prueba una IP remitente ni confirma qué devolverá un servidor de correo receptor.