Ir al contenido principal

DMARC Validator

Valida la sintaxis DMARC antes de publicar y corrige errores en segundos

¿Cómo corregir errores de sintaxis DMARC? Pega tu registro DMARC abajo y valida su sintaxis al instante. Un error de sintaxis DMARC significa que tu política es ignorada silenciosamente por Gmail, Outlook y todos los servidores destinatarios.

Qué comprobamos

  • Sintaxis y cumplimiento de RFC 7489
  • Política (p, sp) y nivel de protección
  • Alineación de DKIM y SPF
  • Cobertura (pct) y reporting (rua, ruf)

¿Por qué validar la sintaxis DMARC antes de publicar?

Un registro DMARC mal formateado es ignorado silenciosamente por Gmail, Outlook, Yahoo y todos los servidores destinatarios. No se emite ninguna alerta. Tus correos quedan sin protección contra suplantación y phishing.

El validador lee tu registro antes de la publicación DNS, comprueba cada etiqueta y verifica los URIs de reporte. Corriges los errores de inmediato, sin esperar 24 a 48 horas de propagación para descubrir que un detalle impide aplicar la política.

Etiquetas DMARC según la RFC 7489

La RFC 7489 define cada etiqueta autorizada en un registro DMARC. El validador comprueba el nombre, la posición y el valor de cada etiqueta.

EtiquetaRolEjemplo
vVersión del protocolo, siempre en primera posiciónv=DMARC1
pPolítica aplicada al dominio raízp=quarantine
spPolítica aplicada a los subdominiossp=reject
adkimModo de alineación DKIM, r (relajado) o s (estricto)adkim=s
aspfModo de alineación SPF, r o saspf=r
pctPorcentaje de mensajes sujetos a la política, 1 a 100pct=50
ruaDestinos de los reportes agregados (URI mailto)rua=mailto:dmarc@captaindns.com
rufDestinos de los reportes forenses (URI mailto)ruf=mailto:forensic@captaindns.com
foOpciones de generación de reportes forensesfo=1

Las etiquetas v y p son obligatorias. Las demás recuperan valores por defecto si se omiten (adkim=r, aspf=r, pct=100).

Ejemplos de corrección antes y después

El validador señala cada error de sintaxis con su posición. A continuación, tres casos frecuentes observados en registros publicados.

URI rua mal formado:

- v=DMARC1; p=reject; rua=reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com

El prefijo mailto: es obligatorio según la RFC 7489.

Política p inválida:

- v=DMARC1; p=monitor; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com

Solo se aceptan los valores none, quarantine y reject.

pct fuera de rango:

- v=DMARC1; p=quarantine; pct=150; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@captaindns.com

El valor pct debe ser un entero entre 1 y 100.

Diagnósticos comunes del validador

El validador devuelve un código corto por cada anomalía detectada. Los códigos siguientes son los más frecuentes.

CódigoCausaAcción
missing_version_tagEtiqueta v=DMARC1 ausenteAñadir v=DMARC1 en primera posición
unsupported_versionValor de v= distinto de DMARC1Reemplazar por v=DMARC1
missing_policyEtiqueta p= ausenteAñadir p=none, p=quarantine o p=reject
invalid_policyValor de p= fuera de none/quarantine/rejectCorregir el valor
invalid_subdomain_policyValor de sp= inválidoUsar none, quarantine o reject
invalid_alignmentValor de adkim= o aspf= distinto de r/sAjustar a r o s
invalid_percentpct= fuera del rango 1-100Usar un entero entre 1 y 100
invalid_rua_uriURI rua mal formadoUsar mailto:direccion@dominio
invalid_ruf_uriURI ruf mal formadoUsar mailto:direccion@dominio
invalid_failure_optionValor fo= no reconocidoUsar 0, 1, d o s
duplicate_tagEtiqueta declarada dos vecesConservar una sola aparición
unknown_tagNombre de etiqueta no reconocidoVerificar la ortografía con la RFC 7489
record_trailing_quoteCadena TXT terminada en comillaEliminar la comilla final

Los códigos de advertencia (policy_none, pct_less_than_100, subdomain_policy_none) señalan una configuración válida pero parcial: la protección permanece incompleta mientras la política se mantiene en none o pct está por debajo de 100.

FAQ - Preguntas frecuentes

¿Qué progresión adoptar para la política p=?

Empieza siempre con p=none para observar el tráfico mediante reportes agregados (rua). Una vez que SPF y DKIM están alineados en todas tus fuentes legítimas, pasa a p=quarantine y después a p=reject. Evita saltar directamente a p=reject: los reportes rua de la fase de observación casi siempre revelan flujos legítimos olvidados.

¿Debo configurar ruf además de rua?

No al principio. Los reportes rua (agregados, diarios) son esenciales para dirigir tu despliegue. Los reportes ruf (forenses, por mensaje fallido) generan un volumen importante y pueden contener datos personales. Actívalos solo si dispones de un pipeline de análisis y de un dictamen jurídico sobre la recolección de estos datos.

¿Debo configurar la etiqueta sp= en los subdominios?

Por defecto, los subdominios heredan la política p. Configura sp= únicamente si la política de los subdominios debe diferir del dominio raíz. Verifica que SPF y DKIM estén alineados en cada subdominio emisor antes de endurecer sp=.

¿El validador aplica las reglas DMARCbis?

Esta versión aplica las reglas de RFC 7489. Para anticipar la transición a DMARCbis (eliminación de pct, ri, rf, incorporación de np, psd, t), usa el DMARCbis Checker o la herramienta de migración DMARCbis.


Herramientas complementarias

HerramientaUtilidad
DMARC CheckerVerificar la publicación y resolver el registro DMARC desde el DNS
Generador DMARCCrear un registro DMARC conforme a la especificación
Validador SPFValidar la sintaxis SPF de tu dominio
Validador DKIMValidar la sintaxis de una clave DKIM
Migración DMARCbisMigrar un registro DMARC al nuevo estándar
Monitoring DMARCRecibe y analiza automáticamente tus informes DMARC agregados

Lecturas recomendadas

Referencia: RFC 7489 - Domain-based Message Authentication, Reporting and Conformance.