Rotación de claves DKIM: cómo rotar con seguridad y sin drama

Qué es realmente la rotación DKIM (y qué no lo es)

La rotación DKIM es el acto de cambiar la clave criptográfica que firma tu correo saliente. En la práctica, eso significa:

• Generas una nueva clave privada en el firmador (MTA o relé saliente).
• Publicas la clave pública correspondiente en DNS bajo un selector.
• Cambias la firma para usar el nuevo selector (o firmas con ambos durante la transición).
• Mantienes la clave pública antigua disponible el tiempo suficiente para que los verificadores validen mensajes antiguos.

Qué no es: un ejercicio de “ajuste” de entregabilidad. La rotación no te hace más confiable por sí sola; reduce el riesgo por compromiso de claves y la deriva operativa. Si tu correo ya falla en SPF/DMARC, rotar DKIM no te salvará. Sin embargo, puede dejar al descubierto que estabas viviendo con riesgo.

Por qué la rotación causa drama

Tres razones:

1. El DNS es un sistema de caché distribuido con opiniones. No “cambias DNS”, negocias con resolutores que no controlas.
2. El correo es asincrónico. Los mensajes pueden retrasarse, reintentarse, ponerse en cola o entregarse horas después, y aún necesitar la clave antigua para validarse.
3. La gente confunde dominios. El dominio visible en From, el dominio d= de DKIM y el dominio del sobre SMTP están relacionados pero no son lo mismo. Confundirlos convierte cambios “simples” en llamadas de incidente entre varios equipos.

Consejo de opinión desde el principio: rota con firma dual si puedes. Si no puedes, aún rotas de forma segura, pero serás más cauto con el tiempo y la retención de claves antiguas en DNS. También: nunca roten durante un lanzamiento importante. Tu yo futuro te enviará una postal desde la carpeta de spam.

Datos interesantes y un poco de historia

• DKIM vino de una fusión. DomainKeys (Yahoo) e Identified Internet Mail (Cisco) se combinaron en DKIM, estandarizado como RFC 4871 en 2007.
• DKIM no cifra el correo. Firma encabezados seleccionados y el cuerpo (o parte de él) para detectar manipulación, no para mantener secretos.
• El selector es una primitiva de versionado. DKIM se diseñó pensando en la rotación: los selectores existen para que puedas publicar múltiples claves simultáneamente.
• Las implementaciones tempranas usaban solo RSA. RSA se convirtió en el predeterminado; Ed25519 apareció después en especificaciones e implementaciones más nuevas, pero la adopción es desigual.
• Las claves RSA de 2048 bits se volvieron el predeterminado “serio”. Aún se ven claves RSA de 1024 bits, pero algunos receptores las tratan como débiles o en contra de la política.
• La validación DKIM ocurre en el momento de la recepción. Eso significa que los receptores necesitan acceso a DNS de tu clave pública cuando evalúan el mensaje —no cuando lo enviaste.
• DKIM puede sobrevivir al reenvío mejor que SPF. SPF revisa la ruta; DKIM revisa el contenido. Los reenviadores rompen SPF de forma rutinaria; DKIM a menudo sobrevive si el reenviador no reescribe las partes firmadas.
• DMARC hizo a DKIM operacionalmente obligatorio. Cuando la aplicación de DMARC se volvió común, DKIM dejó de ser “agradable tener” y pasó a ser “no me hagas recibir alertas”.

Modelo mental: selectores, claves, DNS y tiempo

Pensa en DKIM como cuatro piezas en movimiento:

• Firmador: el sistema que guarda la clave privada y añade la cabecera DKIM-Signature (Postfix + OpenDKIM, un relé en la nube o un ESP).
• Selector: una cadena como s2026q1 que elige qué clave buscar en DNS.
• Registro DNS: un registro TXT en <selector>._domainkey.<domain> que contiene la clave pública y metadatos.
• Receptor: Gmail, Outlook y todos los demás que hacen consultas DNS y validación de firma cuando aceptan el mensaje.

El tiempo es la dependencia oculta

El sistema tiene dos relojes separados:

1. Propagación y caché del DNS: TTL más comportamiento del resolutor.
2. Latencia en la entrega del correo: colas, reintentos, graylisting, congestión y “ese aparato legado” que intenta de nuevo mañana.

