¿Qué es DMARC y cómo funciona?

DMARC es el registro que por fin vincula la autenticación del correo con la dirección que la gente realmente lee. SPF y DKIM pueden pasar los dos en un mensaje falsificado, porque ninguno comprueba la línea From visible. DMARC sí lo hace, y te permite indicar a los receptores qué hacer cuando esa comprobación falla. Esta es la página central de nuestras guías sobre DMARC: empieza aquí y sigue los enlaces de cada paso.

¿Qué es DMARC?

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. Desde mayo de 2026 se define en el RFC 9989, un documento de la categoría Standards Track que sustituyó al RFC 7489. Los informes pasaron a dos documentos complementarios: el RFC 9990 para los informes agregados y el RFC 9991 para los informes de fallos.

El registro en sí es un único registro TXT en _dmarc. delante de tu dominio:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Hace tres cosas:

1. Valida que el correo que usa tu dominio en el encabezado From proviene realmente de ti.
2. Establece una política para el correo que falla: none, quarantine o reject.
3. Solicita informes para que puedas ver todas las fuentes que envían como tu dominio.

DMARC no analiza el contenido ni mira el nombre visible del remitente. El RFC 9989 deja fuera de su alcance los ataques con el nombre visible y el análisis de contenido. Además, solo valida el dominio, no la parte de la dirección anterior a la @.

¿Cómo funciona DMARC con SPF y DKIM?

DMARC no autentica nada por sí mismo. Reutiliza los resultados de dos comprobaciones más antiguas:

• SPF (RFC 7208) comprueba si el servidor de envío está autorizado a usar el dominio del remitente del sobre (el MAIL FROM, que suele aparecer como Return-Path).
• DKIM (RFC 6376) comprueba una firma criptográfica añadida por el remitente. El dominio firmante es el valor d= del encabezado DKIM-Signature.

Después, el receptor se hace una sola pregunta: ¿pasó SPF o DKIM para un dominio alineado con el dominio del From? La sección 5.3.5 del RFC 9989 lo dice de forma sencilla: si uno o más identificadores autenticados están alineados con el Author Domain (dominio del autor), el mensaje pasa. Si ninguno lo está, falla.

Este es el orden de los pasos en el servidor receptor:

1. Leer el dominio del encabezado From: (el RFC 9989 lo llama Author Domain).
2. Buscar su registro DMARC, subiendo por el árbol DNS hasta el dominio organizativo si el nombre exacto no tiene ninguno.
3. Tomar el resultado de SPF para el dominio del MAIL FROM y el resultado de DKIM para cada firma válida.
4. Comprobar si algún dominio que pasa está alineado con el dominio del From.
5. Pasar o fallar, aplicar después la política local, teniendo en cuenta tu valor p=, y registrar el resultado para los informes.

Si quieres entender qué demuestra cada una de las tres comprobaciones por separado, lee SPF, DKIM y DMARC: diferencias.

¿Qué es la alineación de DMARC?

La alineación es el núcleo de DMARC. Sin ella, un atacante podría publicar SPF y DKIM para su propio dominio, pasar ambos y aun así poner tu dominio en el From. La sección 4.4.1 del RFC 9989 lo dice sin rodeos: "un mensaje puede llevar una firma válida de cualquier dominio, incluso de uno usado por un actor malintencionado".

Hay dos modos de alineación:

• Relajada (relaxed, la predeterminada): los dos dominios comparten el mismo dominio organizativo. mail.example.com está alineado con example.com.
• Estricta (strict): los dos dominios son idénticos.

Esta tabla sigue los ejemplos de la sección 4.4 del RFC 9989:

El RFC 9989 señala que "casi todos los propietarios de dominios han considerado suficiente la alineación relajada". Deja adkim y aspf en sus valores relajados predeterminados salvo que tengas un motivo concreto.

¿Qué significan p=none, p=quarantine y p=reject?

La etiqueta p es tu petición a los receptores sobre el correo que falla DMARC. La decisión final la toman los receptores. La sección 7.4 del RFC 9989 llega a decir que los receptores no deben rechazar un mensaje basándose únicamente en p=reject, sin otra información y análisis.

Microsoft documenta cómo trata cada una en el correo entrante cuando Honor DMARC record policy (respetar la política del registro DMARC) está activado: p=quarantine va a la carpeta Correo no deseado y p=reject se rechaza durante la sesión SMTP con el resultado dmarc=fail action=oreject (Microsoft Learn).

Otras dos etiquetas completan la política. sp la define para los subdominios existentes y np para los subdominios que no existen. Si se omite, np toma el valor de sp, y sp toma el de p. Nuestra guía de la política DMARC para subdominios explica esta herencia. La etiqueta t=y, nueva en el RFC 9989, pide a los receptores que apliquen tu política un nivel por debajo mientras haces pruebas. Todas las etiquetas se explican en ejemplos de registros DMARC.

