DMARC: la instrucción que convierte SPF y DKIM en protección

DMARC dice al destinatario qué hacer cuando un mensaje no se autentica, y le envía a usted informes de lo que ocurre. Cómo es el registro y qué hacer con cada hallazgo.

SPF y DKIM producen un resultado: este mensaje se autentica o no. Lo que ninguno de los dos dice es qué hacer después. Esa es la función de DMARC: un registro en el DNS que da al destinatario una instrucción —no hagas nada, apártalo, recházalo— y le pide que informe a usted de lo que ha visto.

DMARC añade además la pieza que faltaba: la alineación. SPF verifica la dirección del sobre y DKIM verifica el dominio firmante, pero el destinatario lee otra cosa en pantalla, la línea «De». DMARC exige que el dominio verificado y el dominio visible sean el mismo. Sin eso, cualquiera puede pasar SPF con su propio dominio y escribir su nombre en el remitente visible.

Los informes son la parte que casi nadie aprovecha y la que más vale. Durante semanas le llegan resúmenes diarios de los grandes proveedores con quién envía correo con su dominio, desde qué direcciones y con qué resultado. Es la única manera de descubrir la aplicación de facturación que lleva tres años enviando sin autenticarse.

Cómo es el registro

DMARC vive siempre en el mismo nombre: _dmarc delante de su dominio.

_dmarc.ejemplo.es.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.es; adkim=r; aspf=r"

Con alineación relajada, una firma de envios.ejemplo.es vale para un remitente ejemplo.es. Con estricta, no. Empiece por relajada: es lo que casi todos los servicios de envío esperan.

El camino de none a reject

DMARC no se activa de golpe. Se despliega en tres fases, y saltarse la primera es la manera más rápida de que su propia facturación deje de llegar.

Entre la fase 1 y la 2 hay una tarea, y es la que ocupa el tiempo: leer los informes, localizar cada sistema que envía con su dominio y autenticarlo. Los informes llegan como XML dentro de un archivo comprimido, ilegibles a simple vista; hay servicios gratuitos que los convierten en tablas, y para un dominio pequeño abrirlos en una hoja de cálculo también funciona.

Cómo se configura

DMARC es un registro TXT en el nombre _dmarc. Se publica en el mismo sitio que el SPF: en el panel donde estén los servidores de nombres del dominio.

Microsoft 365 y Google Workspace no publican el registro por usted: indican qué escribir, pero el registro se crea en el DNS del dominio.

Paso a paso en Dinahosting

1. Panel → Dominios → su dominio → Gestión DNS.
2. Añada un registro TXT con el nombre _dmarc. Algunos paneles piden el nombre completo, _dmarc.ejemplo.es: el propio formulario lo indica.
3. Contenido de la primera fase: v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.es.
4. Use una dirección real y que alguien mire. Un buzón compartido va bien; un alias que nadie abre convierte el ejercicio en decorativo.
5. Guarde y espere unos días. Los informes llegan una vez al día por proveedor.
6. Cuando ningún sistema propio aparezca ya como fallido, cambie p=none por p=quarantine, y semanas después por p=reject.

Los hallazgos, uno por uno

Sin registro DMARC

No hay ningún registro TXT en _dmarc.su-dominio.

Esto importa porque DMARC es el único de los tres mecanismos que produce una consecuencia. Sin él, un mensaje falsificado con su dominio llega igual: el destinatario puede ver que algo no cuadra, pero nadie le ha dicho qué hacer con esa información. Y usted no recibe ningún informe, así que la suplantación ocurre sin que llegue a enterarse. Desde que Google y Yahoo endurecieron sus requisitos para remitentes masivos, además, la ausencia de DMARC afecta directamente a la entrega de boletines.

Qué hacer. Publique hoy mismo la versión de observación: v=DMARC1; p=none; rua=mailto:dmarc@su-dominio. No cambia nada en la entrega y pone en marcha los informes, que es lo que necesita para poder endurecer más adelante sin romper nada.

Varios registros DMARC

Hay más de un registro TXT en _dmarc que empieza por v=DMARC1. El estándar permite uno.

Esto importa porque los receptores no eligen: descartan DMARC por completo. El dominio queda exactamente como si no tuviera registro, con la diferencia de que en el panel se ven dos y parece que hay protección de sobra.

Qué hacer. Decida qué instrucción quiere, escriba un único registro con ella y borre el resto. Si los dos registros tienen direcciones de informes distintas, pueden convivir en el mismo registro separadas por comas.

DMARC sin instrucción válida

El registro existe, pero falta el campo p o contiene un valor que no es none, quarantine ni reject.

Esto importa porque p es el único campo obligatorio junto con la versión. Sin una instrucción reconocible, el registro completo no se aplica: da igual lo bien escrito que esté todo lo demás.

Qué hacer. Revise la escritura. Los fallos habituales son un valor en mayúsculas, una errata como p=quarentine, o p colocado detrás de otros campos cuando el estándar lo quiere inmediatamente después de la versión. Corrija y vuelva a comprobar.

DMARC solo en observación (p=none)

El registro dice p=none: los receptores informan de los mensajes que no se autentican, pero los entregan igual.

Esto importa porque p=none es un buen punto de partida y un mal punto final. Mientras siga así, una falsificación de su dominio llega al buzón del destinatario igual que su correo auténtico. La protección que usted cree tener aún no existe; lo que tiene es un sistema de observación.

