DMARC: qué es y cómo activarlo sin perder correo 2026

Alguien te ha dicho que tienes que «poner DMARC»: tu gestor de sistemas, un cliente grande que te lo exige por contrato, o directamente Google, porque tus envíos han empezado a rebotar. Y lo que te frena es razonable: es un registro en el DNS y te da pánico que a partir de mañana no lleguen los pedidos, las facturas ni los avisos del formulario de contacto.

La buena noticia es que DMARC no se activa de golpe. Se activa por fases, y la primera fase no bloquea absolutamente nada: solo observa y te manda un informe de quién está enviando correo con tu dominio. Aquí tienes el plan completo, desde el registro que publicas hoy hasta la protección real, sin perder un solo correo por el camino.

Qué añade DMARC a SPF y DKIM

SPF declara qué servidores tienen permiso para enviar correo en nombre de tu dominio. DKIM firma criptográficamente cada mensaje para demostrar que salió de donde dice y que nadie lo ha manipulado. Los dos son útiles y los dos tienen el mismo agujero: ninguno le dice al servidor que recibe qué debe hacer cuando la comprobación falla. Cada proveedor decide por su cuenta, y normalmente decide entregar el mensaje igualmente.

DMARC es esa instrucción que falta. Un único registro TXT en el DNS que dice tres cosas: qué hacer con los mensajes que no superan las comprobaciones, a qué dirección quieres que te manden los informes, y —la parte que casi nadie entiende y que lo cambia todo— que SPF o DKIM tienen que estar alineados con el dominio que ve el destinatario.

Si todavía no tienes claro qué hace cada pieza por separado, merece la pena repasar antes cómo funcionan SPF y DKIM en la práctica, porque DMARC se apoya en ellos: si esos dos están mal, DMARC no arregla nada, solo te lo cuenta.

Cómo ver si ya tienes DMARC publicado

Antes de tocar nada, mira qué hay. Desde una ventana de comandos de Windows:

nslookup -type=TXT _dmarc.tudominio.es 8.8.8.8

Desde macOS o Linux:

dig +short TXT _dmarc.tudominio.es

Si no devuelve nada, no tienes DMARC. Si devuelve algo que empieza por v=DMARC1;, ya tienes uno publicado; fíjate en el valor de p= porque ahí está todo. Ojo con un detalle que despista mucho: el registro no va en tudominio.es, va en el subdominio _dmarc.tudominio.es, con guion bajo delante.

Alineación: el detalle que hace que todo cuadre o no

Esta es la parte que hace que empresas con SPF y DKIM correctos suspendan igualmente DMARC, y merece dos minutos.

En un correo hay dos remitentes distintos. El que tú ves en tu programa de correo es la cabecera From:. El que se usa realmente para comprobar SPF es el sobre técnico, el Return-Path o MAIL FROM, que muchas veces pertenece a la plataforma que envía y no a ti. DKIM tiene su propio dominio, la etiqueta d= de la firma.

DMARC exige que al menos uno de esos dos coincida con el dominio del From:. Eso es la alineación. El caso típico: contratas una herramienta de newsletter, ella envía con su propio Return-Path, SPF pasa perfectamente… pero pasa para su dominio, no para el tuyo. Resultado: DMARC falla. Por eso todas esas plataformas te piden que añadas unos registros CNAME en tu DNS: son precisamente para poder firmar con DKIM usando tu dominio y quedar alineadas.

Hay dos modos de alineación: relajado (adkim=r, aspf=r, el valor por defecto, admite subdominios) y estricto (s, exige coincidencia exacta). Empieza siempre en relajado. El estricto solo tiene sentido cuando ya lo tienes todo controlado y quieres cerrar el último resquicio.

p=none, quarantine y reject explicados por sus consecuencias

La política es una sola letra en el registro y define qué le pides al servidor del destinatario:

p=none: no hace nada. El correo que falla se entrega igual. Su único efecto es que empiezas a recibir informes. Es la fase de observación y es donde debes empezar sí o sí.
p=quarantine: el que falla va a la carpeta de correo no deseado. El daño es reversible: el destinatario puede rescatarlo.
p=reject: el que falla se rechaza y desaparece. El destinatario no lo ve ni en spam. Es la protección real contra la suplantación de tu marca, y también la que te deja sin correo si te has saltado los pasos previos.

Un registro de arranque razonable, en fase de observación, se ve así:

Nombre:  _dmarc
Tipo:    TXT
Valor:   v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; fo=1

Publicado eso, esta noche ya no ha cambiado nada para tus destinatarios. Pero mañana empiezan a llegarte los informes.

Los informes: qué dicen y cómo leerlos sin volverse loco

La dirección que pones en rua= recibe informes agregados: un fichero XML comprimido, normalmente uno al día por cada proveedor grande. Dentro no hay contenido de tus correos ni direcciones de tus clientes; hay IPs que han enviado usando tu dominio, cuántos mensajes, y si superaron SPF y DKIM alineados.

Consejos prácticos para no ahogarte:

