Cómo saber si un dominio puede ser suplantado

Cómo leer el resultado

Si las tres respuestas son favorables (p=reject o p=quarantine, con sp/np cubiertos): el dominio exacto no es directamente suplantable. Es una buena base, pero no una garantía total: hay que comprobar con regularidad que la configuración no se ha desviado (nueva fuente sin alinear, cambio de proveedor DNS) y vigilar los vectores secundarios mencionados arriba.

Si el registro existe pero en p=none: el dominio está en fase de observación, lo cual es una etapa legítima del despliegue, pero sigue siendo técnicamente suplantable mientras la política no se haya endurecido. No es una urgencia cuando el inventario de fuentes se construye metódicamente (alcanzar p=reject sin romper el correo legítimo describe el camino), pero tampoco es una protección.

Si no existe ningún registro: el dominio es suplantable sin ninguna barrera, exactamente como si nunca hubiera existido DMARC. Es el caso más frecuente en las organizaciones que simplemente nunca han oído hablar del tema, y la buena noticia es que el primer paso (publicar un registro en p=none) es gratuito e inmediato.

Por qué esta prueba debe repetirse, no ser puntual

Un dominio correctamente protegido hoy puede volver a ser vulnerable mañana, por razones que no tienen nada que ver con un ataque: un cambio de proveedor DNS que borra accidentalmente el registro, una migración de plataforma de email que modifica la configuración SPF sin tocar DMARC, o un simple error de manipulación durante una intervención técnica. Por eso esta prueba de suplantabilidad merece repetirse periódicamente, no efectuarse una sola vez durante la puesta en conformidad inicial: idealmente tras cada cambio de infraestructura de email, y a intervalos regulares incluso sin cambios conocidos.

En la práctica, la forma más sencilla de anclar este hábito es asignar a la prueba un responsable explícito y un hueco en el calendario: un recordatorio trimestral confiado a la persona que administra el DNS, más una línea en la checklist de cada ticket de cambio relacionado con el email (nueva plataforma de marketing, migración de CRM, cambio de proveedor DNS). Cada comprobación se cuenta en minutos: no hay, pues, ningún compromiso real que valorar. Las organizaciones que integran este control en su gestión de cambios detectan una regresión en unos días; las que lo tratan como un punto de auditoría puntual descubren la desviación meses más tarde, a través de un informe de incidente en lugar de una revisión planificada, la forma más costosa posible de aprenderlo.

Un ejemplo de resultado, línea a línea

Para hacer tangible esta prueba, veamos cómo interpretar un registro DMARC real, línea a línea, como el que aparece al consultar _dmarc.ejemplo-empresa.com:

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@ejemplo-empresa.com

Descompongamos lo que revela cada etiqueta. v=DMARC1 confirma que existe un registro DMARC válido: primera pregunta respondida positivamente. p=quarantine indica una política de aplicación parcial sobre el dominio raíz: segunda pregunta, respuesta a medias, no es none (así que no está totalmente abierto), pero tampoco es reject (así que no es la protección máxima). sp=none es el detalle más revelador aquí: los subdominios no tienen ninguna política de aplicación, tercera pregunta, respuesta claramente desfavorable. Un atacante que fracase al suplantar el dominio raíz (gracias a quarantine) puede recurrir sin dificultad a un subdominio, donde sp=none deja el campo libre.

Este tipo de configuración intermedia (ni totalmente abierta, ni totalmente cerrada) es en realidad muy común, e ilustra bien por qué las tres preguntas de la prueba deben plantearse juntas: una respuesta favorable a una no dice nada sobre las otras dos.

Por qué esta prueba precede a cualquier otra discusión de seguridad de email

Una trampa frecuente en las organizaciones que empiezan a interesarse por la seguridad del email: saltar directamente a discusiones sofisticadas (¿hace falta BIMI?, qué solución de vigilancia de dominios parecidos elegir, cómo formar a los equipos contra el fraude del CEO) sin haber verificado esta prueba básica de tres preguntas. Es un error de priorización costoso: todas esas medidas avanzadas suponen, implícitamente, que la suplantación directa del dominio exacto ya está cerrada. Invertir tiempo y presupuesto en una vigilancia de dominios parecidos mientras el dominio principal sigue abierto equivale a instalar una alarma sofisticada en las ventanas de una casa cuya puerta de entrada ni siquiera está cerrada con llave.

Por eso esta prueba debería ser el primerísimo paso de cualquier discusión de seguridad de email en una organización: antes del presupuesto, antes de la elección de herramientas, antes incluso de la decisión de quién liderará el proyecto internamente. La respuesta condiciona todo lo que sigue.

El caso de los dominios que nunca envían email

Un ángulo a menudo olvidado en esta prueba: qué hacer con los dominios que una organización posee pero que nunca envían correo (marcas defensivas, antiguos nombres de producto, dominios reservados por prudencia). La respuesta a la prueba de suplantabilidad para estos dominios debería ser siempre «protegido al máximo», e inmediatamente, sin fase de observación. Como nunca sale de ellos ningún email legítimo, no hay estrictamente ningún riesgo de falso positivo al publicar directamente p=reject; sp=reject; np=reject en un dominio aparcado. A menudo es la prueba más rápida de corregir de toda esta lista: unos minutos de configuración DNS, sin ningún periodo de vigilancia necesario de antemano, al contrario que un dominio activo donde el inventario de fuentes legítimas lleva tiempo. Muchas organizaciones descubren, al hacer este inventario, que poseen muchos más dominios inactivos de los que creían (antiguos nombres de marca, dominios comprados durante una adquisición de empresa nunca depurados desde entonces, variantes reservadas de forma defensiva) y que cada uno de ellos ha permanecido abierto de par en par durante años, un objetivo gratuito que nadie vigilaba.

Hacer la prueba en la práctica

Comprobar manualmente estos tres puntos exige consultar los registros DNS del dominio con una herramienta de consulta (dig, o la interfaz del proveedor DNS), y después interpretar la sintaxis DMARC: accesible, pero que requiere un mínimo de familiaridad técnica para no equivocarse en un detalle de sintaxis.

El método más rápido y más fiable sigue siendo pasar el dominio por el analizador DMARC gratuito, que efectúa estas tres comprobaciones automáticamente y devuelve un resultado claro en unos segundos: política actual, cobertura de los subdominios y alineación de las fuentes si ya existe un registro. Es el equivalente de un escáner de vulnerabilidades, pero para una sola pregunta precisa y fundamental: ¿se puede suplantar el dominio hoy? Al contrario que un escáner de vulnerabilidades genérico que produce una larga lista de resultados que hay que clasificar y priorizar, esta prueba da una respuesta directamente accionable, sin experiencia necesaria para interpretarla ni triaje adicional antes de decidir qué corregir primero.

En resumen

Saber si un dominio es suplantable no exige experiencia avanzada ni una larga auditoría: bastan tres preguntas objetivas: ¿existe un registro DMARC?, en qué política, y ¿están cubiertos los subdominios? Es el punto de partida de toda estrategia de protección contra la suplantación, y la pregunta que hay que volver a plantearse con regularidad, no solo al lanzar un proyecto de seguridad de email: un dominio correctamente configurado hoy no es una garantía de seguir estándolo mañana sin vigilancia continua. Una prueba que lleva tres minutos hoy puede evitar un incidente que costará, ese sí, mucho más de tres minutos resolver, en tiempo, en dinero y en confianza del cliente que reconstruir, ninguno de los tres regresando tan rápido como se perdió.