Descubrir que su clave privada DKIM puede haber sido expuesta es un evento de seguridad grave. A diferencia de una contraseña comprometida, una clave DKIM filtrada puede usarse de forma silenciosa: un atacante puede firmar correos electrónicos fraudulentos que superan la verificación DKIM y potencialmente satisfacen DMARC, haciendo que las campañas de phishing contra sus clientes y socios sean mucho más convincentes. La buena noticia: puede responder de forma rápida y eficaz. Esta guía le explica cada paso, desde la generación de un par de claves de reemplazo hasta la verificación de la corrección y el refuerzo de su configuración contra futuras exposiciones.

Cómo se compromete una clave DKIM

DKIM se basa en criptografía asimétrica. Su servidor de correo posee una clave privada que utiliza para firmar los mensajes salientes. La clave pública correspondiente se publica en DNS como un registro TXT bajo un subdominio selector (por ejemplo, selector1._domainkey.example.com). Los servidores receptores obtienen la clave pública y verifican la firma; si es correcta, DKIM pasa.

La clave privada debe permanecer secreta. Las formas más comunes en que queda expuesta incluyen:

  • Brecha en el servidor. Un atacante obtiene acceso a su servidor de correo o al sistema de archivos donde se almacenan los archivos de clave privada. Los archivos de clave se encuentran a menudo en ubicaciones predecibles, como /etc/opendkim/keys/ o en los directorios de configuración del servidor de correo.
  • Archivos de configuración filtrados. Las claves privadas incrustadas en archivos de configuración —o comprometidas accidentalmente en un repositorio de control de versiones— quedan accesibles de forma permanente una vez que el historial del repositorio queda expuesto.
  • Entornos de alojamiento compartido. En el hosting compartido, los controles inadecuados de permisos del sistema de archivos pueden permitir que otros inquilinos lean sus materiales de clave.
  • Copias de seguridad antiguas. Los archivos de copia de seguridad que incluyen la configuración del servidor de correo son una fuente frecuente pero poco considerada de filtración de claves, especialmente cuando las copias se almacenan en ubicaciones menos seguras, como cubos en la nube sin cifrar.
  • Cuentas de ESP comprometidas. Los proveedores de servicios de correo electrónico gestionan las claves DKIM en su nombre. Si su cuenta de ESP es tomada, un atacante puede recuperar o rotar las claves por otras que él controle.

Una vez que un atacante tiene su clave privada, puede producir firmas DKIM válidas en cualquier correo electrónico que elabore. Esos mensajes superarán las comprobaciones DKIM en los servidores receptores y, si el dominio firmante se alinea con su encabezado Header-From, también satisfarán DMARC, incluso si tiene una política reject. Desde el exterior, esos correos fraudulentos parecen completamente legítimos.

Pasos inmediatos: no entre en pánico, pero actúe con rapidez

Una clave DKIM comprometida es grave, pero tiene solución completa. El proceso de respuesta tiene una secuencia clara: generar un nuevo par de claves, publicar la nueva clave pública en DNS, actualizar su servidor de correo para firmar con la nueva clave y, a continuación, revocar la clave anterior invalidando su registro DNS. Todo el proceso puede completarse en menos de una hora para la mayoría de las configuraciones; la principal variable es el tiempo de propagación de DNS.

No elimine simplemente el registro DNS antiguo como primera acción. Si elimina la clave pública antigua antes de que su servidor de correo haya cambiado a la nueva clave de firma, cualquier mensaje en tránsito firmado con la clave antigua fallará inmediatamente en la verificación DKIM. Siga los pasos a continuación en el orden indicado.

Paso 1: Genere un nuevo par de claves DKIM

Comience generando un nuevo par de claves RSA con un tamaño mínimo de 2048 bits. Las claves de 512 bits y 1024 bits se consideran débiles y muchos servidores receptores las rechazan directamente. Elija un nuevo nombre de selector; usar una convención basada en la fecha, como 20260415, facilita el seguimiento del historial de rotaciones.

En un servidor que ejecuta OpenDKIM, puede generar el par de claves con:

opendkim-genkey -b 2048 -d example.com -s 20260415

