¿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. Imaginemos 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: direccion@ejemplo-empresa.es, DMARC plantea una pregunta más dura: ¿coincide el dominio autenticado con el dominio del From:? Para el atacante, no (malicioso.com ≠ ejemplo-empresa.es): DMARC falla y se aplica la política del dominio suplantado. Esa es la protección que SPF y DKIM por sí solos nunca dieron. Para la versión en profundidad, nuestra guía sobre cómo funcionan juntos SPF, DKIM y DMARC lo desarrolla.

Cómo es un registro DMARC

Un registro DMARC es un único TXT de DNS publicado en _dmarc.ejemplo.es:

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=none; rua=mailto:informes@ejemplo.es; 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 los subdominios (a menudo igualada a p).

Las tres políticas

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

• p=none — solo observación. Nada cambia para la entregabilidad; el registro se limita a recoger 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 nombre del dominio simplemente no se entrega.

Solo p=reject detiene realmente la suplantación. Vigilar en p=none no protege a nadie — solo revela hasta qué punto un dominio está 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 el dominio protegido en el From: sin autorización. Es una garantía fuerte — protege a los clientes, proveedores y empleados frente a las facturas falsas y las órdenes de transferencia fraudulentas emitidas «en nombre de la empresa» —, pero tiene un perímetro, y conocerlo evita una falsa sensación de seguridad.

DMARC no bloquea los dominios parecidos: un atacante que registra ejemplo-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 la 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 la identidad exacta del dominio 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 nombre del dominio, DMARC incluye un canal de retorno. Los destinatarios como Google, Microsoft y Yahoo envían informes agregados (XML) a la dirección rua= cada día, resumiendo cómo se comportó el correo que dice venir de ese dominio: 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). Un punto tranquilizador de entrada: no es una ruptura. Los registros siguen empezando por v=DMARC1, y no hay nada que cambiar 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 aplique aún de forma estricta»). La subida de nivel se apoya ahora 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: los registros actuales siguen siendo válidos, pero es el buen momento para retirar un pct que ya no sirve y poner un np=reject en los 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. Endurecer la política antes de que cada una esté autenticada y alineada arriesga a mandar el 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. Se inventaría cada fuente a partir de los informes agregados, se alinea cada una en SPF/DKIM, y luego se sube la política de quarantine a reject comprobando que los informes siguen limpios. Desplegamos toda la secuencia en llegar a p=reject sin romper el correo legítimo.

DMARC dentro de un programa de cumplimiento

Bajo 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 hay que defender. Los cuestionarios de ciberseguro y las evaluaciones de seguridad de proveedores preguntan cada vez más explícitamente qué política DMARC hay 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: 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 un dominio puede ser suplantado hoy y adjuntar el resultado al expediente.

En qué situación está un dominio

No hace falta adivinar. Una comprobación gratuita e instantánea de la postura DMARC, SPF y DKIM con nuestro analizador de dominios muestra la política actual, la alineación y una nota clara. El Observatorio DMARC permite además 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, un dominio solo debe tener un único registro TXT _dmarc. Un segundo vuelve ambigua la política, y los destinatarios pueden ignorar los dos — dejando el dominio expuesto justo cuando se le cree cubierto. Todo se fusiona 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 las propias facturas, recibos y restablecimientos de contraseña al vacío. La subida pasa 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. Aplicar en el dominio raíz dejando sp permisivo abre la puerta a suplantar news.ejemplo.es o mail.ejemplo.es. sp (y np) se configuran 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 su exposición.
• Publicar sin dirección rua. Sin informes agregados se navega a ciegas: endurecer con serenidad es imposible cuando no se ve quién envía legítimamente en nombre del dominio. Un rua va siempre incluido.
• Olvidar los dominios inactivos. Los dominios que una organización posee pero desde los que no envía son objetivos de suplantación favoritos, precisamente porque nadie los vigila. Cada dominio inactivo merece un p=reject estricto.

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 aporta en lugar de las suposiciones.

Thomas toma el relevo

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

Analizar un dominio gratis o crear una cuenta y dejar que Thomas haga el trabajo pesado.