La rotación falla cuando eliminas la clave antigua del DNS antes de que el mundo termine de validar el correo firmado con ella. También falla cuando cambias el firmador antes de que la nueva clave sea visible para los receptores. La respuesta es aburrida: solapamiento.

Una cita, porque encaja

La esperanza no es una estrategia. — atribuido a varios líderes de ingeniería; común en operaciones y círculos de confiabilidad.

Broma 1: La caché DNS es como purpurina: crees que la limpiaste y luego aparece en tu coche tres semanas después.

Preflight: inventario y control del radio de impacto

Antes de tocar claves, responde tres preguntas con evidencia:

1. ¿Quién está firmando hoy? Tal vez sean tus MTAs. Tal vez tu ESP. Tal vez ambos (marketing vs transaccional). “Ambos” es común y no es intrínsecamente malo—hasta que rotas uno y olvidas el otro.
2. ¿Qué dominios y subdominios están en juego? example.com, mail.example.com, news.example.com y dominios de return-path personalizados pueden existir. Cada uno puede tener selectores y políticas separadas.
3. ¿Qué política depende de que DKIM pase? La aplicación de DMARC (quarantine/reject) convierte un pequeño error de DKIM en un paro total.

Elige un esquema de nombres de selectores que no envejezca mal

Los selectores son cadenas. Eso es poder y caos. Elige algo que siga siendo sensato a través de años y equipos:

• Bueno: s2026q1, mta1-2026-01, rotate-01
• Malo: default, dkim, test, new (porque “new” se vuelve “old” antes de que cierre tu ticket de cambio)

Decide la duración del solapamiento

Mi recomendación práctica:

• Mantén el selector antiguo publicado al menos 7 días después del corte para la mayoría de las organizaciones.
• Manténlo 30 días si tienes colas de correo largas, sistemas regulados o cualquier comportamiento tipo “enviamos estados semanalmente”.

Los receptores pueden validar mensajes antiguos después (piensa: entrega retrasada, reprocesado o migración de buzones). No hay premio por eliminar claves DNS antiguas rápido. El premio es no recibir alertas.

Tareas prácticas con comandos, salidas y decisiones

El objetivo de los comandos no es trabajo ocupacional. Es convertir “creo” en “sé”. Estas tareas están escritas para un entorno típico basado en Linux con Postfix + OpenDKIM, más verificación DNS genérica. Ajusta rutas y nombres de servicio si usas otro firmador, pero mantiene la disciplina: observar, cambiar, observar de nuevo.

Task 1: Confirmar qué selector está firmando actualmente

Envíate un mensaje desde tu sistema y luego inspecciona las cabeceras en tu buzón. En un servidor de correo Linux también puedes buscar DKIM-Signature en los logs si registras resultados del milter.

cr0x@server:~$ sudo grep -R "DKIM-Signature" -n /var/log/mail.log | tail -n 3
Jan 04 09:12:11 mta1 postfix/cleanup[23111]: 4A2B9123: message-id=<...>
Jan 04 09:12:11 mta1 opendkim[1122]: 4A2B9123: DKIM-Signature field added (s=selector2025, d=example.com)
Jan 04 09:12:12 mta1 postfix/qmgr[977]: 4A2B9123: from=<noreply@example.com>, size=..., nrcpt=1 (queue active)

Qué significa: Actualmente estás firmando con el selector selector2025 para d=example.com.

Decisión: Este es tu selector “antiguo”. Debes mantener su registro DNS durante y después de la rotación.

Task 2: Enumerar todos los registros DKIM DNS que publicas actualmente

cr0x@server:~$ dig +short TXT selector2025._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB"

Qué significa: Ese selector existe y publica una clave pública.

Decisión: Si dig no devuelve nada, detente. Estás firmando con un selector que no está publicado, y la rotación no es tu mayor problema.

Task 3: Comprobar el TTL efectivo y si puedes bajarlo con seguridad

cr0x@server:~$ dig TXT selector2025._domainkey.example.com +noall +answer
selector2025._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB"

Qué significa: El TTL es 3600 segundos (1 hora).

Decisión: Si el TTL es enorme (por ejemplo 86400), bájalo un día antes del corte para que las cachés se vacíen más rápido. Si no puedes cambiar el TTL (DNS gestionado con restricciones), planifica un solapamiento más largo y haz firma dual si es posible.

