Pegar un registro DMARC en la zona DNS no cierra nada: el registro no hace nada hasta que alguien lee los reportes que genera cada día. La surveillance de domaine designa este trabajo de lectura continua, repartido en 4 ejes: los reportes DMARC, los registros DNS (MX, SPF, DKIM), la fecha de expiración del dominio y los dominios similares registrados por terceros. Sin ella, un equipo de growth descubre el fallo después, cuando el CMO pregunta por qué cayó el open rate. Un caso clásico circula en los foros de email marketing: un sender reputation que se desploma un 30% en tres meses sin que haya cambiado el contenido de ninguna campaña, y la causa casi siempre termina en un registro DNS modificado sin que nadie se diera cuenta.
Los 4 ejes de la vigilancia de dominio
Un dominio mal vigilado pierde el control en 4 frentes a la vez, rara vez en uno solo. El primero son los reportes DMARC agregados (RUA), que llegan a diario a un buzón dedicado que pocos equipos abren. El segundo cubre los propios registros DNS: SPF, DKIM y el registro DMARC pueden ser modificados por un proveedor externo o un script de migración sin que salte ninguna alerta. El tercer eje toca la expiración del dominio, un tema administrativo que nadie quiere asumir. El cuarto concierne a los dominios que se parecen al tuyo por un solo carácter, registrados para engañar a tus clientes mediante suplantación; el mecanismo de esta amenaza se trata más adelante. La vigilancia de dominio no bloquea ningún ataque por sí sola. Dispara la alerta a tiempo, en los 4 frentes a la vez.
Leer los reportes DMARC en lugar de limitarse a publicarlos
Un registro DMARC en p=none no rechaza ni pone en cuarentena ni un solo mensaje. Activa el envío de reportes agregados (RUA), en formato XML, una vez al día en promedio, por cada proveedor que recibe correo firmado por tu dominio: Gmail, Outlook, Yahoo, además de los servidores corporativos que aplican DMARC. Los reportes forenses (RUF), por su parte, detallan un mensaje individual que falló. Google ya no los envía. Microsoft y Yahoo lo siguen haciendo de forma intermitente. Decodificar los campos de un reporte agregado (IP de origen, alineación SPF/DKIM, disposición aplicada por el servidor receptor) es un ejercicio técnico en sí mismo, tratado en detalle en nuestro artículo cómo leer un informe DMARC agregado sin equivocarte. Aquí, el punto práctico se resume en una frase: sin lectura regular, la política se queda atascada en p=none. Es el caso de la mayoría de los dominios protegidos en el mundo, porque no hay quien procese el flujo XML y haga subir la política hacia p=quarantine y después p=reject.
Detectar un cambio DNS no autorizado en MX, SPF, DKIM, DMARC
Herramientas como MXToolbox, CaptainDNS o DNS Assistant consultan la zona DNS a intervalos regulares y disparan una alerta por email o por Slack en cuanto un registro MX, SPF, DKIM o DMARC cambia de valor, tras compararlo con el valor anterior. La diferencia entre el valor antiguo y el nuevo aparece en la alerta, lo que evita repetir un diagnóstico completo en cada incidente. Un registro SPF que supera su límite de 10 consultas DNS falla sin bounce ni alerta visible del lado del remitente, un escenario detallado en nuestro artículo sobre el límite SPF de las 10 búsquedas DNS. Un registro DKIM eliminado tras una migración de hosting rompe igualmente la firma de todos los emails salientes; el único síntoma visible a veces es un NDR (non-delivery report) que muestra el Enhanced Status Code 5.7.1, sin relación evidente con el cambio DNS ocurrido el día anterior. Una transición protocolaria planificada, como la retirada de la etiqueta pct prevista por DMARCbis, produce este mismo tipo de cambio, aparentemente sospechoso pero legítimo: comparar el antes y el después sigue siendo más fiable que reaccionar a ciegas. Nada que revisar cada mañana en una pila ya cargada de alertas: estos servicios funcionan en segundo plano y solo avisan cuando un valor cambia de verdad. Un solo caso justifica instalarlos. El dominio rara vez cambia de configuración DNS una vez estabilizado. Cuando cambia, casi siempre es una modificación voluntaria de alguien del equipo. El monitoreo sirve para detectar la que ningún ticket interno anuncia, la pista más frecuente detrás de un registro secuestrado sin que la cuenta del registrador se vea comprometida, un escenario documentado por Infoblox y Eclypsium bajo el nombre Sitting Ducks.
Cerca de 800.000 dominios vulnerables identificados y más de 30.000 secuestros confirmados desde 2019, sin que se haya comprometido ninguna cuenta de registrador (Infoblox y Eclypsium, 2024).
Vigilar la expiración y la renovación del dominio
El ciclo que sigue a una expiración tiene tres fases: un período de gracia de unos 30 días donde la renovación sigue siendo sencilla, un período de redención de unos 30 días con una penalización de 80 a 200 euros, y después una ventana de eliminación final de 5 a 15 días antes de volver a ponerse a la venta pública. El 13% de los nombres de dominio corporativos expirados son re-registrados por un tercero, según la investigación interna de CSC publicada en 2024. Esta cifra sube en los dominios históricos que quedan en el punto ciego de un portafolio de marca nunca auditado tras una fusión o un cambio de proveedor. Un dominio perdido en esta etapa se lleva consigo el sitio web y las direcciones de correo corporativas. También borra el posicionamiento en Google acumulado durante varios años.
Detectar dominios similares y el typosquatting
Un dominio copiado con un carácter alterado (sustituir una l por una i mayúscula, añadir un guion, usar la extensión .co en vez de .com) basta para montar una página de phishing creíble o una dirección de envío que engaña a un cliente con prisa. Zscaler ThreatLabz identificó más de 30.000 dominios lookalike que imitaban marcas conocidas entre febrero y julio de 2024, de los cuales más de 10.000 fueron catalogados como maliciosos. Solo en marzo de 2025, Palo Alto Networks Unit 42 detectó más de 26.000 dominios que suplantaban marcas o servicios públicos durante campañas de smishing. El mecanismo técnico de esta suplantación, la forma en que un atacante falsifica el remitente de un email, se desarrolla en detalle en nuestro artículo dedicado al email spoofing. Detectarlo con antelación, antes del envío de la primera campaña fraudulenta, limita el daño. Un servicio de vigilancia sobre las variantes cercanas al nombre de marca registrado completa el conjunto.
Frecuencia de verificación recomendada por eje
| Eje vigilado | Frecuencia recomendada | Señal disparadora | Acción si hay alerta |
|---|---|---|---|
| Reportes DMARC (RUA) | Lectura semanal | IP de origen no identificada, alineación SPF/DKIM fallida | Identificar al remitente, ajustar SPF o subir la política a p=quarantine |
| Registros DNS (MX, SPF, DKIM) | Monitoreo continuo con alerta automática | Valor modificado sin cambio planificado | Comparar antiguo/nuevo, restaurar si no está autorizado |
| Expiración del dominio | Verificación trimestral del portafolio | Renovación inferior a 60 días | Activar la renovación automática y el bloqueo del registrador |
| Dominios similares / typosquatting | Vigilancia mensual | Registro de una variante cercana al nombre de marca | Reporte al registrador, procedimiento UDRP si se confirma uso fraudulento |
Este ritmo funciona en la mayoría de las configuraciones observadas en dominios ya estabilizados. Un dominio que acaba de migrar a un nuevo proveedor de email marketing justifica una lectura DMARC diaria el primer mes, mientras la alineación SPF y DKIM se estabiliza en la nueva infraestructura.
Lo que la vigilancia de dominio no cubre
La causa de una deliverability que cae a veces apunta a otro lugar distinto del dominio: casi siempre hacia la propia lista, con una hard bounce rate al alza y direcciones catchall acumuladas con cada importación. Un dominio puede estar perfectamente vigilado (DMARC leído, DNS estable, renovación anticipada, ninguna variante typosquatted detectada) y aun así ver caer su deliverability. El complaint rate también sube, visible a través de los feedback loops de varios proveedores de correo. Estas señales deterioran la reputación del remitente igual que un registro SPF roto. Ninguna herramienta de monitoreo DNS las detecta, y el equivalente de Microsoft al Postmaster de Gmail (SNDS, Smart Network Data Services, menos consultado pero igual de revelador) tampoco cubre la calidad de las direcciones enviadas. La única forma de saber si la lista se ha degradado al mismo tiempo que el DNS es pasarla por un filtro antes del próximo envío, en lugar de descubrir el problema en un dashboard cuando la reputación ya está dañada.
El estándar BIMI, que muestra el logo del remitente en la bandeja de entrada, exige un DMARC en p=reject estable desde hace varias semanas para poder activarse en la mayoría de los proveedores. Pocos dominios cumplen todavía esta condición en 2026.
