El Grupo de Trabajo DKIM del IETF publicó una nueva versión de la especificación DKIM2 el 17 de mayo de 2026. Se trata de la tercera revisión del documento del grupo de trabajo, lo que supone un avance constante hacia la futura publicación de un RFC. Para quienes han seguido el desarrollo de DKIM2 desde los primeros borradores, esta es la señal más clara hasta la fecha de que el grupo de trabajo está a punto de presentar un producto listo para su uso real.
¿Necesitas repasar el tema antes de seguir leyendo? Echa un vistazo a nuestra guía detallada sobre «¿Qué es DKIM2?» para conocer los fundamentos.
Novedades de esta actualización
La nueva versión se llama draft-ietf-dkim-dkim2-spec-02. Ha sido redactada por Richard Clayton (Yahoo), Wei Chuang (Google) y Bron Gondwana (Fastmail), el mismo equipo que ha trabajado en el documento desde el principio. El primer borrador oficial del grupo de trabajo de la IETF fue el draft-ietf-dkim-dkim2-spec-00, publicado el 24 de marzo de 2026, que sustituyó al borrador individual anterior (draft-clayton-dkim2-spec). Desde entonces, el documento ha pasado por las revisiones -01 en abril y -02 en mayo, y la especificación ha sido elaborada por el grupo de trabajo en su conjunto, en lugar de solo por sus autores originales.
La revisión del 17 de mayo es una actualización incremental que sigue perfeccionando los detalles técnicos de la especificación. Los cambios más destacados son:
- Encabezados «Authentication-Results» excluidos de la firma: estos encabezados suelen cambiar a medida que el correo atraviesa los límites del sistema, por lo que excluirlos de la firma evita errores de verificación innecesarios.
- Normas más claras para los indicadores «donotmodify» y «donotexplode»: los remitentes pueden indicar con mayor firmeza que un mensaje no debe modificarse ni enviarse a varios destinatarios, y los verificadores disponen ahora de comprobaciones explícitas y mensajes de error cuando se ignoran dichas solicitudes.
- Se ha eliminado la receta «z body»: aunque se incluyó inicialmente para los mensajes de rebote truncados, en la práctica resultó que no era necesaria. Su eliminación simplifica la especificación sin perder funcionalidad.
- Normas técnicas más estrictas: las aclaraciones sobre el relleno en Base64, los separadores de punto y coma en los campos de encabezado y el formato JSON reducen la ambigüedad y facilitan la creación de implementaciones compatibles.
Los lectores que sigan de cerca el desarrollo de la especificación pueden comparar las versiones directamente a través del IETF Datatracker.
Los dos problemas que resuelve DKIM2

Esta revisión se ha llevado a cabo debido a dos problemas que venían de lejos con DKIM1.
El primero es el ataque de reenvío DKIM. En este caso, un atacante toma un mensaje legítimo firmado y lo reenvía a otros buzones de correo, aprovechándose de la buena reputación del dominio original. DKIM2 soluciona esto registrando los datos del destinatario dentro del contenido firmado y creando una cadena de custodia a lo largo de cada paso que da el mensaje. Los mensajes reenviados ya no parecen reales para un verificador.
El segundo problema son las firmas dañadas durante el reenvío. Las listas de correo y los servidores de reenvío suelen modificar los encabezados o el contenido del cuerpo de tal forma que se daña la firma DKIM original. Por eso, los mensajes enviados a través de herramientas como Mailman suelen fallar en las comprobaciones DMARC del dominio del remitente. DKIM2 gestiona esto de forma nativa. Cada sistema que procesa el mensaje registra sus cambios y añade su propia firma a la cadena. De este modo, los verificadores pueden rastrear el mensaje hasta el remitente original sin que se rompa la cadena.
Para obtener más información sobre el problema del reenvío, consulta nuestro artículo sobre DMARC y las listas de correo.
ARC va a dejar de utilizarse
La corrección del reenvío también explica una actualización relacionada que conviene conocer. El 22 de abril de 2026, Trent Adams (Proofpoint) y John Levine (Taughannock Networks) presentaron draft-ietf-dmarc-arc-to-historic-00 al Grupo de Trabajo DMARC del IETF. En él se propone que la Cadena de Recepción Autenticada (ARC) se reclasifique como estándar histórico.
La razón que se aduce en el borrador para poner fin al experimento ARC es que la experiencia operativa adquirida con ARC se está incorporando al proyecto DKIM2 propuesto como sucesor de DKIM. En otras palabras, las lecciones aprendidas con ARC no se están descartando, sino que se están integrando en una solución más depurada.
Si quieres saber más sobre ARC y para qué sirve, puedes consultar nuestra guía «¿Qué es ARC?».
Lo que deben hacer ahora mismo los propietarios de dominios

Para la mayoría de los remitentes, la respuesta es: nada urgente.
Las claves DKIM2 utilizan la misma estructura de registros DNS que las claves DKIM actuales, por lo que tu configuración DNS actual seguirá siendo válida. La especificación prevé un largo periodo en el que DKIM1 y DKIM2 funcionarán en paralelo, por lo que no habrá un cambio obligatorio. Se espera que las primeras implementaciones en los principales proveedores de correo electrónico tengan lugar a finales de 2026, y que el despliegue generalizado continúe en 2027 y años posteriores.
Lo importante ahora es asegurarse de que tu configuración actual de DKIM esté en buen estado. Esto implica que las claves estén correctamente publicadas, que la rotación sea adecuada y que no queden selectores obsoletos. Cualquier problema que tengas hoy te acompañará en la era de DKIM2. Si necesitas repasar los conceptos básicos, empieza por aprender qué es DKIM.
Si prefieres no tener que gestionar tú mismo las claves de firma cuando se produzca el cambio, el servicio DKIM alojado de PowerDMARC se encarga de la publicación, la rotación y la supervisión, para que estés listo cuando se implemente DKIM2.
- Actualización de la especificación DKIM2: novedades del borrador de la IETF de mayo de 2026 - 25 de mayo de 2026
- ¿Es suficiente Windows Defender para la seguridad de las pequeñas empresas? - 14 de mayo de 2026
- DMARCbis explicado: qué va a cambiar y cómo prepararse - 16 de abril de 2026