Task 4: Generar un nuevo par de claves DKIM (ejemplo OpenDKIM)

cr0x@server:~$ sudo mkdir -p /etc/opendkim/keys/example.com/selector2026
cr0x@server:~$ sudo opendkim-genkey -b 2048 -D /etc/opendkim/keys/example.com/selector2026 -d example.com -s selector2026
cr0x@server:~$ sudo ls -l /etc/opendkim/keys/example.com/selector2026
total 8
-rw------- 1 root root 1704 Jan  4 10:02 selector2026.private
-rw-r--r-- 1 root root  451 Jan  4 10:02 selector2026.txt

Qué significa: Tienes una clave privada y una plantilla TXT para DNS.

Decisión: Usa RSA de 2048 bits salvo una razón fuerte para no hacerlo. Si tu plataforma soporta Ed25519 y tus receptores lo aceptan, puedes evaluarlo—pero no hagas un experimento de compatibilidad durante una rotación.

Task 5: Validar permisos del archivo de clave (las claves privadas no son proyectos de grupo)

cr0x@server:~$ sudo stat -c "%n %a %U:%G" /etc/opendkim/keys/example.com/selector2026/selector2026.private
/etc/opendkim/keys/example.com/selector2026/selector2026.private 600 root:root

Qué significa: El archivo es legible solo por root.

Decisión: Asegura que el usuario de OpenDKIM pueda leerlo (a menudo mediante propiedad o grupo). Los permisos incorrectos causan cortes silenciosos donde “la firma se detuvo”.

Task 6: Configurar OpenDKIM para conocer la nueva clave (KeyTable/SigningTable)

cr0x@server:~$ sudo grep -n "example.com" /etc/opendkim/KeyTable /etc/opendkim/SigningTable
/etc/opendkim/KeyTable:12:selector2025._domainkey.example.com example.com:selector2025:/etc/opendkim/keys/example.com/selector2025/selector2025.private
/etc/opendkim/SigningTable:9:*@example.com selector2025._domainkey.example.com

Qué significa: Todo apunta a selector2025.

Decisión: Añade las líneas del nuevo selector. Si planeas firma dual, tu enfoque depende del software (alguno soporta múltiples firmas; otros no). Si no puedes firma dual, harás un corte pero mantendrás el DNS antiguo publicado.

Task 7: Añadir el nuevo selector a KeyTable

cr0x@server:~$ sudo bash -lc 'echo "selector2026._domainkey.example.com example.com:selector2026:/etc/opendkim/keys/example.com/selector2026/selector2026.private" >> /etc/opendkim/KeyTable'
cr0x@server:~$ sudo tail -n 2 /etc/opendkim/KeyTable
selector2025._domainkey.example.com example.com:selector2025:/etc/opendkim/keys/example.com/selector2025/selector2025.private
selector2026._domainkey.example.com example.com:selector2026:/etc/opendkim/keys/example.com/selector2026/selector2026.private

Qué significa: OpenDKIM ahora sabe dónde está la nueva clave privada.

Decisión: Si usas una KeyTable respaldada por base de datos o un firmador diferente, aplica el paso equivalente: registra el selector y la ruta de la clave.

Task 8: Cambiar la tabla de firmas al nuevo selector (ejemplo de corte por firma única)

cr0x@server:~$ sudo sed -i 's/\*@example.com selector2025\._domainkey\.example\.com/*@example.com selector2026._domainkey.example.com/' /etc/opendkim/SigningTable
cr0x@server:~$ sudo grep -n "\*@example.com" /etc/opendkim/SigningTable
9:*@example.com selector2026._domainkey.example.com

Qué significa: El correo nuevo será firmado con selector2026 una vez que OpenDKIM recargue.

Decisión: No recargues aún si el DNS no está publicado. Firmar con un selector que nadie puede obtener equivale a DKIM=fail en los receptores.

Task 9: Extraer el valor TXT de DNS que debes publicar

cr0x@server:~$ sudo cat /etc/opendkim/keys/example.com/selector2026/selector2026.txt
selector2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB" )  ; ----- DKIM key selector2026 for example.com

Qué significa: Ese valor p= es lo que usarán los receptores.

