¿Qué es DMARC y cómo detiene la suplantación de correo?

La idea clave: la alineación

La alineación es lo que hace que DMARC sea más fuerte que SPF y DKIM juntos. Imagina a un atacante que controla malicioso.com. Puede configurar un SPF y un DKIM perfectos para malicioso.com — así que su correo pasa esos controles. Pero cuando suplanta From: tu@tu-empresa.es, DMARC plantea una pregunta más dura: ¿coincide el dominio autenticado con el dominio del From:? Para el atacante, no (malicioso.com ≠ tu-empresa.es): DMARC falla y se aplica tu política. Esa es la protección que SPF y DKIM por sí solos nunca te dieron. Para la versión en profundidad, consulta nuestra guía sobre cómo funcionan juntos SPF, DKIM y DMARC.

Cómo es un registro DMARC

Un registro DMARC es un único TXT de DNS publicado en _dmarc.ton-domaine.fr:

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=none; rua=mailto:rapports@ton-domaine.fr; adkim=s; aspf=s"

Las etiquetas que más importan:

• p — la política: none, quarantine o reject.
• rua — la dirección que recibe los informes agregados diarios (el bucle de retroalimentación).
• adkim / aspf — el rigor de la alineación: s (strict) o r (relaxed).
• sp — la política para tus subdominios (a menudo igualada a p).

Las tres políticas

La aplicación de DMARC es una escalera, y el peldaño que elijas cambia lo que los destinatarios hacen con el correo no autenticado:

• p=none — solo observación. Nada cambia para la entregabilidad; solo recoges informes. Es donde se empieza y, por desgracia, donde la mayoría de los dominios se quedan para siempre.
• p=quarantine — el correo no autenticado va a spam. Una defensa real, aunque flexible.
• p=reject — el correo no autenticado se rechaza en la puerta. Ese es el objetivo: el correo suplantado en tu nombre simplemente no se entrega.

Solo p=reject detiene realmente la suplantación. Vigilar en p=none no protege a nadie — solo te dice hasta qué punto estás expuesto. Es justo lo que confirma nuestro Observatorio DMARC: en la mayoría de los sectores analizados, la mayor parte de los dominios sigue bloqueada en p=none, es decir, visible pero no protegida.

Lo que DMARC garantiza — y lo que no

Visto desde la dirección no técnica, DMARC se resume en una promesa precisa: una vez en p=reject, ya nadie puede entregar un correo que muestre exactamente tu dominio en el From: sin tu autorización. Es una garantía fuerte — protege a tus clientes, proveedores y empleados frente a las facturas falsas y las órdenes de transferencia fraudulentas emitidas «en tu nombre» —, pero tiene un perímetro, y conocerlo te evita una falsa sensación de seguridad.

DMARC no bloquea los dominios parecidos: un atacante que registra tu-empresa-facturacion.com, o sustituye una «l» por un «1», se cuela por completo, ya que suplanta un dominio que le pertenece de verdad. Tampoco impide el engaño sobre el nombre visible — «Dirección General» delante de una dirección de correo web cualquiera — ni el envío desde un buzón legítimo comprometido, que se autentica a la perfección. Y no filtra el phishing entrante procedente de los dominios de los demás: es el DMARC de los demás el que protege tu bandeja de entrada. Cartografiamos estas técnicas vecinas en nuestro panorama de la suplantación de correo. DMARC es, por tanto, una pieza imprescindible, no un escudo total: bloquea tu identidad exacta y deja los demás vectores a la concienciación y al filtrado.

Cómo funcionan los informes DMARC

Como no se puede aplicar una política sin saber quién envía legítimamente en tu nombre, DMARC incluye un canal de retorno. Los destinatarios como Google, Microsoft y Yahoo envían informes agregados (XML) a tu dirección rua= cada día, resumiendo cómo se comportó el correo que dice venir de ti: qué IP lo emitieron, en qué volumen y si pasó SPF, DKIM y la alineación. Esos informes son el mapa que sirve para encontrar y corregir cada fuente legítima antes de endurecer la política. Los detallamos en leer los informes agregados DMARC.

DMARC evoluciona: qué cambia DMARCbis (2026)

En mayo de 2026, el IETF publicó DMARCbis — la versión modernizada del estándar, repartida en tres RFC: 9989 (el propio protocolo), 9990 (informes agregados) y 9991 (informes de fallo). Juntas reemplazan la RFC 7489 original y llevan DMARC, por primera vez, a la vía de los estándares (Proposed Standard). Tranquilízate de inmediato: no es una ruptura. Los registros siguen empezando por v=DMARC1, y no tienes que cambiar nada para seguir protegido. Esto es lo esencial de lo que se mueve:

• La etiqueta pct desaparece. El despliegue «sobre un porcentaje del correo» resultó poco fiable y se retira, reemplazado por un modo de prueba binario: la etiqueta t (t=y señala «estoy experimentando, no apliques aún de forma estricta»). Para subir de nivel, ahora te apoyas en las políticas de subdominio y en la observación de los informes, no en un porcentaje.
• Dos nuevas etiquetas de subdominio. np define la política para los subdominios inexistentes — un objetivo de suplantación clásico, porque nadie los vigila — y psd marca los dominios de sufijo público (registros).
• El DNS Tree Walk reemplaza la Public Suffix List. Para determinar el «dominio organizativo», DMARCbis consulta el DNS paso a paso (8 consultas como máximo) en lugar de depender de una lista externa mantenida a mano — más robusto y más predecible.

