Los registros DMARC (Domain-based Message Authentication, Reporting and Conformance) sirven como políticas basadas en DNS que indican a los servidores de correo receptores cómo manejar los emails de tu dominio. Comprender la sintaxis precisa de los registros DMARC es crucial para las organizaciones que implementan protocolos robustos de autenticación de email en 2026.

Un registro DMARC consiste en pares etiqueta-valor separados por punto y coma, publicado como un registro TXT en la ubicación DNS específica _dmarc.tudominio.com. Cada componente cumple una función distinta en la cadena de autenticación, desde la aplicación de políticas hasta la configuración de informes forenses.

I. Visión General de la Estructura del Registro DNS DMARC

Proceso de cinco pasos para crear registros DMARC, desde la etiqueta de versión hasta la publicación en DNS.

Formato de Sintaxis Básica

Los registros DMARC siguen un formato estandarizado etiqueta=valor con requisitos específicos de ordenamiento:

v=DMARC1; p=policy; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=subdomain_policy; pct=percentage; adkim=alignment; aspf=alignment; rf=format; ri=interval; fo=options

Etiquetas Requeridas vs Opcionales

Etiquetas Requeridas:

  • v (versión)
  • p (política)

Etiquetas Opcionales:

  • rua (informes agregados)
  • ruf (informes forenses)
  • sp (política de subdominios)
  • pct (porcentaje)
  • adkim (alineación DKIM)
  • aspf (alineación SPF)
  • rf (formato de informe)
  • ri (intervalo de informe)
  • fo (opciones de fallo)

II. Etiqueta de Versión (v)

Sintaxis

v=DMARC1

La etiqueta de versión debe ser siempre el primer componente en cualquier registro DMARC y actualmente solo soporta un valor: DMARC1. Esto identifica el registro como una política DMARC para los servidores de correo receptores.

Ejemplos

v=DMARC1; p=none
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Casos Extremos

  • La ausencia de la etiqueta de versión hace que todo el registro sea inválido
  • La etiqueta de versión apareciendo en cualquier lugar excepto la primera posición causa fallos de análisis
  • Cualquier valor diferente a DMARC1 resulta en rechazo del registro

III. Etiqueta de Política (p)

Sintaxis

p=none|quarantine|reject

La etiqueta de política define cómo los servidores receptores deben manejar emails que fallan las verificaciones de autenticación DMARC.

Valores de Política Explicados

none: Modo de monitoreo – no se toma acción en mensajes fallidos

v=DMARC1; p=none; rua=mailto:[email protected]

quarantine: Mensajes fallidos entregados a carpetas de spam/basura

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

reject: Mensajes fallidos bloqueados completamente a nivel SMTP

v=DMARC1; p=reject; rua=mailto:[email protected]

Casos Extremos

  • La aplicación de políticas depende de la implementación del receptor
  • Algunos receptores pueden tratar cuarentena como rechazo por razones de reputación
  • La escalación de políticas debe seguir patrones de implementación gradual (none → quarantine → reject)

IV. URI de Informes Agregados (rua)

Sintaxis

rua=mailto:[email protected],mailto:[email protected]

Especifica direcciones de email para recibir informes agregados XML que contienen estadísticas de autenticación.

Ejemplos de Configuración

Destinatario único:

rua=mailto:[email protected]

Múltiples destinatarios:

rua=mailto:[email protected],mailto:[email protected]

Informes de dominio externo:

rua=mailto:[email protected]

Casos Extremos

  • Los destinatarios de dominios externos requieren registros de autorización DNS
  • Los informes son generados diariamente por la mayoría de los receptores (ciclos de 24 horas)
  • La ausencia de la etiqueta rua elimina la visibilidad del rendimiento DMARC
  • Algunos receptores imponen límites de tamaño en los destinos de informes

V. URI de Informes Forenses (ruf)

Sintaxis

ruf=mailto:[email protected]

Define destinatarios para informes forenses detallados de fallos individuales de autenticación.

Ejemplos

