Rotación de claves DKIM: runbook operativo (D-7 a D+30)

La rotación de claves DKIM es una operación recurrente y, sin embargo, mal documentada. Las guías de los proveedores (Microsoft, AWS, SendGrid) describen el botón "rotate" sin explicar la ventana de solapamiento, el plazo de propagación DNS ni el procedimiento de rollback. Este runbook cubre ese vacío con un cronograma calendario D-7 a D+30, scripts openssl probados y los errores reportados desde el terreno por equipos que han realizado más de una rotación DKIM en producción.

Para la referencia general, consulte la guía completa DKIM. Aquí, el objetivo es operativo: generar el par, publicar el selector, conmutar la firma, monitorizar DMARC, retirar el selector antiguo. Público objetivo: administradores de sistemas, DevOps, SRE y equipos de infraestructura en producción.

¿Por qué rotar las claves DKIM?

Tres razones operativas justifican la rotación periódica de las claves DKIM.

Compromiso de la clave. Una clave privada DKIM siempre acaba filtrándose: backup sin cifrar, acceso KMS legacy de un exempleado, vertido de un proveedor SaaS. La rotación limita la ventana de explotación de una fuga.

Límite criptográfico. La RFC 8301 dejó obsoletas las claves RSA por debajo de 1024 bits ya en 2018 y recomienda RSA 2048 como mínimo. Una clave RSA 1024 publicada en 2018 hoy es rechazada por Google, Yahoo y Microsoft. Rotar regularmente obliga a reemplazar los algoritmos heredados.

Higiene criptográfica. NIST SP 800-57 Part 1 Rev. 5 recomienda criptoperiodos cortos para las claves de firma: 1 a 2 años máximo, más cortos para entornos sensibles. Sin rotación regular, la primera rotación forzada se convierte en un drama.

DKIM2, en proceso de estandarización en el IETF, añade una protección contra el replay pero no elimina la necesidad de rotación. Véase DKIM2 y la protección contra el replay.

Estrategia: selectores paralelos en lugar de reemplazo directo

Principio fundamental de cualquier rotación de claves DKIM: no reemplazar nunca una clave por overwrite. Publicar siempre un nuevo selector en paralelo, conmutar la firma y luego retirar el selector antiguo tras un periodo de gracia.

Tres factores imponen la coexistencia temporal:

• Caché del resolver DNS. El valor TXT de un selector queda en caché durante el TTL (1 a 24 horas). Algunos resolvers siguen entregando el valor antiguo.
• Reintento SMTP. Un MTA receptor mantiene un mensaje en cola hasta 5 días. Si el selector se retira demasiado pronto, la reverificación falla.
• Auditoría forense. Los equipos de seguridad deben verificar la firma de un mensaje recibido dos semanas antes. Un selector retirado hace imposible esa verificación.

Convención de nombrado: selectores fechados por trimestre. Ejemplo: s2026-q1 para enero a marzo de 2026, s2026-q2 para el siguiente. Esta convención evita colisiones con los selectores de los proveedores (selector1 Microsoft 365, google Google Workspace, mte1 SendGrid). Los dos selectores coexisten durante la ventana de solapamiento:

s2025-q4._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
s2026-q1._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

Duración mínima de solapamiento: 7 días del lado de la propagación, 30 días del lado de la retirada para cubrir los reintentos SMTP más largos.

Calendario operativo de la rotación de claves DKIM

Generar el par con openssl

Cuatro comandos openssl cubren la totalidad de las necesidades. Todos han sido probados con OpenSSL 3.x.

RSA 2048: generación de la clave privada.

openssl genrsa -out dkim_private.pem 2048

RSA 2048: extracción de la clave pública en base64 para el DNS.

openssl rsa -in dkim_private.pem -pubout -outform der | openssl base64 -A

El resultado es el valor a pegar en la etiqueta p= del registro TXT.

Ed25519: generación de la clave privada.

openssl genpkey -algorithm ed25519 -out dkim_ed25519_private.pem

Ed25519: extracción de la clave pública en base64 (32 bytes).

openssl pkey -in dkim_ed25519_private.pem -pubout -outform der | tail -c 32 | openssl base64

El tail -c 32 es necesario: openssl emite una cabecera ASN.1 de 12 bytes antes de los 32 bytes efectivos de la clave Ed25519, cabecera que la RFC 8463 exige retirar para p=.

Tabla comparativa de las tres opciones realistas en 2026:

Recomendación 2026: RSA 2048 solo para la máxima compatibilidad, o double-publish RSA 2048 más Ed25519 para beneficiarse de la firma Ed25519 en los receptores compatibles. Evitar RSA 4096: la clave pública supera los 255 caracteres y obliga a una división TXT en varias cadenas, frágil en cada edición DNS. Para el detalle comparativo, véase RSA frente a Ed25519 para DKIM.

Gestión de la clave privada

La clave privada DKIM es un secreto criptográfico al mismo nivel que una clave TLS. Existen tres modelos de almacenamiento aceptables en producción.

KMS gestionado (AWS KMS asymmetric keys, GCP Cloud KMS, Azure Key Vault). La clave se genera y permanece en el HSM. El MTA invoca la API KMS para firmar cada mensaje. La clave privada nunca queda expuesta en memoria aplicativa, la rotación queda trazada por IAM. Inconveniente: 5 a 20 ms de latencia por llamada.

HashiCorp Vault Transit. Equivalente self-hosted del KMS gestionado. La clave permanece en el backend Transit, el MTA firma a través de la API. Ruta convencional: secret/dkim/captaindns/s2026-q1.