El resto — p, sp, rua, ruf, adkim, aspf, fo — conserva exactamente el mismo significado. En la práctica: tu registro actual sigue siendo válido, pero es el buen momento para retirar un pct que ya no sirve y poner un np=reject en tus subdominios fantasma.

Por qué la mayoría de los dominios se quedan bloqueados en p=none

Publicar p=none es fácil; superarlo es donde los equipos se atascan. La razón es el miedo: las organizaciones emiten desde muchos más sitios de los que creen — la plataforma de marketing, el CRM, la facturación, el soporte, esa aplicación que un equipo configuró hace dos años. Endurece la política antes de que cada una esté autenticada y alineada, y te arriesgas a mandar tu propio correo legítimo a spam. Así que el registro se queda en p=none, en vigilancia eterna, mientras los suplantadores operan a sus anchas.

La salida no es el valor, es el método. Inventarías cada fuente a partir de los informes agregados, alineas cada una en SPF/DKIM, y luego subes la política de quarantine a reject comprobando que los informes siguen limpios. Desplegamos toda la secuencia en llegar a p=reject sin romper tus emails.

DMARC dentro de un programa de cumplimiento

Si llevas el sombrero de CISO o de DPO, DMARC tiene una segunda vida más allá de lo técnico: es una pieza que reaparece en casi todos los expedientes que tienes que defender. Los cuestionarios de ciberseguro y las evaluaciones de seguridad de proveedores preguntan cada vez más explícitamente qué política DMARC tienes publicada — y un p=none queda mal ahí. Los grandes proveedores de correo para consumidores ya la exigen a los remitentes de gran volumen, lo que convierte una simple recomendación en una condición de entregabilidad. Varios Estados la han hecho obligatoria para sus propias administraciones — señal de que el estándar abandonó hace tiempo el terreno del «estaría bien tenerlo». Y dentro de un sistema de gestión de la seguridad de tipo ISO 27001, una política DMARC aplicada documenta de forma concreta una medida de reducción del riesgo de fraude por suplantación de identidad, mientras que los informes agregados aportan una prueba verificable y continua de que la medida funciona de verdad — justo lo que a un auditor le gusta ver.

El ángulo del cumplimiento tiene una gran virtud: le pone una fecha límite a un proyecto que la técnica por sí sola deja fácilmente para más adelante. Un buen punto de partida para objetivar la urgencia: comprobar negro sobre blanco si tu dominio puede ser suplantado hoy y adjuntar el resultado al expediente.

Comprueba en qué situación está tu dominio

No hace falta adivinar. Lanza una comprobación gratuita e instantánea de la postura DMARC, SPF y DKIM de tu dominio con nuestro analizador de dominios — muestra tu política actual, la alineación y una nota clara. También puedes recorrer el Observatorio DMARC para ver cómo se comparan sectores enteros.

Los errores DMARC habituales que evitar

Incluso los equipos que publican DMARC tropiezan a menudo con los mismos detalles, y cada uno socava en silencio la protección:

• Dos registros DMARC. Igual que con SPF, tu dominio solo debe tener un único registro TXT _dmarc. Un segundo vuelve ambigua la política, y los destinatarios pueden ignorar los dos — dejándote expuesto cuando crees estar cubierto. Fusiona todo en un solo registro.
• Saltar directamente a p=reject. Aplicar antes de que cada fuente legítima esté alineada es la forma más rápida de mandar tus propias facturas, recibos y restablecimientos de contraseña al vacío. Sube por none y luego quarantine, vigilando los informes en cada etapa.
• Ignorar la política de subdominio. La etiqueta sp controla los subdominios, y con DMARCbis la etiqueta np cubre ahora los subdominios inexistentes. Si aplicas en tu dominio raíz pero dejas sp permisivo, los atacantes simplemente suplantan news.tu-dominio.es o mail.tu-dominio.es. Configura sp (y np) de forma deliberada, en general como p.
• Considerar p=none como la línea de meta. La vigilancia es el punto de partida, no el destino. Un registro que nunca supera none no protege a nadie — solo documenta tu exposición.
• Publicar sin dirección rua. Sin informes agregados navegas a ciegas: nunca podrás endurecer con serenidad porque no ves quién envía legítimamente en tu nombre. Incluye siempre un rua.
• Olvidar los dominios inactivos. Los dominios que posees pero desde los que no envías son objetivos de suplantación favoritos, precisamente porque nadie los vigila. Publica un p=reject estricto en cada dominio inactivo.

Ninguno es difícil de corregir; es sobre todo cuestión de paciencia y de buenos datos — exactamente lo que un proceso guiado y basado en los informes te aporta en lugar de las suposiciones.

Deja que Thomas tome el relevo

Llegar a p=reject es un proyecto, pero no tiene por qué ser tu proyecto. Thomas, tu CISO virtual, nombra cada fuente de envío a partir de tus informes, genera el DNS exacto para pegar (etiquetas DMARCbis incluidas), evalúa tu preparación sobre datos deslizantes y te dice el momento preciso para endurecer sin riesgo — de p=none hasta p=reject, sin bloquear un solo correo legítimo.

Analiza tu dominio gratis → o crea una cuenta y deja que Thomas haga el trabajo pesado.