Cómo monitorizar tus registros SPF, DKIM y DMARC

SPF, DKIM y DMARC son registros TXT situados en tres puntos concretos de tu zona DNS. Monitorizarlos consiste en vigilar esos tres puntos y recibir una alerta cuando su contenido cambie. Por qué merece la pena: un registro roto no impide que tus correos salgan. Siguen saliendo de tu servidor, solo que empiezan a caer en spam o a ser rechazados, y sueles enterarte días después, cuando un cliente menciona una factura que nunca llegó o las tasas de apertura se desploman. Este artículo sitúa cada registro en el mapa, repasa las operaciones cotidianas que los rompen y muestra cómo poner una alerta sobre los tres.

Dónde viven SPF, DKIM y DMARC en tu DNS

Mecanismo	Ubicación DNS	Aspecto del registro
SPF	TXT en el apex (example.com)	v=spf1 include:_spf.google.com ~all
DMARC	TXT en _dmarc.example.com	v=DMARC1; p=quarantine; rua=mailto:reports@example.com
DKIM	TXT en <selector>._domainkey.example.com	v=DKIM1; k=rsa; p=MIGfMA0GCSq...

El selector DKIM lo elige tu proveedor de correo, no tú. Google Workspace usa google, Microsoft 365 usa selector1 y selector2, y cada herramienta de envío (Mailchimp, SendGrid, Brevo) trae el suyo. Un dominio que envía a través de tres herramientas suele tener publicados tres o más selectores DKIM, y algunos proveedores funcionan por delegación CNAME en lugar de un TXT directo. Si necesitas repasar cómo funcionan los registros TXT en general, consulta los tipos de registros DNS explicados.

Cómo se rompen estos registros en la práctica

Ninguno de los escenarios siguientes involucra a un atacante. Son operaciones rutinarias, hechas por gente con buenas intenciones.

La sobrescritura del SPF

Un dominio solo admite un registro SPF. Esta es la causa de rotura más frecuente: un compañero da de alta un CRM o una herramienta de newsletter, sigue la guía del proveedor y pega el registro SPF del proveedor en el DNS, como entrada nueva o en lugar del existente. En ambos casos, la fusión que debía producirse no se produjo, y el resto de remitentes del dominio empieza a fallar la comprobación SPF.

La segunda trampa del SPF es el límite de 10 lookups DNS. Cada include: consume lookups, y los includes anidados también cuentan. Con suficientes herramientas, el registro supera el límite y los servidores receptores lo tratan como un error permanente, aunque cada entrada sea legítima.

La rotación de claves DKIM

Los proveedores de correo rotan sus claves de firma. Cuando ocurre, un selector antiguo deja de validar, o aparece un selector nuevo que nadie ha publicado en el DNS. La variante que más duele es la limpieza de CNAME: muchos proveedores delegan el DKIM mediante registros CNAME que apuntan a su propia zona, y una pasada bienintencionada de "eliminar registros sin uso" borra la delegación. Desde ese momento la firma falla, sin hacer ruido.

La migración DNS que pierde los TXT

Cuando un dominio se muda a otro proveedor DNS, los registros visibles viajan bien. Los A, MX y CNAME se copian, porque sin ellos la web y el buzón fallarían de forma escandalosa. Los registros con guion bajo, _dmarc y todo lo que cuelga de _domainkey, son los que más se olvidan, precisamente porque nada se rompe de forma visible cuando faltan.

Lo que una política DMARC estricta amplifica

Un DMARC en p=none se limita a observar. Con p=quarantine o p=reject, los receptores actúan sobre los fallos: tus propios correos legítimos acaban en spam o son rechazados en cuanto SPF y DKIM fallan ambos la alineación. Ese es el propósito del mecanismo, porque es lo que frena los correos de phishing enviados en tu nombre. Pero corta en ambos sentidos: una política endurecida convierte una sobrescritura de SPF silenciosa en una avería de entrega inmediata.

Desde 2024, Gmail y Yahoo exigen un registro DMARC a los remitentes de gran volumen. Si ese requisito te llevó a publicarlo, el orden prudente es este: primero monitorizar, después endurecer.

Poner los tres bajo vigilancia con Domain Sentinel

Este es el flujo real con la monitorización DNS de Domain Sentinel. Añade tu dominio a la watchlist y activa la monitorización DNS. Las comprobaciones por defecto cubren los registros TXT del apex, así que tu SPF queda vigilado sin más configuración. Para los otros dos puntos, añade los hostnames en Extra names: _dmarc, más cada selector DKIM que uses, por ejemplo google._domainkey o selector1._domainkey. Cada dominio admite diez nombres adicionales, suficiente para unas cuantas herramientas de envío.

Una aclaración honesta: Domain Sentinel no descubre tus selectores DKIM por ti. Tienes que saber qué selectores usan tus proveedores, y la lista está en los ajustes de autenticación de cada uno. Dedica cinco minutos a reunirla antes de configurar la vigilancia.

Los registros se comprueban una vez al día. Cuando un TXT vigilado cambia, recibes un correo con el valor anterior y el nuevo: una sobrescritura de SPF o un _dmarc desaparecido sale a la luz al día siguiente, no semanas después. Domain Sentinel detecta cambios; no evalúa si tu sintaxis SPF o tu política DMARC son correctas. Para esa validación puntual, usa un verificador dedicado y deja luego que la monitorización custodie el resultado. Cómo encaja todo esto en la vigilancia de un dominio en sentido amplio se explica en qué es la monitorización DNS.

Comprobar el estado actual

Antes de configurar nada, mira qué hay publicado hoy:

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT google._domainkey.example.com

Sustituye por tu dominio y tus selectores. ¿Sin terminal a mano? La herramienta de lookup DNS acepta un nombre de host, así que puedes leer _dmarc y cada uno de tus selectores DKIM desde el navegador.

Tres pasos concretos para esta semana: inventariar cada herramienta que envía correo por tu dominio y anotar su selector DKIM, lanzar las tres consultas de arriba y corregir lo que falte, y poner los tres puntos bajo vigilancia. Solo después conviene plantearse pasar DMARC de p=none a una política más estricta.