ruf=mailto:[email protected]
v=DMARC1; p=quarantine; ruf=mailto:[email protected],mailto:[email protected]

Casos Extremos

  • Muchos receptores ya no envían informes forenses debido a preocupaciones de privacidad
  • Los informes forenses contienen encabezados completos de mensajes y datos potencialmente sensibles
  • Los destinatarios de dominios externos requieren autorización DNS explícita
  • El volumen puede ser abrumador para dominios con alto tráfico de email

VI. Política de Subdominio (sp)

Sintaxis

sp=none|quarantine|reject

Establece herencia de política para subdominios cuando no existe un registro DMARC explícito a nivel de subdominio.

Ejemplos de Configuración

Política de subdominio más estricta:

v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]

Políticas coincidentes:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Casos Extremos

  • Los registros DMARC específicos de subdominio anulan las configuraciones sp
  • El comportamiento predeterminado aplica la política del dominio padre a los subdominios cuando sp está ausente
  • Los subdominios organizacionales pueden requerir diferentes enfoques de política

VII. Etiqueta de Porcentaje (pct)

Implementación de DMARC en tres fases, desde la monitorización hasta la aplicación total con pruebas porcentuales.

Sintaxis

pct=1-100

Controla el porcentaje de mensajes fallidos sujetos a la aplicación de la política DMARC.

Ejemplos

Implementación gradual:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

Aplicación completa (predeterminado):

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

Casos Extremos

  • El valor predeterminado es 100 cuando se omite la etiqueta pct
  • Útil para implementación gradual de políticas y pruebas
  • El muestreo aleatorio puede crear experiencias inconsistentes para los usuarios
  • No todos los receptores honran las especificaciones de porcentaje

VIII. Modo de Alineación DKIM (adkim)

Sintaxis

adkim=r|s

Define requisitos de alineación entre el dominio de la firma DKIM y el dominio del encabezado From.

Modos de Alineación

Relajado (r) – Predeterminado:

v=DMARC1; p=quarantine; adkim=r; rua=mailto:[email protected]
  • Permite alineación de dominio organizacional (subdomain.example.com se alinea con example.com)

Estricto (s):

v=DMARC1; p=quarantine; adkim=s; rua=mailto:[email protected]
  • Requiere coincidencia exacta de dominio

Casos Extremos

  • La alineación relajada acomoda servicios legítimos de email de subdominio
  • La alineación estricta previene la suplantación de subdominios pero puede romper flujos legítimos de email
  • Múltiples firmas DKIM evaluadas independientemente para alineación

IX. Modo de Alineación SPF (aspf)

Sintaxis

aspf=r|s

Especifica requisitos de alineación entre el dominio Return-Path de SPF y el dominio del encabezado From.

Ejemplos

Alineación SPF relajada:

v=DMARC1; p=none; aspf=r; adkim=s; rua=mailto:[email protected]

Alineación SPF estricta:

v=DMARC1; p=quarantine; aspf=s; rua=mailto:[email protected]

Casos Extremos

  • Los escenarios de reenvío a menudo rompen la alineación SPF independientemente del modo
  • Los servicios de email de terceros requieren configuración cuidadosa de Return-Path
  • El modo relajado acomoda estructuras de dominio organizacional

X. Formato de Informe (rf)

Sintaxis

rf=afrf|iodef

Especifica preferencia de formato para informes forenses.

Opciones de Formato

Authentication Failure Report Format (afrf) – Predeterminado:

v=DMARC1; p=none; rf=afrf; ruf=mailto:[email protected]

Incident Object Description Exchange Format (iodef):

v=DMARC1; p=none; rf=iodef; ruf=mailto:[email protected]

Casos Extremos

  • La mayoría de los receptores usan afrf por defecto independientemente de la especificación rf
  • El formato iodef raramente se implementa en la práctica
  • La preferencia de formato puede ser ignorada por los sistemas de informes

XI. Intervalo de Informe (ri)

Sintaxis

ri=seconds

Solicita intervalo específico para la generación de informes agregados.