Decisión: Publícalo exactamente. No metas comillas extra desde la interfaz DNS, no insertes saltos de línea en la clave, no omitas puntos y comas. El comportamiento de las herramientas DNS varía; valida después de publicar.

Task 10: Publicar el nuevo registro DKIM y verificar desde múltiples resolutores

cr0x@server:~$ dig +noall +answer TXT selector2026._domainkey.example.com
selector2026._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB"

Qué significa: El registro existe y el TTL es 300 segundos (5 minutos).

Decisión: Si el TTL no es el esperado, arréglalo ahora mientras nadie depende de él. También consulta un resolutor público conocido para reducir el riesgo de “mi DNS corporativo me miente”.

cr0x@server:~$ dig @1.1.1.1 +short TXT selector2026._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB"

Qué significa: Un resolutor público lo ve.

Decisión: No realices el corte hasta que al menos dos resolutores independientes devuelvan la nueva clave de forma consistente.

Task 11: Recargar OpenDKIM limpiamente y confirmar que no hubo errores

cr0x@server:~$ sudo systemctl reload opendkim
cr0x@server:~$ sudo systemctl status opendkim --no-pager -l
● opendkim.service - OpenDKIM Milter
     Loaded: loaded (/lib/systemd/system/opendkim.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-04 09:00:03 UTC; 1h 8min ago
       Docs: man:opendkim(8)
   Main PID: 1122 (opendkim)
     Status: "Running"

Qué significa: El servicio está activo. Eso es necesario, no suficiente.

Decisión: Revisa inmediatamente los logs por errores de carga de claves; OpenDKIM puede estar en ejecución mientras falla al firmar.

Task 12: Confirmar que OpenDKIM usa el nuevo selector en los logs

cr0x@server:~$ sudo tail -n 20 /var/log/mail.log | grep -E "opendkim|DKIM-Signature" | tail -n 5
Jan 04 10:12:07 mta1 opendkim[1122]: 6C9FD123: DKIM-Signature field added (s=selector2026, d=example.com)
Jan 04 10:12:07 mta1 postfix/qmgr[977]: 6C9FD123: from=<noreply@example.com>, size=..., nrcpt=1 (queue active)

Qué significa: El correo ahora se firma con selector2026.

Decisión: Procede a la verificación externa (cabeceras en Gmail o un buzón de prueba) antes de declarar victoria.

Task 13: Verificar que DKIM pasa en un mensaje recibido (inspección de cabeceras)

En Gmail u Outlook, ve la fuente original del mensaje. Buscas los resultados de autenticación.

cr0x@server:~$ python3 - <<'PY'
import re,sys
msg=open('/tmp/raw.eml','r',errors='ignore').read()
m=re.search(r'Authentication-Results:.*', msg, re.I)
print(m.group(0) if m else "no Authentication-Results header found")
PY
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector2026 header.b=AbCdEf...

Qué significa: DKIM está pasando y el selector es correcto.

Decisión: Si DKIM=fail, detente y depura antes de proceder a desmantelar la clave antigua.

Task 14: Rastrear el uso continuo del selector antiguo (para saber cuándo es seguro retirarlo)

cr0x@server:~$ sudo grep -R "s=selector2025" -n /var/log/mail.log | tail -n 5
Jan 03 23:48:51 mta1 opendkim[1122]: 1F0A9123: DKIM-Signature field added (s=selector2025, d=example.com)

Qué significa: El último correo observado firmado con el selector antiguo fue ayer.

Decisión: Si esto sigue apareciendo después del corte, tienes otro firmador, un segundo MTA o un despliegue parcial. No borres el DNS antiguo hasta saber que todos los firmadores están cambiados.

Task 15: Confirmar que la rotación no dañará la alineación DMARC

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com; adkim=s; aspf=s"

Qué significa: DMARC tiene alineación estricta (adkim=s). Eso significa que d= en DKIM debe coincidir exactamente con el dominio From.

Decisión: Asegura que tu firmador use d=example.com (no un subdominio) si el From es @example.com. La rotación es un momento propenso a cambiar accidentalmente d= y causar fallos DMARC.

Task 16: Detectar formato DNS roto (comillas, puntos y coma y cadenas partidas)

cr0x@server:~$ dig +short TXT selector2026._domainkey.example.com | tr -d '"' | grep -E "v=DKIM1;|p="
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp....IDAQAB

Qué significa: Puedes ver v=DKIM1 y p= limpiamente en el TXT devuelto.

Decisión: Si tu salida contiene paréntesis sobrantes, fragmentos rotos o falta p=, corrige el DNS. Algunas consolas envuelven registros TXT largos incorrectamente si pegas con espacios.

Broma 2: Rotar claves DKIM sin monitoreo es como cambiar paracaídas en pleno vuelo porque la etiqueta se veía vieja.

Listas de verificación / plan paso a paso (rotación sin drama)

Plan A: Mejores prácticas (selectores con firma dual)

Si tu pila de firma soporta añadir dos cabeceras DKIM-Signature (selector antiguo y nuevo), hazlo. Te compra la pereza correcta: los receptores pueden validar con cualquiera de las claves mientras las cachés y los rezagados se ponen al día.

1. Elige un nuevo selector con un esquema de nombres sensato (por ejemplo, s2026q1).
2. Baja el TTL en el/los registro(s) DKIM actuales 24 horas antes del corte (por ejemplo, a 300 segundos), si tu proceso de cambios DNS lo permite.
3. Genera un nuevo par de claves en el firmador, guarda la privada con seguridad, ajusta permisos y regístrala en la configuración del firmador.
4. Publica la nueva clave pública en DNS bajo el nuevo selector. Verifica vía múltiples resolutores.
5. Activa la firma dual: firma cada mensaje con ambos selectores al menos 48 horas (a menudo más en organizaciones grandes).
6. Mide: confirma que los receptores reportan DKIM=pass con el nuevo selector de forma consistente.
7. Deja de firmar con el selector antiguo cuando estés seguro, pero mantén publicado el registro DNS del selector antiguo.
8. Retira la clave DNS antigua solo después del periodo de solapamiento y cuando tengas evidencia de que ningún sistema la usa.

Plan B: Corte por firma única (seguros, pero menos tolerante)

1. Elige selector y genera las claves.
2. Publica el nuevo selector en DNS primero. Verifica desde fuera de tu red.
3. Espera al menos una ventana de TTL (y, realísticamente, más) para que las cachés lo recojan.
4. Cambia la firma al nuevo selector y recarga el firmador.
5. Verifica DKIM pasa usando cabeceras reales de buzones (Gmail/Outlook) y tus logs.
6. Mantén publicado el selector antiguo en DNS durante el periodo de solapamiento.

Plan de reversión (escríbelo antes de necesitarlo)

Las reversiones deben ser aburridas. Si improvisás, ya estás perdiendo tiempo.

• Disparador de reversión: aumenta la tasa de fallos DKIM; aparecen fallos DMARC; búsquedas de clave devuelven NXDOMAIN de forma intermitente; receptores mayores muestran “firma mala”.
• Acción de reversión: vuelve a cambiar la tabla de firmas al selector antiguo y recarga el firmador; mantiene ambos registros DNS publicados.
• Verificación de reversión: confirma que los logs muestran firma con el selector antiguo; confirma DKIM pasa en un buzón externo.

Importante: la reversión solo es posible si no eliminaste el registro de la clave antigua (y mantuviste la clave privada antigua accesible para el firmador). Te sorprendería cuánta gente “limpia” temprano.

Reglas para la ventana de cambio (mis opiniones fuertes)

• Hazlo a mitad de semana durante horas con equipo disponible. Rotar un viernes es un hobby, no una práctica.
• No lo combines con otros cambios. Rotación de claves más cambios de enrutamiento saliente es la forma de entrar en el infierno de “múltiples causas plausibles”.
• Anuncia a los interesados que poseen flujos de envío. Plataformas de marketing, CRM, sistemas de tickets, aplicaciones internas. Estás rotando su maquinaria de reputación; merecen aviso.

Guía de diagnóstico rápido

Cuando la entregabilidad cae tras una rotación, necesitas un camino rápido y ordenado. No una sesión de lluvia de ideas.

Primero: determina si DKIM falla por DNS o por firma

1. Revisa un mensaje real recibido (cabeceras de Gmail/Outlook): busca Authentication-Results y si dice dkim=pass o dkim=fail, además de qué selector header.s usó.
2. Si falla, consulta DNS por ese selector desde un resolutor público y desde tu servidor. Si DNS no devuelve nada o las respuestas son inconsistentes, tienes un problema de propagación/caché.
3. Si DNS parece bien, inspecciona los logs del firmador en busca de “key not found”, “permission denied” o “no signature added”. Ahí está tu tubería de firma.

Segundo: comprueba el impacto en la alineación DMARC

1. Confirma que el valor DKIM d= coincide con el dominio visible From, especialmente si DMARC tiene alineación estricta (adkim=s).
2. Confirma que ningún nuevo camino saliente reescribe el From o añade otra firma DKIM que confunda a los receptores.

Tercero: identifica cortes parciales y confusión por múltiples firmadores

1. Busca en los logs ambos selectores. Si ambos aparecen días después, tienes más de un firmador.
2. Revisa ESPs de marketing o relés en la nube que firmen en tu nombre. Pueden tener su propia configuración DKIM y selectores.
3. Busca mensajes con múltiples cabeceras DKIM-Signature y mira cuáles pasan/fallan. Una firma fallida puede ser aceptable si otra pasa, pero las reglas de alineación DMARC importan.

El cuello de botella que buscas

La mayoría de “incidentes de rotación DKIM” son o:

• Registro DNS faltante o malformado para el nuevo selector.
• Firmador mal configurado (firma aún con el selector antiguo, dominio equivocado, ruta de clave incorrecta, permisos equivocados).
• Firmador no contabilizado (un sistema de una unidad de negocio no recibió el aviso).

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: DKIM falla de repente para todo el correo tras el corte

Causa raíz: Cambiaste la firma al nuevo selector antes de publicar el nuevo registro DNS (o antes de que las cachés lo vieran).

Solución: Publica el registro, verifica vía resolutores públicos y luego espera el TTL o revierte la firma al selector antiguo hasta que DNS sea visible.

2) Síntoma: DKIM pasa a veces, falla a veces