¿Qué son los informes DMARC?

Cuando tu registro incluye rua=mailto:..., los receptores que admiten informes te envían informes agregados: archivos XML comprimidos que enumeran cada IP de envío, cuántos mensajes envió como tu dominio y si SPF y DKIM pasaron y estaban alineados. La sección 5.3.8 del RFC 9989 dice que los receptores deberían enviarlos al menos una vez cada 24 horas.

Los informes agregados son la forma de descubrir la herramienta de facturación, el CRM o el formulario web que envía como tu dominio sin autenticación. En bruto son difíciles de leer. Nuestro DMARC Report Analyzer (analizador de informes DMARC) gratuito convierte un informe en una tabla en tu navegador, y cómo leer los informes DMARC explica cada campo.

La etiqueta ruf solicita informes de fallos sobre mensajes concretos. El RFC 9989 señala que los receptores preocupados por la privacidad eliminan gran parte de sus datos o directamente no los envían, y Microsoft 365 no los envía. Empieza solo con rua.

¿Cómo configuro DMARC?

A grandes rasgos, siguiendo la sección 5.1 del RFC 9989 y la guía de DMARC de Google:

1. Haz una lista de todos los servicios que envían como tu dominio y configura en cada uno SPF o DKIM alineados. Nuestra guía de configuración de DKIM y las páginas de registros SPF por proveedor cubren los más habituales.
2. Publica p=none con una dirección rua. El DMARC Record Generator (generador de registros DMARC) crea el registro.
3. Lee los informes, corrige los remitentes que fallan y pasa después a p=quarantine y p=reject.

El procedimiento completo, con el registro de cada fase y cuánto tiempo mantenerla, está en cómo pasar DMARC de p=none a p=reject. Si un escáner te dice que tu política DMARC no está habilitada, empieza por cómo solucionar "DMARC policy not enabled". Un dominio que nunca envía correo puede saltarse el despliegue gradual y publicar p=reject directamente, como se explica en cómo proteger dominios aparcados contra la suplantación.

¿Necesito DMARC?

Si tu dominio envía correo, sí. Para los remitentes masivos ya es un requisito obligatorio:

• Google exige SPF, DKIM y DMARC a quienes envían cerca de 5.000 mensajes o más al día a cuentas personales de Gmail, con el dominio del From alineado con SPF o DKIM. La política puede ser none (directrices para remitentes de Google). Google Postmaster Tools muestra si Gmail considera que cumples.
• Yahoo exige a los remitentes masivos "publicar una política DMARC válida de al menos p=none" y dice que DMARC debe pasar (Yahoo Sender Hub). También insta encarecidamente a todos los demás remitentes a publicar una.

Los detalles están en nuestra guía sobre los requisitos de Gmail, Yahoo y Microsoft para remitentes masivos.

Muchos dominios grandes siguen sin protección. En nuestro análisis de los 1.000 primeros dominios de Tranco en octubre de 2026, el 26,5 % no tenía registro DMARC y el 38,3 % no aplicaba DMARC.

Qué no hace DMARC

DMARC es eficaz contra un ataque concreto: el correo que pone exactamente tu dominio en el From. No impide:

• Los dominios similares, como examp1e.com, que tienen su propio DNS. Consulta phishing con dominios similares.
• Los trucos con el nombre visible, en los que el nombre dice "CEO" pero la dirección es un buzón gratuito.
• El spam y el phishing que te envían desde dominios que se autentican correctamente.

Protege tu dominio en las bandejas de entrada de otros. El correo que llega a tu propio dominio sigue necesitando filtrado del correo entrante.

Nuestras guías sobre DMARC

Próximos pasos

1. Comprueba tu dominio con el DMARC Checker (verificador de DMARC). Muestra si tienes un registro, cuál es la política y si los informes están configurados.
2. Si no tienes registro, haz una lista de tus remitentes y confirma SPF y DKIM con el SPF Checker (verificador de SPF) y el DKIM Checker (verificador de DKIM).
3. Publica p=none con una dirección de informes usando el DMARC Record Generator.
4. Revisa al menos un mes de informes, corrige los remitentes que fallan y pasa después a quarantine y reject.

DMARC protege el nombre de tu dominio fuera de tu organización. Para el correo entrante, un filtro del correo entrante como iBlockSpam analiza el spam, el phishing y la suplantación antes de que lleguen a tus usuarios; consulta cómo funciona.

Cuando tu registro tenga una dirección de informes, la monitorización de DMARC de iBlockSpam puede leer los informes diarios por ti e indicarte cuándo tus remitentes están listos para una política más estricta. Si solo quieres saber cuándo cambian tus registros DMARC, SPF o MX, el Free Domain Watch (vigilancia gratuita del dominio) los comprueba cada semana sin costo.

Explora nuestras otras guías sobre SPF, DKIM y DMARC.