Esto produce dos archivos: 20260415.private (la nueva clave privada) y 20260415.txt (el registro TXT de DNS a publicar). Almacene el archivo de clave privada con permisos estrictos del sistema de archivos; legible únicamente por el proceso del servidor de correo, nunca con lectura pública.

Si usa un proveedor de servicios de correo electrónico como Google Workspace, Microsoft 365, Mailchimp o SendGrid, el paso de generación de claves se realiza en el panel de administración del ESP, no en su propio servidor. Busque una sección de configuración de DKIM o autenticación de dominio y genere una nueva clave allí. El ESP le proporcionará el valor del registro TXT de DNS a publicar.

Paso 2: Publique la nueva clave pública en DNS

Cree un nuevo registro TXT de DNS en el subdominio selector para su nueva clave. El formato del registro es:

20260415._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=<base64-encoded-public-key>"

Reemplace 20260415 con el nombre de selector que haya elegido y example.com con su dominio. El valor de p= es la clave pública codificada en Base64, que se incluye en el archivo .txt generado por opendkim-genkey o proporcionado por su ESP.

Establezca el TTL de este registro en un valor bajo: se recomiendan 300 segundos (5 minutos) durante la rotación activa de claves. Un TTL corto garantiza que los cambios se propaguen rápidamente. Puede volver a aumentarlo a un valor más alto (3600 o más) una vez que la rotación esté completa y sea estable.

No toque todavía el registro DNS del selector antiguo. Debe permanecer válido hasta que haya confirmado que su servidor de correo utiliza completamente la nueva clave.

Paso 3: Actualice su servidor de correo para firmar con la nueva clave

Una vez que el nuevo registro DNS esté activo y propagándose, actualice la configuración de su servidor de correo para firmar los mensajes salientes con la nueva clave privada y el nuevo selector. En OpenDKIM, esto significa actualizar la tabla de claves y la tabla de firmas para hacer referencia al nuevo selector y archivo de clave, y luego recargar el servicio:

systemctl reload opendkim

Para DKIM gestionado por ESP, este paso generalmente se completa activando o habilitando la nueva clave en el panel de control; el ESP comenzará a firmar con la nueva clave inmediatamente después de la activación.

Envíe un mensaje de prueba (a una dirección de Gmail funciona bien) e inspeccione los encabezados del mensaje sin procesar para confirmar que el encabezado DKIM-Signature referencia su nuevo selector. Busque s=20260415 (o el nombre del selector que haya elegido) en el encabezado de firma.

Paso 4: Revoque la clave antigua

Una vez que haya confirmado que su servidor de correo firma con la nueva clave, invalide el registro DNS del selector antiguo. La forma correcta de revocar una clave DKIM no es eliminar el registro DNS por completo; en cambio, actualice el registro para usar un valor de clave pública vacío:

old-selector._domainkey.example.com  IN  TXT  "v=DKIM1; p="

Establecer p= en una cadena vacía es el mecanismo de revocación estándar definido en RFC 6376. Indica a los servidores receptores que la clave ha sido revocada y que cualquier mensaje firmado con ella debe tratarse como si no tuviera una firma DKIM válida. Esto es preferible a la eliminación total porque algunos resolvedores DNS almacenan en caché las respuestas negativas y pueden no volver a comprobar un registro eliminado de forma inmediata.

Espere a que el TTL del selector antiguo expire antes de continuar. Si el registro antiguo tenía un TTL de 3600 segundos, espere al menos una hora después de publicar el registro de revocación antes de considerar que las copias en caché están totalmente obsoletas. Después de eso, puede dejar el registro revocado en su lugar indefinidamente o eliminarlo por completo; cualquiera de las dos opciones es segura una vez que el TTL ha expirado.

Paso 5: Verifique la rotación

Verifique que la nueva clave está correctamente publicada y la clave antigua revocada usando dig:

# Check the new selector
dig TXT 20260415._domainkey.example.com +short

# Check the old selector (should return p= with empty value)
dig TXT old-selector._domainkey.example.com +short

También puede usar el verificador DKIM de DMARCFlow para validar su nuevo selector desde fuera de su red. Introduzca su dominio y el nuevo nombre de selector para confirmar que la clave pública tiene el formato correcto, que el registro es sintácticamente válido y que la longitud de la clave cumple el mínimo de 2048 bits. El verificador señalará cualquier problema con la estructura del registro antes de que afecte a su flujo de correo.