Causa raíz: DNS en estado dividido (respuestas autoritativas múltiples durante la propagación), o algunos receptores golpean un NXDOMAIN en caché.

Solución: Asegura que el proveedor DNS muestre un único registro consistente; confirma que todos los servidores autoritativos sirven el mismo contenido; extiende el solapamiento; evita borrar la clave antigua demasiado pronto.

3) Síntoma: falta completamente la cabecera DKIM

Causa raíz: El milter no está en ejecución, Postfix no está conectado a él, o OpenDKIM no puede leer la clave privada por permisos/SELinux.

Solución: Revisa el estado y logs del servicio; valida smtpd_milters de Postfix; corrige la propiedad de la clave y los contextos SELinux si aplica.

4) Síntoma: DKIM muestra “firma mala” aunque DNS sea correcto

Causa raíz: Algo modifica el mensaje después de firmar (inyección de pie de página, ajuste de líneas, filtros de contenido), o hay desajuste de canonicalization.

Solución: Asegura que la firma DKIM ocurra lo más tarde posible en la canalización; evita modificaciones post-firma; revisa ajustes de canonicalization.

5) Síntoma: DKIM pasa pero DMARC falla

Causa raíz: El dominio d= de DKIM no está alineado con el dominio From (especialmente con alineación estricta).

