¿Un registro DMARC bloquea de verdad la suplantación, o solo las campañas que el equipo de marketing sigue enviando desde un router mal alineado? DMARC (Domain-based Message Authentication, Reporting and Conformance) es un registro DNS que indica a los servidores receptores, Gmail, Outlook, Yahoo, qué política aplicar a un correo que falla el alineamiento de SPF o DKIM. Publicado solo, sin los dos protocolos que supervisa, no bloquea nada. A finales de 2025, el 83,9% de los dominios analizados por Red Sift no tenía ningún registro DMARC publicado, sobre una muestra de 73,3 millones de dominios. A continuación se detalla la sintaxis exacta del registro, las tres políticas disponibles y la lectura de los informes rua.
¿Qué es DMARC?
Un dominio que publica SPF y DKIM sin _dmarc deja que cada servidor receptor decida por su cuenta qué hacer ante un fallo de autenticación. Algunos rechazan el mensaje, otros lo entregan igualmente marcándolo como sospechoso, otros no cambian nada. DMARC cierra esa ambigüedad: el propietario del dominio fija él mismo la política, en un registro TXT publicado en el host _dmarc.tudominio.com. El estándar está documentado en la RFC 7489 desde 2015, pero su adopción sigue siendo desigual. Las grandes empresas cotizadas superan el 85% de cobertura en los análisis por país, mientras que la media mundial no llega al 15% (Red Sift, 2025). La diferencia se debe sobre todo a la complejidad percibida de la sintaxis, raramente a su dificultad real.
Por qué DMARC es importante
Un dominio sin política DMARC deja que cualquiera envíe un correo firmado con su nombre, sin que ningún mecanismo avise al destinatario. Es el vector principal del phishing por suplantación de marca, el que hace que un contable haga clic en una factura falsa que supuestamente viene de su propio proveedor. El panel de un SaaS de email marketing puede mostrar una buena entregabilidad sin decir nada sobre lo que un tercero envía fuera de esa plataforma: la entregabilidad medida internamente y la superficie de suplantación externa siguen siendo dos medidas distintas. Un dominio atacado por una campaña de suplantación también ve degradarse su reputación de envío ante los filtros de Gmail y Outlook, una señal que después aparece en las métricas de Google Postmaster Tools, incluso cuando ningún correo fraudulento sale realmente de la infraestructura de la empresa. Los filtros se fijan en el nombre de dominio visible, no en la IP de envío.
Cómo DMARC se apoya en SPF y DKIM
DMARC no sustituye ni a SPF ni a DKIM. Los supervisa, apoyándose en sus resultados. SPF verifica que el servidor emisor está autorizado a enviar en nombre del dominio indicado en el sobre MAIL FROM. DKIM firma el contenido del mensaje con una clave criptográfica, lo que permite detectar cualquier modificación en tránsito. Un correo puede fallar uno y pasar el otro: DMARC exige que al menos uno de los dos tenga éxito, y sobre todo que el dominio verificado por ese protocolo coincida con el dominio mostrado en la cabecera From, el que ve el destinatario. Esa coincidencia tiene un nombre, el alineamiento.
El alineamiento puede ser estricto o relajado, según las etiquetas aspf y adkim del registro DMARC. En modo relajado, el valor por defecto, un subdominio como newsletter.empresa.com se alinea con empresa.com. En modo estricto, solo se acepta una coincidencia exacta. La mayoría de las plataformas de envío externas publican sus propios registros SPF y firman con sus propias claves DKIM, ya sea un router transaccional o un CRM externo. Sin una configuración explícita del subdominio de envío en el DNS, esos correos fallan el alineamiento aunque sean perfectamente legítimos. Es la causa más frecuente de una tasa de rechazo DMARC que sube justo después de añadir una nueva herramienta de marketing, sin que ninguna campaña de phishing tenga nada que ver.
Crear un registro DMARC: sintaxis y ejemplo
Configurar un registro DMARC empieza siempre por elegir el host DNS correcto. El registro se publica como un TXT normal, en el host _dmarc de la zona DNS del dominio, nunca en el dominio raíz. Aquí tienes un ejemplo comentado, pensado para un despliegue progresivo:
v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@empresa.com; ruf=mailto:ruf@empresa.com; aspf=r; adkim=r; sp=none
Cada etiqueta tiene un papel concreto. v fija la versión del protocolo, siempre DMARC1. p define la política aplicada al dominio. pct fija el porcentaje de mensajes no conformes afectados por esa política. rua indica la dirección que recibe los informes agregados diarios. ruf indica la dirección de los informes forenses, que los grandes proveedores de correo rara vez respetan. sp fija la política aplicada a los subdominios que no tienen registro propio.
Para crear y verificar el registro:
- Identificar todos los emisores legítimos del dominio (ESP, CRM, facturación, soporte técnico) y confirmar que cada uno publica SPF o firma con DKIM.
- Crear una dirección dedicada a los informes rua.
- Publicar el registro TXT en _dmarc con p=none durante al menos dos a cuatro semanas, solo observando.
- Leer los primeros informes agregados para detectar las fuentes que fallan el alineamiento y corregirlas una a una.
- Subir la política por etapas, pct=25, luego pct=50, luego pct=100, antes de pasar a quarantine y después a reject.
Un registro mal formado, una etiqueta duplicada o una dirección rua no válida, por lo general no impide su publicación en el DNS. Lo que hace es bloquear silenciosamente la recepción de informes, lo que vuelve imposible el seguimiento sin que ninguna alerta avise al administrador.
Las tres políticas DMARC y el despliegue progresivo
Para la etiqueta p son posibles tres valores. none no cambia nada en la entrega: el correo sigue su curso normal, solo el informe rua registra el fallo. quarantine envía el correo no conforme a la carpeta de spam del destinatario o equivalente. reject bloquea el envío antes de que llegue a la bandeja de entrada, con un rechazo SMTP devuelto al remitente.
Pasar directamente a p=reject sin una fase de observación también bloquea correos legítimos no alineados, una lista de distribución que reescribe la cabecera From, un router CRM externo mal configurado, un servicio de facturación subcontratado. El despliegue recomendado empieza con none en modo observación, sube de forma gradual hacia quarantine y termina con el rechazo completo, aumentando pct por etapas. Una política reject al 100% también abre la puerta al despliegue de BIMI, el logo de marca que se muestra en la bandeja de Gmail y Yahoo, que exige un DMARC estricto como requisito técnico.
Leer los informes DMARC: rua y ruf
Los informes rua llegan en XML comprimido. Cada proveedor de correo que ha recibido mensajes del dominio suele enviar uno al día, con la lista de IPs emisoras, el volumen procesado, el resultado del alineamiento SPF y DKIM y la política aplicada. La lectura manual sigue siendo viable para un dominio con dos o tres emisores. A partir de una decena de subdominios activos y varias plataformas de envío, el volumen de líneas XML hace poco realista una lectura línea por línea sin una herramienta de parsing dedicada.
Los informes ruf, en cambio, detallan un correo concreto que ha fallado, con las cabeceras completas incluidas. Gmail y Yahoo no los envían, por razones de privacidad de los datos personales contenidos en esas cabeceras. Solo una minoría de proveedores de correo más modestos aún los respeta. La guía completa para leer un informe DMARC agregado sin equivocarse detalla el parsing del XML campo por campo.
Lo que DMARC no cubre
DMARC protege exactamente el dominio publicado en el registro, nada más. Un correo enviado desde empresa-soporte.com en lugar de empresa.com, un dominio visualmente parecido registrado por un atacante, pasa por completo por delante de todo el dispositivo: ningún SPF, DKIM o DMARC cubre un dominio que la empresa no posee. Este typosquatting sigue siendo el punto ciego más frecuente de los despliegues DMARC, incluidos los configurados ya en p=reject. La lista completa de límites, desde el contenido del mensaje hasta la protección de dominios no registrados, merece conocerse antes de anunciar internamente que un dominio ya está protegido.
Quién debe publicar un registro DMARC en 2026
Desde el 1 de febrero de 2024, Google exige una autenticación SPF y DKIM alineada, además de un registro DMARC al menos en p=none, para todo remitente que envíe 5.000 mensajes o más en 24 horas a cuentas personales de Gmail. Microsoft siguió a partir del 5 de mayo de 2025 en Outlook.com, Hotmail y Live.com: por encima del mismo umbral, los correos no autenticados se rechazan a nivel SMTP con el Enhanced Status Code 550 5.7.15, en lugar de redirigirse a la carpeta de spam. La complaint rate reportada a través de los feedback loops de los proveedores de correo debe mantenerse por debajo del 0,3%, con un umbral recomendado por debajo del 0,1% para evitar un filtrado más estricto.
Google precisa que el umbral de 5.000 mensajes se evalúa en una ventana móvil de 24 horas: un remitente que lo supera una sola vez queda sujeto a las mismas exigencias que si lo alcanzara cada día.
Por debajo de ese umbral, nada obliga legalmente a publicar DMARC. Pero un dominio B2B activo, incluso con poco volumen, sigue siendo un blanco preferido para la suplantación: la factura fraudulenta dirigida a un proveedor no se fija en el volumen de envío de la víctima. Otra herramienta más en la pila, dirán algunos al descubrir que también hay que vigilar la tasa de hard bounce y la reputación de envío asociadas al dominio. DMARC no sustituye nada de lo que ya existe. Sobre todo consume datos que ya están en Google Postmaster Tools. Limpiar la lista de distribución, una práctica elemental de list hygiene, antes de endurecer la política hacia DMARC reject, evita confundir una dirección que rebota con un fallo de alineamiento mal diagnosticado, una confusión que retrasa el despliegue varias semanas en la mayoría de los casos observados.
¿Cuánto tiempo ha pasado desde la última vez que se leyó el informe rua de este dominio?