Verifique su configuración DKIM de forma gratuita
Compruebe que su nuevo selector está correctamente publicado y que su clave cumple los estándares de seguridad actuales, en segundos.
Verificar su DKIM

Paso 6: Supervise los informes DMARC

En los días posteriores a una rotación de claves, observe atentamente sus informes agregados DMARC. Un aumento en los fallos DKIM inmediatamente después de la rotación es una señal de que alguna ruta de envío sigue utilizando la clave antigua; por ejemplo, un servidor de correo secundario o una integración de ESP que no se actualizó. Los informes DMARC le muestran exactamente qué direcciones IP fuente están produciendo fallos DKIM y qué selector están usando, lo que facilita la identificación de cualquier rezagado.

Si todavía no recibe ni revisa informes DMARC, DMARCFlow analiza sus informes agregados automáticamente y muestra los patrones de fallo DKIM con desglose por fuente. Tras una rotación, querrá ver que las tasas de aprobación DKIM vuelven a su nivel previo al incidente en un plazo de 24–48 horas. Si no lo hacen, los datos del informe le mostrarán con precisión de dónde provienen los fallos restantes.

Compruebe también si la clave comprometida fue usada activamente de forma maliciosa. Si un atacante usó la antigua clave privada para firmar mensajes fraudulentos antes de que usted la revocara, esos mensajes aparecerán en los informes DMARC como aprobaciones de DKIM desde su dominio pero provenientes de direcciones IP que usted no reconoce. Documente cualquier actividad de este tipo y considere notificar a las partes afectadas.

Prevención de futuras vulneraciones de claves

Una respuesta reactiva es necesaria, pero el objetivo es evitar que el escenario se repita. Las siguientes prácticas reducen significativamente su exposición:

  • Restrinja los permisos de los archivos de clave privada. Los archivos de clave deben ser legibles únicamente por la cuenta de usuario que ejecuta el daemon de su servidor de correo (por ejemplo, el usuario opendkim). El modo 600 o 640 con la propiedad correcta es el mínimo. Nunca establezca archivos de clave como legibles públicamente.
  • Nunca comprometa claves privadas en el control de versiones. Añada patrones de archivos de clave a su .gitignore. Analice los repositorios existentes en busca de secretos comprometidos accidentalmente usando herramientas como truffleHog o git-secrets. Si una clave ha sido comprometida, trátela como vulnerada independientemente de si el repositorio es privado.
  • Use claves de 2048 bits como mínimo. RFC 8301 depreca las claves inferiores a 1024 bits, pero 2048 bits es el mínimo práctico para una seguridad significativa. Considere claves de 4096 bits para selectores de larga duración, aceptando el ligero aumento en el tamaño del registro DNS y el costo de CPU en la verificación.
  • Establezca un calendario de rotación regular. Incluso sin una vulneración sospechada, rotar las claves DKIM con una cadencia regular —cada 6 a 12 meses— limita la ventana de exposición ante cualquier vulneración pasada no detectada. Use selectores con marca de fecha para hacer visible el historial de rotaciones.
  • Almacene las copias de seguridad de forma segura y separada. Cifre los archivos de copia de seguridad que contengan la configuración del servidor de correo. Almacénelos en ubicaciones con control de acceso, separadas del servidor de producción. Rote las claves después de restaurar desde una copia de seguridad si la antigüedad o procedencia de esta es incierta.
  • Supervise el acceso a la cuenta del ESP. Si sus claves DKIM son gestionadas por un ESP, habilite la autenticación multifactor en esa cuenta y revise los registros de acceso periódicamente. Una toma de control de la cuenta puede ser tan dañina como una brecha en el servidor desde el punto de vista de la seguridad DKIM.
  • Revise los informes DMARC de forma continua. Aprobaciones DKIM inesperadas provenientes de direcciones IP desconocidas en sus informes DMARC pueden indicar que se está usando una clave comprometida, incluso antes de que usted sea consciente de la brecha. La revisión regular le proporciona una advertencia temprana.