Ejemplos

Informes diarios (86400 segundos):

v=DMARC1; p=none; ri=86400; rua=mailto:[email protected]

Informes semanales (604800 segundos):

v=DMARC1; p=none; ri=604800; rua=mailto:[email protected]

Casos Extremos

  • La mayoría de los receptores generan informes en sus propios horarios independientemente del valor ri
  • La práctica estándar es la generación diaria de informes
  • Los intervalos más cortos raramente son honrados por los principales proveedores de email

XII. Opciones de Fallo (fo)

Sintaxis

fo=0|1|d|s

Controla las condiciones que activan la generación de informes forenses.

Opciones de Fallo Explicadas

fo=0 (Predeterminado): Informes generados cuando tanto SPF como DKIM fallan

v=DMARC1; p=none; fo=0; ruf=mailto:[email protected]

fo=1: Informes generados cuando SPF o DKIM fallan

v=DMARC1; p=none; fo=1; ruf=mailto:[email protected]

fo=d: Informes generados cuando DKIM falla

v=DMARC1; p=none; fo=d; ruf=mailto:[email protected]

fo=s: Informes generados cuando SPF falla

v=DMARC1; p=none; fo=s; ruf=mailto:[email protected]

Casos Extremos

  • Múltiples valores pueden combinarse: fo=1:d:s
  • Los informes forenses están cada vez más deshabilitados por los receptores
  • Los dominios de alto volumen deben usar fo=0 para minimizar el volumen de informes

XIII. Ejemplos de Configuración Avanzada

Implementación Empresarial

v=DMARC1; p=reject; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1; rf=afrf; ri=86400

Implementación Gradual

v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Política Enfocada en Subdominios

v=DMARC1; p=none; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]

XIV. Requisitos de Publicación DNS

Los registros DMARC deben publicarse como registros TXT en _dmarc.tudominio.com con la configuración DNS adecuada:

Consideraciones de TTL

  • TTL recomendado: 300-3600 segundos para cambios de política
  • Valores TTL más bajos permiten actualizaciones de política más rápidas
  • Valores TTL más altos reducen la carga de consultas DNS

Límites de Registro

  • Un solo registro DMARC por dominio (múltiples registros causan fallos)
  • La longitud máxima del registro varía según el proveedor DNS
  • Los registros largos pueden requerir división de registros TXT

XV. Errores Comunes de Sintaxis

Problemas de Espaciado

# Incorrecto - espacios en nombres de etiquetas
v = DMARC1; p = none

# Correcto
v=DMARC1; p=none

Sensibilidad a Mayúsculas

# Incorrecto - las mayúsculas importan para los valores
v=dmarc1; p=NONE

# Correcto
v=DMARC1; p=none

Problemas de Delimitadores

# Incorrecto - coma en lugar de punto y coma
v=DMARC1, p=none

# Correcto
v=DMARC1; p=none

Las organizaciones que implementan políticas DMARC se benefician de usar Skysnag Protect para monitorear el rendimiento DMARC, validar la sintaxis de registros y recibir informes detallados de autenticación. La plataforma proporciona visibilidad en tiempo real del estado de autenticación de email y ayuda a identificar problemas de configuración antes de que impacten la entrega de email.

XVI. Conclusiones Clave

La sintaxis de registros DMARC requiere formato preciso con etiquetas obligatorias de versión y política, mientras que las etiquetas opcionales proporcionan control de informes y alineación. La implementación exitosa demanda comprender la función de cada componente, publicación DNS adecuada y escalación gradual de políticas. El monitoreo regular a través de informes agregados asegura la efectividad de la autenticación mientras que los informes forenses ayudan a identificar patrones específicos de fallo.

La configuración DMARC adecuada protege dominios de ataques de suplantación mientras mantiene la entrega legítima de email cuando las reglas de sintaxis se siguen correctamente. Las organizaciones deben comenzar con políticas de monitoreo, validar la sintaxis completamente e implementar autorización de informes externos cuando usen servicios DMARC de terceros.