¿Qué es DKIM? DomainKeys Identified Mail explicado (guía 2026)

DKIM (DomainKeys Identified Mail) es un estándar de autenticación de correo, definido en el RFC 6376, que adjunta una firma criptográfica a cada mensaje que envía tu dominio. El servidor receptor consulta tu clave pública en el DNS, recalcula la firma sobre el cuerpo del mensaje y una serie de cabeceras seleccionadas, y confirma dos cosas: que el correo salió realmente de tu dominio y que nadie lo modificó por el camino. Si envías correo desde tu propio dominio, DKIM ya no es opcional. Google y Yahoo lo exigen a los remitentes masivos desde febrero de 2024, y Microsoft empezó a rechazar el correo de alto volumen que no cumple los requisitos hacia Outlook.com, Hotmail.com y Live.com el 5 de mayo de 2025 (blog de Microsoft Defender for Office 365).

Cómo funciona DKIM realmente

DKIM es un esquema de firma de clave pública montado sobre SMTP. El flujo tiene cuatro pasos:

1. Generas un par de claves. La clave privada se queda en tu servidor de salida o en manos de tu proveedor de correo. La clave pública se publica en el DNS.
2. Tu servidor firma el correo saliente. Calcula el hash del cuerpo del mensaje más una lista elegida de cabeceras (From, Subject, Date y otras), firma ese hash con la clave privada e inserta el resultado como cabecera DKIM-Signature:.
3. El receptor obtiene tu clave pública. Lee el dominio (d=) y el selector (s=) de la cabecera de firma y consulta un registro TXT en <selector>._domainkey.<dominio>.
4. El receptor verifica. Recalcula el hash y lo compara con la firma. Si coinciden, las partes firmadas del mensaje son auténticas y no han sido modificadas.

Una diferencia clave: DKIM sobrevive al reenvío, cosa que SPF no hace. SPF valida la dirección IP que conecta, así que se rompe en cuanto una lista de correo o un reenviador retransmite tu mensaje. La firma DKIM viaja con el propio mensaje, por lo que la alineación DKIM suele ser la mitad más duradera de una política DMARC.

Anatomía de un registro DKIM

Un registro DKIM publicado es un registro TXT del DNS en un nombre de host específico del selector. Este es un ejemplo recortado para el selector s1 en example.com, publicado en s1._domainkey.example.com:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Las etiquetas que encontrarás con más frecuencia:

Hay un detalle que hace tropezar a casi todo el mundo: una clave pública RSA de 2048 bits supera el límite de 255 bytes de una sola cadena de caracteres en DNS, así que debe publicarse como varias cadenas entrecomilladas que el resolutor concatena. Algunos paneles de DNS lo hacen solos y otros no, y una clave mal troceada falla la verificación sin ningún error visible.

Cómo configurar DKIM en cinco pasos

1. Genera un par de claves RSA de 2048 bits, o deja que lo haga tu proveedor. Google Workspace, Microsoft 365, Zoho, Mailgun, SendGrid, Postmark y Amazon SES emiten claves desde sus consolas de administración.
2. Elige un selector descriptivo. Usa uno por cada origen de envío, por ejemplo google1 o mg-2026a. Nunca reutilices un selector entre dos sistemas.
3. Publica el registro TXT en <selector>._domainkey.<tudominio>. Espera a la propagación, que suele tardar minutos pero puede llegar al TTL de la zona.
4. Activa la firma en la plataforma de envío. Publicar la clave sin activar la firma es el despliegue DKIM a medias más frecuente.
5. Verifica. Consulta el registro desde una terminal con dig TXT s1._domainkey.example.com +short, después envía un mensaje de prueba a un buzón propio y lee la cabecera Authentication-Results:. Quieres ver dkim=pass.

Repite esto en cada sistema que envíe como tu dominio: el servidor de correo, la plataforma de marketing, la herramienta de facturación, el sistema de soporte. Cada uno necesita su propio selector y su propia clave.

DKIM frente a SPF y DMARC

