Ejemplos de registro DMARC para copiar (y entender)

v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.es

Plantilla 2 — Quarantine (primera aplicación)

Cuando las fuentes están alineadas, se sube un peldaño. El correo que falla se va a correo no deseado en lugar de a la bandeja. Aquí añadimos sp y np para cubrir los subdominios, y t=y para señalar que la política está en fase de prueba.

v=DMARC1; p=quarantine; sp=quarantine; np=reject; t=y; rua=mailto:dmarc@ejemplo.es

Conviene fijarse en np=reject desde el principio: los subdominios inexistentes no llevan ningún correo legítimo, así que mejor bloquearlos de inmediato (véase la política de subdominio). Una vez que los informes estén limpios y el modo de prueba resulte tranquilizador, se retira t=y.

Plantilla 3 — Reject (el objetivo)

La aplicación máxima. El correo falsificado en nombre del dominio se rechaza antes de llegar. Es el objetivo de la mayoría de los despliegues, que se alcanza una vez que los informes están demostradamente limpios desde hace varias semanas.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@ejemplo.es

Simétrico y limpio: raíz, subdominios existentes e inexistentes, todos en reject. Si un subdominio legítimo necesita un margen, no hay que bajar sp para todo el mundo: se le da su propio registro dedicado. La secuencia completa para llegar aquí sin romper nada se describe en llegar a p=reject sin romper el correo legítimo; para saber si el dominio está listo, la lista de comprobación de elegibilidad responde a la pregunta.

Plantilla 4 — Dominio aparcado o sin correo

¿Un dominio desde el que nunca sale correo (marca defensiva, nombre antiguo, reserva)? No debe quedarse sin DMARC: sería un blanco de suplantación gratuito. Se le aplica la política más estricta desde el principio, sin fase de observación: por definición, no puede bloquearse ningún correo legítimo.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@ejemplo.es

Es el mismo que la plantilla reject, pero puede publicarse de inmediato, sin pasar por none ni quarantine, ya que no hay nada que observar. Un dominio aparcado protegido es una puerta menos para los defraudadores.

Dónde publicar el registro

El punto que más bloquea a los principiantes no es el valor, sino el lugar. El registro se publica en el proveedor de DNS (el que gestiona la zona), como registro TXT, en el nombre _dmarc. Según la interfaz, se introduce o bien el nombre completo _dmarc.ejemplo.es, o bien simplemente _dmarc (la interfaz añade el dominio automáticamente). El valor es la cadena v=DMARC1; …, sin comillas que añadir a mano en la mayoría de las interfaces.

Cuidado con un error clásico: el registro no va en ejemplo.es directamente, sino en el subnombre _dmarc. Un registro DMARC puesto en la raíz nunca lo encontrarán los destinatarios. Otro punto: la propagación DNS no es instantánea; tras la publicación, hay que contar con unos minutos a unas horas antes de que el nuevo registro sea visible en todas partes, según el TTL de la zona. Concluir que «no funciona» cinco minutos después de haberlo puesto es precipitado; la comprobación correcta llega una vez completada la propagación.

Configuraciones por proveedor

El registro DMARC en sí es idéntico sea cual sea el proveedor de mensajería: es una propiedad del dominio, no de la plataforma de correo. Lo que cambia de un proveedor a otro es la alineación (SPF/DKIM) que DMARC viene a verificar. Algunas referencias:

• Google Workspace: la firma DKIM se activa desde la consola de administración (Apps → Google Workspace → Gmail → Autenticar el correo), que proporciona un registro DKIM que hay que publicar. Una vez que DKIM esté alineado con el dominio, el DMARC anterior funciona tal cual.
• Microsoft 365: DKIM se activa en el centro de seguridad (o mediante PowerShell) y firma con el dominio. SPF para Microsoft pasa por el include:spf.protection.outlook.com. El detalle de SPF está en SPF para Microsoft 365 y Google Workspace.
• OVH, Scaleway y proveedores europeos: la mecánica es la misma —se publica el TXT _dmarc en la zona DNS y se verifica que la plataforma de envío firma en DKIM con d=ejemplo.es.
• Plataformas de terceros (marketing, facturación, transaccional): cada una proporciona su propio procedimiento DKIM con la marca del remitente. Ahí es donde se juega la alineación real, fuente por fuente.

