Alertas DMARC: monitorizar emails sin volverte loco

Configurar SPF, DKIM y DMARC es la parte fácil. Hay cincuenta tutoriales que te llevan de la mano hasta poner el p=reject en el TXT de tu DNS y darte una palmadita en la espalda. Lo que casi ninguno te cuenta es lo que pasa al día siguiente.

El agujero ciego del que nadie habla

A los pocos días de pasar a p=reject, los reportes XML empiezan a llegar a la dirección que pusiste en el rua= y se acumulan en una carpeta de IMAP que nadie abre. Cinco al día por dominio. Diez si tienes varios dominios y mucho volumen. La sensación es de “ya está”, el dominio ya está blindado.

No lo está. Lo que has hecho es montar la cerradura. Lo que falta es la cámara que avise cuando alguien intenta forzarla. Eso es la monitorización DMARC del día a día, y casi nadie la implementa.

Las preguntas que importan no son del setup, son del día a día:

• ¿Hay un servidor nuevo enviando emails con mi dominio que yo no he autorizado?
• ¿Cambió alguien mi registro DMARC sin avisarme?
• ¿Por qué ayer salieron 50.000 emails si normalmente salen 2.000?
• ¿Qué porcentaje de mis emails legítimos está pasando autenticación esta semana?

Sin un sistema que conteste a estas preguntas en tiempo real, te las haces el día que un cliente te dice que recibió un email “tuyo” que no era tuyo, o el día que tu equipo de ventas reporta que sus correos llevan un mes en spam y nadie sabe por qué.

Por qué leer reportes DMARC a pelo no funciona

Los reportes que envían Google, Microsoft, Yahoo y demás vienen comprimidos en .gz o .zip, son XML, y la estructura es la que te imaginas: árboles anidados, atributos verbosos, codificación que ningún humano va a leer un martes por la tarde.

Un reporte tipo trae decenas o cientos de record y los tres campos que de verdad miras son siempre los mismos:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>17</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <auth_results>
    <dkim>...</dkim>
    <spf>...</spf>
  </auth_results>
</record>

source_ip te dice quién envió. policy_evaluated/disposition te dice qué hizo el receptor (none, quarantine, reject). auth_results te dice por qué pasó o falló cada autenticación.

Multiplica esto por 5-10 reportes al día, varios dominios, y un mes de retención. Tienes miles de records que humanamente no vas a abrir. Sin un pipeline que parsee, agregue y resalte lo que es raro, el reporte es un cementerio de XMLs. La información existe; solo que no llega a nadie.

Las 4 cosas que sí merece la pena monitorizar en tiempo real

No hace falta vigilarlo todo. Hace falta vigilar las cuatro señales que de verdad cambian decisiones.

1. Picos de volumen anómalos

Si tu dominio principal manda 2.000 emails al día y un martes salen 50.000, una de dos: alguien está suplantándote a escala, o un sistema interno se ha roto. Un cron que entró en bucle. Una campaña de marketing que dispararon mal. Una integración nueva que se autorenvía.

La detección no es ciencia: una ventana móvil de 7 a 30 días sobre el volumen diario, y una alerta cuando el día actual supera el percentil 95 móvil en un 200% o se desvía más de 3 desviaciones estándar del baseline. El umbral exacto depende de la varianza natural de tu negocio. Lo importante es tener un baseline calculado y disparar cuando se rompe.

Sin esto, los picos se ven cuando alguien te pasa el aviso por otro canal: tu proveedor de email cortando la salida, un cliente quejándose de que le llegaron 30 mensajes iguales, una factura abultada. Siempre tarde.

2. Senders nuevos / IPs no vistas antes

Cada vez que una IP nueva envía emails con tu dominio, debería ser una decisión consciente. No un descubrimiento.

Los casos típicos son siempre los mismos:

• Un departamento contrata un SaaS de email marketing (Mailchimp, Brevo, ConvertKit) y se olvida de añadir el include al SPF.
• Alguien levanta un cron en un VPS nuevo para enviar notificaciones y no avisa a nadie.
• Un servicio que llevaba años usando una IP cambia de proveedor.

Y luego está el caso que no quieres descubrir tarde: un servidor comprometido en otro continente enviando phishing con tu dominio en el From.

La mecánica es directa: mantén un inventario de IPs conocidas y autorizadas, y dispara una alerta la primera vez que aparezca una IP que no esté en esa lista. Puedes marcarla como “conocida” en un click si es legítima. La que importa es la que no marcas.

3. Cambios en registros DNS (DMARC, SPF, DKIM)

Si alguien con acceso al panel del registrador cambia tu p=reject a p=none, te bajan la guardia y nadie se entera. Si “limpian” el SPF y se llevan por delante un include legítimo, tus emails empiezan a fallar y el equipo de soporte recibe quejas durante días sin saber por qué.

No es un escenario de película. Pasa más de lo que parece:

• Rotación de claves DKIM mal propagada que rompe la firma durante horas.
• Becario de IT que “ordena” el SPF y deja fuera un servicio.
• Cambio de proveedor de email transaccional que pisa la configuración anterior.
• Ataque al panel del registrador, mucho más raro pero con consecuencias mayores.

La defensa es simple: una resolución DNS programada cada hora contra los registros DMARC, SPF y DKIM relevantes, comparación con el último snapshot, y alerta inmediata cuando algo cambia. No es prevención, es detección. Pero el tiempo entre el cambio y que tú te enteras pasa de “días o semanas” a “minutos”.

4. Tasa de compliance

Es el indicador de salud que más se ignora. La compliance es el porcentaje de tus emails legítimos que pasan SPF + DKIM con alineamiento DMARC. Cuando tu setup está bien, este número vive entre el 95% y el 99%. Cuando algo se rompe, cae.

Si en una semana pasa del 96% al 72%, no necesitas mirar reportes uno a uno: algo se ha roto. Los sospechosos habituales son los mismos del punto anterior — rotación de claves DKIM mal sincronizada, un nuevo servicio que envía sin firmar, un registro DNS recién modificado.

El umbral de alerta debería ser configurable y conservador. Yo dispararía una alerta por debajo del 90% sostenido durante más de un día. No tienes que saber qué pasó al ver la alerta. Tienes que saber que pasa algo y que toca investigar.

Cómo aterriza esto en la práctica

En mi setup uso DMARC Examiner y la mecánica es la que esperarías: apuntas el rua= de tu registro DMARC a la dirección única que te genera por dominio (algo del estilo <token>@reports.dmarc-examiner.com) y se acabó. Los reportes se ingestan cada pocos minutos, se parsean, se deduplican y se agregan. Las alertas llegan por email instantáneo o como digest semanal. Los webhooks tienen auto-disable después de 10 fallos consecutivos para que un endpoint roto no se convierta en otro problema. En mi caso los mando a un canal de Slack para revisión rápida y a un workflow de n8n que cruza la alerta con un inventario interno de IPs.

Antes probé otras cosas. Parsear los XML con un script propio funciona dos semanas; el día que hay que añadir un nuevo tipo de alerta o reescribirlo en otro lenguaje empiezas a perder la voluntad. MXToolbox sigue siendo excelente para diagnósticos puntuales — un check rápido de SPF, una comprobación de blacklist —, pero no es monitorización continua. Dmarcian es una herramienta sólida y madura, pero su pricing está orientado a corporativo y se nota en la factura desde el primer mes.

Sea cual sea la herramienta que elijas, el criterio mínimo que te recomiendo es: detección de picos de volumen, alertas en cambios DNS y digest semanal con resumen ejecutivo. Sin esas tres no tienes monitorización, tienes un cementerio de XMLs.

Lo que ninguna herramienta te da

Un dueño humano del proceso. La automatización detecta. La decisión la tomas tú.

Una alerta sin runbook es una distracción que acaba en un canal de Slack que nadie lee. Conviene escribir, aunque sea en una página, qué se hace cuando salta cada tipo:

• Sender nuevo: 1) verificar la IP contra el inventario interno de servicios autorizados, 2) si no coincide, contactar con el departamento que pueda haberlo provocado, 3) si nadie lo reclama en 24h, escalar como posible suplantación.
• Cambio DNS: 1) verificar quién y cuándo en el log del registrador, 2) confirmar si fue cambio autorizado, 3) si no, revertir y rotar credenciales del panel.
• Pico de volumen: 1) confirmar si hay campaña planificada, 2) si no, revisar logs del MTA para identificar fuente, 3) cortar y diagnosticar.

Más vale tener tres alertas con un dueño claro y un runbook de tres pasos que cincuenta alertas que nadie atiende.

Checklist — ¿estás monitorizando o solo configurado?

Pasa esta lista por tu organización. Cada “no” es un punto ciego.

• ¿Sabes cuántos emails al día salen en promedio desde tu dominio principal? Si no, no detectas picos.
• ¿Tienes la lista de IPs y servicios autorizados a enviar en tu nombre? Si no, no detectas senders nuevos.
• ¿Recibirías una alerta hoy si alguien cambia tu registro DMARC? Si no, punto ciego crítico.
• ¿Tienes un umbral de compliance configurado y alertando cuando cae? Si no, la calidad de tu autenticación se degrada en silencio.
• ¿Hay un dueño humano del proceso? Si no, nadie va a actuar sobre las alertas.
• ¿Está documentado el runbook de “qué hago cuando salta esta alerta”? Si no, cada incidente se reinventa.
• ¿Recibes un digest periódico de salud del dominio? Si no, no hay revisión proactiva, solo reactiva.

Configurar DMARC es la entrada al juego. Monitorizarlo es jugarlo. Sin lo segundo, lo primero es decoración.

Si vas a probar DMARC Examiner, tienes un 20% de descuento durante los 3 primeros meses con el código LMMARTINB20, válido para los planes Basic, Pro y Ultimate.

PD: Si quieres comparar setups, contarme un caso raro o discutir umbrales, mándame un DM por twitter.