Los tres estándares se complementan, no se sustituyen. DKIM demuestra integridad, SPF autoriza la ruta de envío y DMARC vincula cualquiera de los dos resultados con la dirección From visible e indica al receptor qué hacer si fallan.

DKIM sigue siendo el menos desplegado de los tres. Un rastreo de 5,5 millones de dominios en febrero de 2026 situó SPF en el 56,0 %, DMARC en el 30,4 % y DKIM en el 22,7 % (estudio de DMARCguard). Los autores advierten de que DKIM está probablemente infravalorado, porque un escáner solo puede sondear selectores comunes y no descubre los personalizados.

Longitud de clave, rotación y el problema del replay

Usa RSA de 2048 bits. El RFC 8301 dejó obsoletas las claves de firma por debajo de 1024 bits, y el NIST SP 800-57 considera 2048 bits el mínimo actual para RSA. Las claves de 1024 bits todavía se verifican en la mayoría de receptores, pero tienen los días contados. Subir a 4096 bits aporta poco y complica la publicación en DNS.

Rota con un calendario. El RFC 6376 recomienda la rotación periódica sin fijar un intervalo; las buenas prácticas de M3AAWG y la mayoría de operadores se sitúan entre 6 y 12 meses, o trimestralmente en entornos regulados. La rotación es segura si respetas el orden: publica el nuevo selector, firma con la clave nueva mientras el registro antiguo sigue activo, confirma los resultados correctos en tus informes agregados DMARC y solo entonces elimina el registro viejo.

Entiende el replay de DKIM. En abril de 2025 una campaña de phishing aprovechó un mensaje legítimamente firmado por Google y lo reenvió literalmente a nuevas víctimas, de modo que llegaba con un dkim=pass válido de google.com (análisis de Red Sift). Nada de la firma estaba falsificado. El ataque funciona porque una firma DKIM no dice nada sobre quién envió el mensaje ni a quién. Dos mitigaciones prácticas: sobrefirmar las cabeceras importantes listándolas en la etiqueta h= más veces de las que aparecen, lo que impide que un atacante añada un segundo To: o Subject:, y fijar una caducidad corta con la etiqueta x= para reducir la ventana de replay.

Fallos habituales de DKIM y sus causas

Preguntas frecuentes

¿DKIM cifra mi correo? No. DKIM firma, no cifra. Quien intercepte el mensaje todavía puede leerlo. El cifrado en tránsito es TLS y el cifrado del contenido es S/MIME o PGP.

¿Puedo tener más de un registro DKIM? Sí, y normalmente deberías. Cada selector es un registro independiente, así que un dominio puede alojar una clave por cada plataforma de envío que uses.

¿DKIM por sí solo detiene la suplantación? No. Una firma válida demuestra que algún dominio firmó el mensaje, pero el receptor solo actúa si una política DMARC se lo indica. DKIM más DMARC en p=quarantine o p=reject es lo que realmente bloquea el correo suplantado.

¿Qué pasa si borro una clave DKIM? Cualquier mensaje aún en tránsito firmado con ella fallará la verificación. Para revocar de forma deliberada, publica el registro con un p= vacío en lugar de borrarlo, para que los receptores vean una revocación explícita.

¿Ed25519 está listo para usarse? La firma Ed25519 está estandarizada en el RFC 8463 y produce registros DNS mucho más cortos, pero el soporte de los verificadores todavía es desigual. Firma en paralelo con RSA-2048 en lugar de cambiar de golpe.

Guías relacionadas

• Cómo configurar DMARC paso a paso
• Verificador de registros SPF: cómo probar, leer y corregir tu SPF
• Seguridad DNS: SPF, DMARC, DNSSEC y CAA explicados

Comprueba tu DKIM en 60 segundos

La mayoría de configuraciones DKIM rotas parecen correctas desde la consola de administración y solo se delatan en las cabeceras del correo entregado. El escaneo gratuito de FortifyNet lee tu DNS en vivo e informa de SPF, DKIM y DMARC en conjunto, junto a tu configuración SSL/TLS, tus cabeceras de seguridad y tu exposición en la dark web. Sin registro. Escanea tu dominio gratis y comprueba qué ven realmente los receptores.