DMARC: qué es y para qué sirve

Dicho de otra forma: si DKIM es la tarjeta de embarque y el registro SPF es la lista del personal autorizado, DMARC es el control que compara el nombre de la tarjeta con el del documento de identidad. Y decide qué pasa si no coinciden: te deja pasar tomando nota, te aparta a un lado, o no embarcas.

Qué comprueba DMARC que no comprueban SPF ni DKIM

Un correo lleva varias identidades y cada mecanismo verifica una distinta. El registro SPF comprueba la dirección del sobre. DKIM comprueba el dominio que firma el mensaje. Ninguno de los dos mira la dirección que aparece en el «De», que es la única que ve tu cliente.

Ese hueco es el que cierra DMARC, y tiene nombre propio: alineación. DMARC comprueba que el dominio del «De» coincida con el dominio que SPF o DKIM acaban de validar.

Por eso un correo puede pasar SPF con nota y suplantarte igualmente: si el sobre sale con el dominio de otro y el «De» lleva el tuyo, SPF dice que todo bien, porque él solo miró el sobre. DMARC es el que se da cuenta.

Cuándo pasa y cuándo falla

Aquí está la regla que más se cuenta mal:

Falla solo cuando ninguno de los dos lo consigue.

¿Y por qué basta con uno? Porque el SPF se rompe con los reenvíos. Cuando alguien reenvía tu correo, el mensaje sale del servidor de quien lo reenvía, que no está en tu lista de autorizados, y el SPF falla aunque el correo sea legítimo. DKIM, en cambio, viaja con el mensaje y sobrevive al reenvío. Exigir los dos habría dejado sin entregar una montaña de correo bueno.

Qué aspecto tiene un registro DMARC

Es un registro TXT, pero no va en el dominio: va en un subdominio llamado _dmarc. Para tudominio.com, el registro se publica en _dmarc.tudominio.com.

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

De todas las etiquetas posibles, solo dos son obligatorias, y v tiene que ir la primera:

El error del mailto:

La dirección de los informes tiene que ir precedida de mailto:. No es un adorno: la especificación obliga a que sea una URI, y sin ese prefijo el valor no es válido.

Es el fallo que más veo copiado de guías y de diapositivas de formación, porque a simple vista el registro parece correcto:

[email protected]      ← mal, no llegará ningún informe
rua=mailto:[email protected]   ← bien

Las tres políticas

Y aquí la confusión más cara de todas: p=none no te protege de nada. Es un modo de observación. Sirve para ver quién está enviando con tu dominio, no para impedirlo. Muchos dominios llevan años con p=none convencidos de que tienen DMARC «puesto»; lo que tienen es un contador.

Y en el otro extremo está el error contrario. Con p=reject, un correo que no alinee se rechaza en el propio servidor: no llega a la bandeja de entrada y tampoco a la carpeta de spam. Y el correo que no alinea suele ser el tuyo: la factura que manda tu programa de facturación, el aviso de pedido, el mensaje de recuperación de contraseña, la newsletter que sale desde tu plataforma de envíos. Todo eso usa tu dominio desde sistemas que quizá no has autenticado todavía.

Sí se genera un rebote, pero llega al servidor que envió el mensaje, no a ti. Si envías desde una plataforma, ese rechazo se queda en sus registros: tu bandeja no se entera. Por eso lo habitual es descubrirlo tarde, cuando un cliente dice que no ha recibido nada.

El camino es siempre el mismo: empezar en none, leer los informes hasta reconocer todos los sistemas que envían en tu nombre, arreglar los que fallen, y solo entonces subir. Ni quedarse en none para siempre, ni saltar a reject sin haber mirado los informes.

Cumplir y estar protegido no son lo mismo

Es la confusión más extendida. Un dominio puede estar «en regla» con los tres grandes y seguir estando abierto de par en par: cualquiera puede mandar correos con tu nombre y llegarán igual, porque tú no le has dicho a nadie que los pare.

Y quedarse en p=none para siempre ya no sale gratis. En 2026 los proveedores empiezan a leer una política de monitorización mantenida durante años como una señal de poca confianza, y los remitentes que están en quarantine o en reject obtienen mejor colocación en bandeja que los que siguen en none, aunque los dos cumplan el requisito.

Dicho de otra forma: p=none es la matrícula, no el título.

Lo que no cambia es el orden. Subir sin haber leído los informes es la manera más rápida de bloquearte tu propio correo, porque lo primero que dejará de entregarse será lo tuyo. Primero none para ver quién envía en tu nombre, después arreglar lo que falle, y entonces subir. Ni saltarse el paso, ni quedarse ahí para siempre.

Quién exige DMARC, y desde cuándo

Esto ya no es una recomendación de buenas prácticas. Los tres proveedores que reparten la mayor parte del correo del mundo lo piden por escrito:

Dos detalles que conviene saber. El primero: quien cruza el umbral de Google una sola vez queda clasificado como remitente masivo de forma permanente. No se vuelve atrás por bajar el volumen. El segundo: Yahoo nunca dijo a partir de cuántos correos aplica, así que enviar poco no garantiza estar fuera.