Solución: Firma con el dominio From, o ajusta la política DMARC con conocimiento. No “arregles” debilitando DMARC salvo que aceptes el coste de seguridad.

6) Síntoma: algunos emisores siguen usando el selector antiguo semanas después

Causa raíz: Un segundo sistema de salida (ESP, SaaS, MTA regional) no fue actualizado.

Solución: Haz inventario de todas las fuentes salientes; busca en reportes agregados DMARC (si los tienes) y en logs; actualiza cada firmador; mantén la clave antigua en DNS hasta que el último se migre.

7) Síntoma: los receptores reportan “clave demasiado corta” o tratan el correo como sospechoso

Causa raíz: Generaste una clave RSA de 1024 bits (o un receptor tiene política en contra).

Solución: Pasa a RSA de 2048 bits; re-publica; vuelve a cortar. Si ya estás rotando, no envíes una clave débil por rapidez.

8) Síntoma: el registro TXT DNS aparece truncado

Causa raíz: Copiar/pegar o la interfaz DNS envolvió e insertó espacios o perdió fragmentos; algunos proveedores requieren convenciones de comillas.

Solución: Reingresa el registro usando el formato multi-cadena correcto del proveedor; valida que el p= devuelto sea contiguo cuando se recupere.

Tres minihistorias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