Dicho de otro modo, no existe un «registro DMARC especial para Gmail» o «especial para Microsoft»: existe un registro DMARC para el dominio, y un trabajo de alineación que hacer en cada remitente.

Alineación relajada o estricta (adkim / aspf)

Dos etiquetas opcionales merecen una palabra, porque aparecen a menudo en las plantillas que se encuentran en línea: adkim y aspf, que controlan el rigor de la alineación. En modo relajado (r, el valor por defecto), un subdominio cuenta como alineado con el dominio organizativo: un DKIM firmado d=mail.ejemplo.es alinea un From: en ejemplo.es. En modo estricto (s), ambos deben coincidir exactamente.

El consejo práctico: quedarse en relajado salvo razón concreta. El modo estricto rompe configuraciones perfectamente legítimas (plataformas que firman con un subdominio técnico) y solo aporta una ganancia en escenarios de seguridad muy específicos. Quien no sepa decir por qué pasaría a estricto, no lo necesita; por eso ninguna de las plantillas de arriba menciona estas etiquetas: su ausencia es la configuración correcta para la práctica totalidad de los dominios.

¿Hay que añadir ruf (informes forenses)?

Muchos ejemplos antiguos incluyen una etiqueta ruf= junto a rua=. En 2026, rara vez es útil: la mayoría de los grandes proveedores (Google, Microsoft, Yahoo) ya no envían informes forenses, y estos plantean cuestiones de privacidad, porque pueden contener encabezados e incluso extractos de mensajes reales. Salvo una necesidad de diagnóstico concreta y un marco RGPD controlado, ruf se deja de lado al empezar. La diferencia entre ambos tipos de informes se detalla en RUA vs RUF, y el ángulo de la privacidad en informes forenses y RGPD. Por esa razón, ninguna plantilla de arriba contiene ruf: empezar simple evita recoger datos sensibles que nadie va a explotar.

Errores de sintaxis frecuentes

• Olvidar rua. Un DMARC sin dirección de informe «funciona», pero deja a ciegas: nunca se sabrá quién envía en nombre del dominio ni si el endurecimiento es posible.
• Equivocarse de nombre de host. El registro va en _dmarc, no en la raíz del dominio.
• Mezclar varios registros DMARC. Solo debe haber un único registro TXT que empiece por v=DMARC1 en _dmarc. Dos registros = comportamiento indefinido, a menudo ignorado.
• Copiar una dirección rua de otro dominio. Enviar los informes a dmarc@otro-dominio.es exige una autorización del lado del dominio receptor (véase configurar la dirección rua). Para empezar, lo sensato es una dirección del propio dominio.
• Dejar t=y puesto. El modo de prueba es una fase de la subida, no una configuración permanente.

Tratar el registro como configuración

Un último hábito separa a los equipos serenos de los que entran en pánico meses después: conservar una traza escrita de cada modificación del registro DMARC. Las interfaces DNS rara vez ofrecen un historial —un valor sobrescrito desaparece, y con él el razonamiento que lo acompañaba. Anotar la fecha de cada cambio, lo que se modificó y por qué, allí donde el equipo ya documenta su infraestructura. Conviene decidir también quién es responsable de la entrada _dmarc, para que un colega bienintencionado no «limpie» una etiqueta que no reconoce. Las modificaciones DMARC son raras por naturaleza —justo por eso falla la memoria: el día de un incidente de entregabilidad, saber responder a «¿qué decía el registro antes y quién lo cambió?» transforma una tarde de arqueología en una verificación de cinco minutos.

¿Y después?

Una plantilla pegada no es más que un comienzo. El verdadero trabajo —alinear cada fuente para que el endurecimiento no bloquee a nadie— empieza después. Una vez publicado el registro, conviene verificarlo desde el punto de vista de un destinatario con el analizador DMARC gratuito: confirma que la sintaxis es válida, que la política se lee bien y, sobre todo, que las fuentes se alinean como se espera. Es la forma más rápida de transformar una plantilla genérica en una protección realmente adaptada al dominio, y de atrapar la errata o el registro duplicado que, de otro modo, pasaría inadvertido durante meses.