Crea un buzón dedicado ([email protected]) y no lo mezcles con tu correo de trabajo.
Abrir los XML a mano es viable la primera semana y desesperante a la tercera. Hay servicios que los convierten en una tabla legible, muchos con plan gratuito suficiente para un dominio pequeño.
Lo único que buscas al principio es una lista: qué fuentes envían en tu nombre y cuáles fallan. Cada IP que falla es o una plataforma tuya mal configurada, o alguien suplantándote.
La etiqueta ruf= pide informes forenses con copia parcial de los mensajes fallidos. Casi ningún proveedor grande los manda, y además pueden contener datos personales de terceros, así que no la actives salvo que sepas exactamente qué vas a hacer con ellos.

Plan de seis semanas de none a reject

Este ritmo funciona bien en una empresa pequeña y es conservador a propósito. Si envías poco volumen puedes comprimirlo; si tienes varios dominios y muchas herramientas, alárgalo sin complejos.

Semana 1 — Inventario. Antes del DNS, la lista. Escribe todo lo que envía correo con tu dominio: el buzón corporativo, el servidor web (formularios, avisos de pedido de WooCommerce, recuperación de contraseña), la newsletter, el CRM, el programa de facturación, la plataforma de reservas o citas, la herramienta de firma digital, la gestoría si manda nóminas en tu nombre. Casi siempre aparecen dos o tres que nadie recordaba.
Semana 2 — Publica p=none. El registro de arriba. Cero riesgo. Deja que corran siete días completos.
Semana 3 — Arregla lo que falla. Con los informes en la mano, ve plataforma por plataforma activando DKIM con tu dominio y añadiendo lo que corresponda a tu SPF. Ten cuidado con el límite de diez consultas DNS del SPF: si añades includes sin control, el registro deja de evaluarse y rompes lo que ya funcionaba.
Semana 4 — Sube a p=quarantine; pct=25. Ese pct aplica la política solo a una parte de los mensajes fallidos. Es tu red de seguridad.
Semana 5 — p=quarantine; pct=100. Si nadie ha llamado quejándose y los informes están limpios, sigues.
Semana 6 — p=reject. Y a partir de ahí, revisa los informes una vez al mes, no una vez al año.

Qué se te puede romper: newsletters, CRM, formularios y facturación

Sé honesto con los puntos donde esto duele, porque son siempre los mismos:

El formulario de tu web. El clásico absoluto: el formulario manda el mensaje poniendo como From: la dirección del visitante. Eso es literalmente suplantación y con p=reject deja de llegarte. Solución correcta: que el formulario envíe siempre desde una dirección tuya y ponga la del visitante en Reply-To. En WordPress, además, conviene que el correo salga por SMTP autenticado y no por la función mail() del servidor.
Los reenvíos automáticos. Si un buzón reenvía a otro, SPF se rompe por el camino. DKIM suele sobrevivir si el intermediario no toca el mensaje, y por eso tener DKIM bien puesto es más importante que tener SPF perfecto.
Listas de correo y foros que modifican el asunto o añaden pie de página: rompen la firma DKIM.
Programas de facturación y ERP que envían desde su propio servidor con tu dirección en el remitente. Casi todos permiten configurar SMTP propio; si el tuyo no, es un motivo legítimo para cambiarlo.
El «enviar como» desde una cuenta personal usando tu dirección de empresa.

Ninguno de estos casos es raro ni es culpa tuya. Son la razón exacta por la que existe la fase p=none: para que aparezcan en un informe y no en una llamada de un cliente enfadado.

Cómo saber si ya estás protegido de verdad

Tienes DMARC funcionando cuando se cumplen las tres cosas a la vez: el registro está en p=reject, los informes agregados muestran que todas tus fuentes legítimas pasan alineadas, y no queda ninguna IP desconocida enviando con volumen. Con dos de las tres, todavía no.

¿Necesitas ayuda profesional para esto? Con un dominio, un proveedor de correo y dos o tres herramientas, no. El proceso de arriba lo hace perfectamente una persona con acceso al panel de DNS y algo de paciencia. Empieza a compensar pagar a alguien cuando tienes varios dominios y marcas, un histórico de plataformas heredadas que nadie sabe quién contrató, o cuando ya has intentado subir a reject y se te ha caído algo. Y si el problema que te trajo aquí es que tus correos no llegan aunque nadie te suplante, el diagnóstico es otro y lo tienes en por qué tus correos acaban en la carpeta de no deseados.

Un apunte final que conviene tener claro: DMARC protege tu dominio de que lo usen para engañar a otros. No te protege a ti de recibir fraude desde dominios ajenos —para eso lo que hace falta es que tu equipo sepa reconocer un correo de phishing dirigido a la empresa—. Y el correo es solo una pata de la casa: el resto (hosting, HTTPS, accesos, DNS) lo tienes ordenado en la guía de configuración segura de una web.

Si quieres empezar por lo más rápido, antes de tocar el DNS: mira en qué política de DMARC estás ahora mismo. La comprobación es gratuita, tarda unos segundos y te dice si tienes SPF, DKIM y DMARC publicados y en qué fase estás, que es justo el punto de partida de este plan.

Seguir leyendo en esta sección

Ver todo en Correo seguro → · Mapa completo del sitio