Y hay una consecuencia que casi nadie menciona y que cambia cómo se mira todo esto. Si alguien suplanta tu dominio y tú no lo has protegido, el problema es tuyo. Quien recibe el correo falso ve tu nombre, y quien podía haberlo impedido publicando una política eras tú. Autenticar no es solo evitar el spam: es hacerse responsable de lo que sale con tu nombre.

La trampa de los subdominios

Si no pones la etiqueta sp=, los subdominios heredan la política del dominio principal. Es decir: el día que subes a p=reject, lo subes también para facturas.tudominio.com, envios.tudominio.com y cualquier otro subdominio que exista, aunque nunca hayas comprobado si están autenticados.

Por eso sp= se declara de forma explícita en lugar de dejar que herede. Si tienes subdominios que envían y todavía no los has revisado, pueden quedarse en sp=none mientras el dominio principal ya está protegido.

Un dominio solo puede tener un registro DMARC

Uno. Si en la consulta aparecen varios registros que empiecen por v=DMARC1, el servidor no puede decidir cuál vale y deja de aplicar DMARC a ese mensaje. No es que aplique el más suave ni el más estricto: es que no aplica ninguno.

Es la misma avería que en el registro SPF, y por la misma razón: se añade el registro nuevo sin quitar el viejo. Con la diferencia de que aquí no salta ningún error visible. El dominio simplemente deja de estar protegido, en silencio.

Los informes

Son la mitad del valor de DMARC y casi nadie los usa. Hay dos tipos:

• Agregados (rua): un resumen periódico —por defecto, diario— de todo el correo enviado con tu dominio, quién lo envió, desde qué IP y si pasó la autenticación. Llegan en XML comprimido, así que en crudo no se leen: hacen falta herramientas que los interpreten.
• De fallo (ruf): detalle mensaje a mensaje de los que fallan. Mucho más informativos, pero contienen datos del correo real, así que muchos proveedores directamente no los envían.

Los agregados son los que responden a la pregunta que nadie sabe contestar cuando empieza: ¿quién está enviando correo con mi dominio ahora mismo?

Leído en una herramienta, un informe se resume en tres cifras. Algo así:

2.090   correos procesados
  99%   con SPF o DKIM alineado
   1%   sin alinear

Ese 1% es lo interesante. Puede ser un intento de suplantación, o —mucho más a menudo— una herramienta tuya que envía en tu nombre y que nadie autenticó. Hasta que no sabes cuál de las dos cosas es, no puedes subir la política sin riesgo.

Preguntas frecuentes

¿Necesito SPF y DKIM antes de poner DMARC?

Sí. DMARC no autentica nada por su cuenta: lee los resultados de SPF y DKIM y comprueba si están alineados. Sin al menos uno de los dos bien configurado y alineado, DMARC solo puede fallar. Lo que sí puedes hacer desde el primer día es publicar p=none con rua para empezar a recibir informes mientras arreglas lo demás.

¿Qué significa «does not pass DMARC verification» en un rebote?

Que el correo llegó, se comprobó y no superó la alineación: ni SPF ni DKIM validaron un dominio que coincidiera con el del «De». Y como tu política le dijo al destinatario qué hacer en ese caso, lo ha hecho. Si tenías p=reject, ese mensaje no se ha entregado.

¿DMARC es obligatorio si envío poco correo?

Google y Yahoo lo exigen desde febrero de 2024 y Microsoft desde mayo de 2025 a quien envía unos 5.000 correos al día o más. Con dos matices: quien cruza ese umbral una sola vez queda clasificado como remitente masivo de forma permanente, y Yahoo nunca declaró umbral de volumen. Enviar poco no garantiza quedar fuera, y publicar p=none no cuesta nada.

¿Puedo tener dos registros DMARC?

No. Si hay más de uno, el servidor deja de aplicar DMARC a ese dominio por completo. Cuando hay que cambiar la política o el destino de los informes, se edita el registro que ya existe; no se añade otro.

¿Tengo que llegar a p=reject?

Para cumplir el requisito de Google, Yahoo y Microsoft basta con p=none. Para estar protegido, no: p=none no impide que nadie use tu dominio, solo te lo cuenta. La suplantación se detiene con quarantine o con reject. Y en 2026 quedarse indefinidamente en monitorización empieza a leerse como una señal de poca confianza. El orden sí importa: primero los informes, después arreglar lo que falle, y entonces subir.

¿Cuánto tiempo hay que estar en p=none?

El que haga falta para reconocer en los informes todos los sistemas que envían legítimamente en tu nombre y dejarlos autenticados. En un negocio con pocas herramientas pueden ser semanas; con muchas plataformas y proveedores, bastante más. El plazo lo marcan los informes, no el calendario.

¿DMARC evita que me suplanten?

Evita que suplanten tu dominio exacto, que no es poco. No evita que registren un dominio parecido al tuyo, ni que pongan tu nombre en el campo visible del remitente usando otro dominio. Para eso hacen falta otras medidas.