¿SPF, DKIM o DMARC dejaron de funcionar? Cómo encontrar la causa

Una autenticación que pasó durante dos años puede fallar un martes sin ningún mensaje de error y sin ningún cambio que recuerdes haber hecho. El correo sigue saliendo de tus servidores. Solo que llega a spam, o como un fallo de DMARC en un informe que no has abierto, o no llega. Esta guía cubre lo que suele romper SPF, DKIM y DMARC cuando ya funcionaban, cómo encontrar la causa en minutos con unas pocas consultas DNS y cómo enterarte de la próxima regresión antes de que lo haga tu tasa de rebote.

La respuesta breve#

Cuando una autenticación que funcionaba empieza a fallar, algo cambió en el DNS o algo cambió en el remitente. Comprueba en este orden: ¿se cambió hace poco de proveedor de DNS o de servidores de nombres, hay exactamente un registro SPF, el selector DKIM del mensaje que falla sigue devolviendo una clave, hay exactamente un registro DMARC en _dmarc y alguna herramienta nueva empezó a enviar como tu dominio? Esas cinco preguntas explican la mayoría de las regresiones. Lee primero la cabecera Authentication-Results de un mensaje que falla, porque te dice cuál de SPF, DKIM o DMARC falló y para qué dominio. El analizador de cabeceras de correo muestra esos veredictos, y el verificador de SPF, DKIM y DMARC muestra lo que dice el DNS ahora mismo.

Lee primero el mensaje que falla#

No adivines qué protocolo se rompió. Abre las cabeceras completas de un mensaje que falló y busca la línea Authentication-Results que añadió el servidor receptor.

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.example.com;
  dkim=fail header.d=example.com header.s=mail;
  dmarc=fail header.from=example.com

Importan tres detalles. spf= y dkim= muestran qué comprobación falló. header.s es el selector DKIM que se usó, lo que te da el nombre DNS exacto que debes consultar. Y smtp.mailfrom o header.d indican qué dominio evaluó cada comprobación, algo relevante cuando el mensaje pasa SPF para un dominio distinto del de la cabecera From.

Después consulta los registros desde la línea de comandos. Funcionan en macOS y Linux.

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Sustituye mail por el selector de la cabecera. Si no lo conoces, cómo encontrar un selector DKIM te lo explica paso a paso. Si la consulta no devuelve nada, el registro ya no existe. Si devuelve algo, léelo con atención, porque la siguiente sección explica cómo un registro puede existir y aun así estar roto.

Causa 1: una migración de DNS eliminó o alteró registros#

Pasar a un nuevo proveedor de DNS, a un nuevo registrador o a una nueva plataforma web es el desencadenante más común. La herramienta de importación copia lo que entiende, normalmente registros A, CNAME y MX, y omite o reescribe en silencio los registros TXT. Los síntomas son un dominio sin SPF, sin DMARC, o con un selector DKIM que ya no se resuelve, todo desde la fecha de la migración.

Comprueba tres cosas después de cualquier cambio: que los servidores de nombres apuntan realmente a donde crees, que todos los registros de autenticación existen en el nuevo proveedor y que los valores TXT largos llegaron intactos. Las claves DKIM largas son la baja habitual: algunos proveedores las truncan o añaden espacios sueltos, y una clave cortada falla la verificación aunque el registro "exista" (por qué las claves largas hay que dividirlas). Las guías específicas de Cloudflare y Route 53 muestran cómo lo gestiona cada uno, y cambiar de proveedor de correo cubre la misma trampa desde el lado del correo.

Causa 2: dos registros SPF, o dos registros DMARC#

Un dominio puede publicar exactamente un registro SPF y exactamente un registro DMARC. Esto se rompe sin ruido cuando la página de configuración de una herramienta nueva dice "añade este registro TXT" y alguien añade un segundo registro v=spf1 en lugar de editar el primero.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

Con dos registros como estos, los receptores devuelven un error permanente de SPF, así que SPF falla para todos los mensajes, incluido el correo de las herramientas que sí figuran. La solución es fusionarlos en un único registro con ambos include antes de ~all. La misma regla se aplica en _dmarc: dos registros DMARC hacen que los receptores ignoren ambos. Vigila el presupuesto de consultas al fusionar, porque cada include: añadido cuesta consultas DNS y el límite es 10. SPF: demasiadas consultas DNS explica cómo contarlas.

Causa 3: una clave DKIM se rotó, se movió o se eliminó#

DKIM firma cada mensaje con una clave privada y publica la mitad pública en selector._domainkey.tudominio.com. Si el registro DNS desaparece mientras el remitente sigue firmando con ese selector, todos los mensajes fallan DKIM.

Esto ocurre de varias maneras. Un proveedor rota a un selector nuevo y limpias demasiado pronto el registro antiguo. Alguien borra entradas _domainkey "sin uso" durante una limpieza del DNS. Un CNAME que apunta a una clave alojada por el proveedor deja de resolverse porque el proveedor lo cambió o porque dejaste el servicio. O la clave se revocó, lo que se publica como un valor p= vacío.