Rotaron DKIM un jueves por la mañana. El ticket de cambio era ordenado: nueva clave, nuevo selector, actualizar el firmador. El ingeniero hizo la verificación obvia: dig desde su portátil mostraba el nuevo registro TXT. Hicieron el corte. Todo pareció bien durante cinco minutos.

Luego soporte empezó a enviar capturas: “Tu mensaje fue bloqueado”. El correo transaccional a un gran proveedor de buzón de consumidor empezó a aterrizar en spam o fallar DMARC. El on-call vio que DKIM fallaba en ese proveedor, pero pasaba en un buzón de prueba más pequeño. Confuso. El tipo de confusión que te hace perder una hora.

La suposición equivocada fue simple: “Si mi resolutor puede verlo, todos pueden”. Su DNS corporativo estaba configurado para reenviar consultas a un resolutor rápido que ya había recogido el nuevo registro. Sin embargo, el proveedor de buzón mayor golpeaba una ruta de caché diferente y ocasionalmente veía NXDOMAIN para el nuevo selector. No era “propagación lenta” en sentido místico; era comportamiento normal de caché distribuida amplificado por un TTL que había sido 24 horas hasta el día anterior.

La solución no fue heroica. Revirtieron la firma al selector antiguo, dejaron publicado el nuevo selector, esperaron un día completo y volvieron a cortar. La lección: la verificación debe incluir resolutores públicos y comprobaciones autoritativas, no solo “el DNS que usa mi portátil hoy”.

Mini-historia 2: La optimización que salió mal

Otra compañía quería “DNS limpio”. Su equipo de seguridad presionó para eliminar agresivamente claves DKIM antiguas: rotar semanalmente, borrar inmediatamente tras el corte, mantener la zona mínima. Sonaba elegante en una presentación.

Falló de manera aburrida. Su correo saliente incluía sistemas que ponían mensajes en cola por horas (envíos por lotes, notificaciones retrasadas, reintentos por limitación de proveedor). Un subconjunto de mensajes fue firmado con la clave antigua y entregado tarde, después de que se había eliminado el registro DNS del selector antiguo. Los receptores no pudieron validarlos. Algunos proveedores trataron eso como una señal negativa más fuerte que un mensaje sin firma porque parecía manipulación.

No tenían una alerta específica “DKIM falla porque borraste la clave demasiado pronto”. Tenían un panel “entregabilidad caída”, que es el equivalente operacional de una alarma de humo que suena cuando la cocina ya está en llamas.

Revirtieron la política: mantienen selectores antiguos en DNS por semanas, no días. Introdujeron versionado de selectores por trimestre y limitaron la frecuencia de rotación a algo alineado con riesgo real. DNS más “limpio” no mejoró la entregabilidad. Mejoró la vida de nadie.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una org mantenía un hábito que parecía excesivo hasta que no lo fue: tenían un “inventario de autenticación de correo” que listaba cada sistema que envía correo, qué dominio usa en From, qué selector DKIM usa y quién lo administra. No era glamoroso. Lo actualizaban humanos. Era correcto.

Cuando planearon una rotación DKIM para el dominio padre, usaron ese inventario para coordinar el cambio: dos MTAs on-prem, un relé en la nube y una herramienta de ticketing SaaS que firmaba en su nombre con un subdominio delegado. Rotaron cada flujo deliberadamente y mantuvieron las claves antiguas publicadas por un mes.

A mitad de camino descubrieron que un MTA regional aún firmaba con un selector más antiguo. No por incompetencia—porque la región tenía otra ventana de mantenimiento y una tubería de gestión de configuración separada. El inventario lo hizo visible. No borraron el selector antiguo. No pasó nada. Nadie se enteró. Ese es el objetivo.

También tenían un snippet de reversión preescrito en su sistema de gestión de configuraciones: un cambio para revertir el selector y redeployar. Nunca lo usaron. El hecho de que pudieran fue la razón por la que la rotación siguió tranquila.