Y no es un estado inocuo: a un dominio en p=none durante años se le acumulan vías de envío sin autenticar, precisamente porque nada falla nunca y nadie las descubre. Cuanto más tiempo pasa, más cuesta el paso siguiente.

Qué hacer. Abra los informes de las últimas semanas y haga la lista de todo lo que envía con su dominio. Autentique cada sistema: include en el SPF o DKIM propio, mejor las dos cosas. Cuando en los informes solo aparezcan como fallidos remitentes que no son suyos, pase a p=quarantine. Dé unas semanas más y pase a p=reject. Si no está seguro, p=quarantine ya es una mejora real: lo dudoso va a spam, no se pierde.

DMARC solo se aplica en parte

El registro lleva pct= con un valor inferior a 100, así que la instrucción se aplica solo a esa proporción de los mensajes.

Esto importa porque el resto pasa sin control. Con p=reject; pct=20, cuatro de cada cinco mensajes falsificados se entregan con normalidad. pct está pensado como rampa durante el despliegue, y casi siempre es un resto olvidado de esa rampa.

Qué hacer. Si el despliegue ya terminó, retire pct por completo: sin el campo, la instrucción se aplica al cien por cien. Si sigue en pruebas, suba el valor por tramos y quítelo al llegar a 100. Tenga en cuenta que BIMI exige aplicación total: con pct por debajo de 100, el logotipo no se muestra.

DMARC sin dirección de informes

El registro no tiene campo rua, así que nadie le envía informes.

Esto importa porque se queda sin lo más valioso de DMARC. Sin informes no ve quién envía con su dominio, no sabe qué sistemas propios todavía fallan y no tiene ninguna base para endurecer la instrucción. En la práctica significa que el registro se quedará en p=none para siempre, porque subir a ciegas da miedo con razón.

Qué hacer. Añada rua=mailto:dmarc@su-dominio al registro. Use una dirección que alguien abra. Si prefiere recibirlos ya procesados, hay servicios que los leen por usted; en ese caso, atención al hallazgo siguiente.

Subdominios exentos (sp=none)

El registro lleva sp=none: la instrucción principal no se aplica a los subdominios.

Esto importa porque las falsificaciones se desplazan justo ahí. Un remitente como facturacion.su-dominio.es o correo.su-dominio.es resulta perfectamente creíble para el destinatario y, con sp=none, no encuentra ninguna resistencia aunque el dominio principal esté en p=reject. El atacante no necesita que el subdominio exista.

Qué hacer. Si ningún subdominio envía correo, retire sp por completo: sin ese campo, p rige también para ellos. Si algún subdominio envía y todavía no está autenticado, deje sp=quarantine mientras lo arregla, pero póngale fecha. sp=none de forma indefinida deja abierta la puerta más cómoda.

Dirección de informes sin autorización

El campo rua apunta a una dirección de otro dominio, y ese dominio no ha publicado la autorización que el estándar exige.

Esto importa porque, sin esa autorización, los proveedores que emiten los informes los descartan sin avisar. El registro parece correcto, usted cree estar recibiendo datos y no llega nada. Ocurre casi siempre al contratar un servicio externo de análisis de DMARC y saltarse un paso de la puesta en marcha.

Qué hacer. El dominio que recibe los informes tiene que publicar un registro TXT con el nombre su-dominio._report._dmarc.dominio-que-recibe y el contenido v=DMARC1;. Si el receptor es un servicio comercial, normalmente lo hace él en cuanto usted añade su dominio en su panel: compruebe que ese paso está hecho.

DMARC heredado del dominio principal

El nombre comprobado es un subdominio que no tiene registro propio. Rige el del dominio principal, y el informe indica de dónde viene.

Esto no es un defecto. Así está pensado el estándar y en la mayoría de los casos es justo lo que se quiere: se administra una sola instrucción y vale para todo.

Qué hacer. Normalmente, nada. Un registro propio solo compensa si ese subdominio tiene sus propias vías de envío y necesita otra instrucción u otra dirección de informes; por ejemplo, un subdominio de boletines que todavía está en observación mientras el dominio principal ya está en p=reject.

Preguntas frecuentes

¿Me van a llegar cientos de correos de informes?

No. Los informes agregados llegan una vez al día y por proveedor: para un dominio pequeño son unos pocos mensajes diarios de Google, Microsoft, Yahoo y algún otro. Lo que sí conviene es dirigirlos a un buzón propio, porque son archivos XML comprimidos y ensucian una bandeja de entrada normal.

¿Puedo pasar directamente a p=reject?

Se puede, y a veces sale bien: si el dominio solo envía desde un proveedor de buzones bien configurado, el riesgo es bajo. En cuanto hay una tienda, un CRM o un formulario de por medio, el riesgo deja de ser bajo y no hay síntoma que avise. Dos semanas en p=none con los informes abiertos cuestan poco y evitan justamente eso.

Tengo un dominio que no envía correo. ¿Necesita DMARC?

Sí, y además es el caso más sencillo: v=DMARC1; p=reject; junto con un SPF v=spf1 -all. Un dominio que solo sostiene una web o que está aparcado es un remitente cómodo de falsificar precisamente porque nadie lo vigila. Lo tratamos en recepción de correo.

¿Qué relación tiene DMARC con el logotipo en la bandeja de entrada?

Directa. BIMI exige p=quarantine o p=reject aplicado al cien por cien. Mientras DMARC esté en p=none o con pct por debajo de 100, el logotipo no se muestra por muy bien hecho que esté el resto.