La prueba es sencilla: toma el selector del header.s del mensaje que falla, consulta selector._domainkey.tudominio.com y confirma que hay un valor p= con datos de clave reales. Si el selector es erróneo porque el remitente pasó a uno nuevo, publica el nuevo registro que te da el proveedor. Una rotación bien hecha solapa la clave antigua y la nueva, algo que describe la guía del selector.

Causa 4: un remitente nuevo empezó a enviar como tu dominio#

A veces tus registros están bien y lo que cambió fue el remitente. Un equipo activa un CRM, un helpdesk, una herramienta de facturación o una plataforma de newsletters, y cada una empieza a enviar con tu dominio en la dirección From. Si nadie añadió ese servicio a SPF ni configuró su clave DKIM, su correo falla la alineación SPF, puede que no pase nada en absoluto y aparece como fallos en los informes DMARC.

No lo detectarás mirando el DNS, porque el DNS no cambió. Lo detectas mirando quién envía realmente. Para eso sirven los informes agregados de DMARC: una fuente nueva con una tasa de aprobación baja es la firma inconfundible. Para cada una de esas fuentes, o bien la autenticas correctamente (incluirla en SPF cuando proceda y, sobre todo, firmar con DKIM usando tu propio dominio) o evitas que envíe como tú.

Causa 5: un registro de apoyo caducó o cambió#

Algunos fallos están junto a la autenticación en lugar de dentro de ella.

• Cambió el destino de un CNAME. Muchos proveedores te piden apuntar un registro a su nombre de host. Si lo retiran o tú borras el CNAME, la clave o el dominio de retorno dejan de resolverse.
• Un host MX perdió su dirección. El correo hacia tu dominio empieza a rebotar aunque la autenticación saliente sea perfecta, porque el host indicado en MX no tiene registro A ni AAAA.
• La política MTA-STS y el DNS se desincronizaron. El registro TXT _mta-sts sigue ahí, pero el archivo de política HTTPS ya no lista tus hosts MX actuales, o caducó el certificado de un servidor de correo. Los remitentes con una política en modo enforce guardada entonces difieren o rechazan el correo, mientras que los que no tienen política en caché vuelven a la entrega en claro, así que el daño es irregular. Consulta MTA-STS y TLS-RPT.
• Se endureció DMARC. Alguien pasó de p=none a quarantine o reject. Los fallos que siempre estuvieron ahí, como una herramienta sin autenticar o el correo reenviado, ahora te cuestan entregas. El fallo no era nuevo. La consecuencia sí.

Detectar la próxima regresión a tiempo#

La mayor parte de esto se puede detectar solo con el DNS, antes de un solo rebote, porque el estado roto es un registro ausente o mal formado. La excepción es todo lo que hay detrás del registro DNS, como un archivo de política MTA-STS. Comprueba, por orden de urgencia:

1. MX está presente y todos los hosts se resuelven.
2. Exactamente un registro SPF, con sintaxis válida y 10 consultas o menos.
3. Cada selector DKIM del que dependes devuelve una clave con un valor p=.
4. Exactamente un registro DMARC con una política válida y una dirección rua=.

Puedes ejecutar esto a mano después de cada cambio de DNS, y deberías hacerlo. La debilidad de una comprobación manual es que la regresión que te importa ocurre cuando nadie está mirando. El monitoreo de salud del dominio repite estas comprobaciones en cada dominio cubierto una vez al día y te envía un correo cuando aparece un problema y otra vez cuando desaparece. Los códigos de problema se corresponden con esta lista: SPF ausente o múltiple, SPF por encima del límite de consultas, un include de SPF que no publica ningún registro, un selector DKIM configurado sin clave o con una clave revocada, DMARC ausente o inválido y problemas de MX. Un artículo de referencia, monitoreo de la salud del dominio de correo, explica el panorama general y con qué frecuencia comprobar.

Vale la pena conocer dos detalles. Tú le indicas qué selectores DKIM vigilar, porque un selector ausente solo se puede reportar si lo nombraste. Y un timeout de DNS produce "no se pudo comprobar", no una alerta, de modo que un resolvedor inestable no te despierta.

Lo que el monitoreo no detectará#

El monitoreo de DNS lee solo el DNS público. No puede saber que un CRM nuevo empezó a enviar como tú, que a un registro SPF válido le falta un remitente ni que un proveedor rotó una clave que nunca le indicaste. Los informes agregados de DMARC muestran quién envía realmente como tú, y la prueba de entregabilidad del correo muestra cómo se autentica un mensaje real. La lista completa de límites está en la guía de monitoreo de salud del dominio.

Una autenticación que funciona demuestra que tu correo es tuyo, no que tu lista merezca recibir envíos. Cuando quieras mirar la lista en sí, el plan gratuito de la página de precios te da 100 créditos que ejecutan la verificación completa. Unos registros correctos siguen necesitando una lista sana detrás.