Archivo PEM cifrado en reposo. Mínimo aceptable para las infraestructuras pequeñas. La clave se almacena en el servidor de envío en un volumen cifrado (LUKS, encrypted EBS), permisos 0600, propietario opendkim:opendkim. Despliegue mediante Ansible Vault, Sealed Secrets de Kubernetes o SOPS.

Anti-patrones que deben evitarse:

• Clave privada commiteada en el repositorio Git, incluso en rama privada. Git conserva el historial para siempre.
• Clave privada pasada como variable de entorno sin cifrar (DKIM_PRIVATE_KEY=...) en un docker-compose o un archivo .env.
• Clave privada almacenada en un secret manager compartido con cuentas de servicio innecesarias (principio de mínimo privilegio violado).

En el momento de la rotación, no olvide rotar también los accesos KMS. Un exempleado que haya tenido acceso de lectura a secret/dkim/captaindns/s2025-q4 no debe conservar ese acceso aunque la clave ya no esté activa: sigue siendo válida para firmar mensajes antedatados.

Automatizar la rotación de claves DKIM mediante cron

Una rotación manual se olvida en la primera ausencia del equipo. Por consiguiente, la automatización es indispensable a partir de 3 o 4 dominios activos. Dividir el job en 3 pasos idempotentes:

1. Generate: producir el par y almacenar la clave privada en KMS.
2. Publish-DNS: invocar la API del proveedor DNS para añadir el TXT.
3. Switch-signing: reconfigurar el MTA tras la ventana D-7.

Esqueleto bash Generate + Publish-DNS en Cloudflare:

#!/bin/bash
set -euo pipefail

SELECTOR="s$(date +%Y-q%q)"
DOMAIN="captaindns.com"
ZONE_ID="${CLOUDFLARE_ZONE_ID}"

# Generate RSA 2048
openssl genrsa -out "dkim_${SELECTOR}.pem" 2048
PUB=$(openssl rsa -in "dkim_${SELECTOR}.pem" -pubout -outform der | openssl base64 -A)

# Store private key in Vault
vault kv put "secret/dkim/${DOMAIN}/${SELECTOR}" private_key=@"dkim_${SELECTOR}.pem"

# Publish DNS via Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"TXT\",\"name\":\"${SELECTOR}._domainkey\",\"content\":\"v=DKIM1; k=rsa; p=${PUB}\",\"ttl\":3600}"

# Verify publication
sleep 30
dig +short TXT "${SELECTOR}._domainkey.${DOMAIN}"

Cron: 0 3 1 */6 * (cada 6 meses, el primer día del mes a las 3h UTC) dispara la fase Generate más Publish-DNS, seguida 7 días después de un segundo cron que ejecuta Switch-signing.

Integraciones con proveedores:

• AWS SES BYODKIM: comando aws sesv2 put-email-identity-dkim-signing-attributes con el par DomainSigningSelector y DomainSigningPrivateKey codificado en base64.
• Microsoft 365: Rotate-DkimSigningConfig -Identity captaindns.com -KeySize 2048 (Exchange Online PowerShell). La rotación genera un nuevo selector del lado de Microsoft pero obliga a publicar el nuevo CNAME en el DNS para activar la nueva clave.
• SendGrid: la rotación se gestiona a través de la API POST /whitelabel/domains/{id}/validate después de añadir el nuevo CNAME en el proveedor DNS.

Alerta recomendada: lanzar una alerta si la tasa dkim=fail en los informes DMARC aggregate supera el 1 % durante la ventana D+0 a D+7. La validación posterior a la rotación se ejecuta de forma programática mediante la API DKIM Record Check.

Errores frecuentes durante la rotación de claves DKIM

Cinco errores recurrentes en la rotación de claves DKIM aparecen en los tickets de soporte y en los hilos reddit r/sysadmin.

TTL demasiado largo en el selector antiguo. Un TTL de 24 horas impide la propagación rápida de una corrección. Reduzca el TTL a 300 segundos 48 horas antes de D+0, luego elévelo a 3600 segundos tras D+7.

Selector con guiones mal colocados. Algunos parsers DKIM estrictos rechazan un selector que contenga un guion en primera o última posición. Prefiera s2026q1 a -s2026-q1-.

DMARC en alineamiento estricto (adkim=s). Una firma d=mail.captaindns.com es rechazada para un From: contact@captaindns.com. Verifique que el dominio d= de la nueva clave siga siendo idéntico al de la antigua.

Clave pública oculta del lado SaaS. Mailchimp, ActiveCampaign y otros publican un CNAME en lugar de un TXT directo. La rotación la gestiona el proveedor: valide que el CNAME apunta al nuevo destino tras la rotación declarada.

Etiqueta s= mal configurada. La etiqueta opcional s=email restringe el uso de la clave a la firma de mensajes de correo. Una clave publicada con s=* o sin etiqueta acepta todos los servicios. Para el detalle, véase la etiqueta s= en el registro DKIM.

Ejemplo de TXT mal codificado (wrap base64 multilínea con salto de línea en bruto, rechazado por algunos resolvers):

s2026-q1._domainkey.captaindns.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
                                                "p=MIIBIjANBgkqhkiG\n"
                                                "9w0BAQEFAAOC..." )

Ejemplo correcto (cadena única o división limpia en fragmentos de 255 caracteres):

s2026-q1._domainkey.captaindns.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

FAQ

Valide su próxima rotación de claves DKIM: utilice el DKIM Record Check para verificar que su nuevo selector está publicado y firmado correctamente antes y después del cambio. Para anticipar las evoluciones del protocolo, véase también DKIM2 y la protección contra el replay.

Fuentes

• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301 - Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463 - A New Cryptographic Signature Method for DKIM (Ed25519)
• NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management
• Microsoft Learn - Rotate-DkimSigningConfig