Preguntas frecuentes

1) ¿Con qué frecuencia debemos rotar las claves DKIM?

Rota con una cadencia que coincida con tu riesgo: comúnmente trimestral a anual. Rota de inmediato si sospechas compromiso de clave, se expuso un firmador o perdiste control de la clave privada.

2) ¿Puedo reutilizar el mismo selector y solo cambiar la clave en DNS?

Puedes, pero no deberías. Los selectores existen para que puedas solapar claves y evitar caos de caché. Reutilizar un selector fuerza un corte duro y complica la resolución de problemas porque el “nombre del selector” deja de implicar “qué versión de clave”.

3) ¿Cuánto tiempo conservo la clave pública DKIM antigua en DNS?

Al menos 7 días después de que dejes de firmar con ella; 30 días es más seguro en entornos empresariales. Si tienes colas largas o envíos por lotes periódicos, mantenla más tiempo. Eliminarla pronto no aporta mucho y puede perjudicar al correo entregado tarde.

4) ¿Qué TTL deberían usar los registros TXT DKIM?

Valores comunes son 300 a 3600 segundos. Para rotación, bajar el TTL un día antes ayuda. Tras la rotación, puedes subirlo modestamente si quieres menos consultas DNS, pero no persigas micro-optimización.

5) ¿Qué tamaño de clave deberíamos usar?

Usa RSA de 2048 bits salvo que tu entorno tenga una alternativa validada y la compatibilidad de receptores esté confirmada. Las claves de 1024 bits son tratadas cada vez más como débiles o inaceptables por política.

6) Si DKIM pasa, ¿seguimos necesitando SPF?

Sí. SPF y DKIM fallan de formas diferentes. DMARC permite que cualquiera (DKIM o SPF alineados) satisfaga la política. Mantener ambos te da resiliencia frente a reenvíos, relés y caminos de envío extraños.

7) ¿Por qué DKIM falla solo para mensajes reenviados?

Los reenviadores a veces modifican el cuerpo o las cabeceras (añadiendo pies, reescribiendo asuntos, alterando límites MIME). Si tocan partes firmadas, la firma se rompe. Las soluciones incluyen minimizar modificaciones después de firmar y usar mecanismos de reenvío compatibles con DMARC cuando sea posible.

8) ¿Podemos rotar sin tiempo de inactividad si usamos un ESP de terceros?

Generalmente sí, pero tus controles son distintos: generas/publicas claves DNS y configuras el uso de selectores en el ESP. La misma regla de solapamiento aplica: publica el nuevo selector primero, verifica y luego cambia. Mantén el selector antiguo publicado después.

9) ¿Cuál es la forma más segura de probar antes de volcar tráfico de producción?

Usa un subdominio dedicado o un subconjunto pequeño de flujos de correo si tu firmador soporta políticas por remitente o dominio. Publica el nuevo selector, firma correo de prueba con él y valida en varios proveedores de buzón importantes.

10) ¿Varias firmas DKIM confunden a los receptores?

No, las firmas múltiples son comunes. Los receptores pueden validar cualquiera o todas. Lo que importa es que al menos una firma DKIM alineada pase para DMARC (dependiendo de la política y modo de alineación).

Conclusión: siguientes pasos que puedes hacer esta semana

Si quieres que la rotación DKIM sea un no-evento, trátala como cualquier otro cambio en producción: planifícala, verifícala externamente, solápala más de lo que tu instinto pide y no borres cosas temprano.

• Escribe tu inventario de emisores: cada sistema, cada dominio From, cada selector DKIM.
• Elige un esquema de selectores que sobreviva a la rotación organizativa (por trimestre o por año está bien).
• Haz una prueba en un subdominio no crítico para validar tu tooling DNS y comportamiento de recarga del firmador.
• Añade dos monitores: (1) “cabecera DKIM presente” en muestras salientes, (2) “tasa de DKIM pass” vía cabeceras de buzones recibidos o telemetría disponible.
• Programa la rotación con solapamiento: publica la nueva clave, verifica en resolutores públicos, luego cambia la firma y mantén la clave antigua publicada por semanas.

Tu objetivo no es demostrar que puedes rotar claves. Tu objetivo es que nadie note que lo hiciste.