El 22 de abril de 2026, el grupo de trabajo DMARC del IETF publicó draft-ietf-dmarc-arc-to-historic-00, solicitando la reclasificación del RFC 8617 como estándar Histórico. El grupo de trabajo había recibido un nuevo mandato apenas unos días antes, el 16 de abril de 2026, con la misión específica de producir un documento de cambio de estado para ARC antes de noviembre de 2026.
El experimento que fue ARC ha terminado, en el lenguaje formal del IETF.
Eso importa a cualquier organización que ejecute una política DMARC en p=quarantine o p=reject. ARC era el mecanismo que se suponía debía evitar que el correo reenviado legítimo fallara al encontrarse con tu política de aplicación. Entender qué se está retirando, por qué no funcionó y qué viene a continuación te dice exactamente lo que necesitas hacer hoy.
Qué Problema Resolvía ARC
DMARC tiene un problema estructural conocido con el correo que pasa a través de intermediarios.
Considera un mensaje que un cliente envía desde Gmail a una lista de correo. El servidor administrador de la lista recibe el mensaje original, añade una cabecera de lista, modifica el pie de página y lo reenvía a todos los suscriptores. Cuando ese mensaje llega al buzón de un suscriptor, han ocurrido dos cosas:
- SPF se ha roto. El remitente original del sobre pasó SPF, pero la lista de correo ahora está enviando desde su propia IP, que no está en tu registro SPF.
- DKIM puede haberse roto. Si el administrador de la lista modifica el cuerpo del mensaje o ciertas cabeceras, la firma DKIM sobre esas partes ya no es válida.
Una política DMARC de p=reject comprueba la alineación SPF y la alineación DKIM. Si ambas fallan, falla DMARC. El servidor receptor está ahora en la posición de rechazar un mensaje que era completamente legítimo cuando entró en la cadena de correo.
El reenvío de correo (el que configura un usuario para redirigir correo de una dirección a otra) crea el mismo problema. El servidor de reenvío no está en tu registro SPF, puede modificar el mensaje, y el resultado es un fallo DMARC en el destino final.
ARC, Authenticated Received Chain (RFC 8617, publicado en julio de 2019), fue la solución propuesta. Cada servidor intermediario que tocaba el mensaje añadía tres cabeceras: ARC-Authentication-Results, ARC-Message-Signature y ARC-Seal. Juntas creaban un registro criptográficamente verificable del estado de autenticación del mensaje en cada salto. Un receptor al final de la cadena podía leer las cabeceras ARC, decidir si confiar en la firma del intermediario y aplicar esa confianza para anular el aparente fallo DMARC.
Gmail lo adoptó. Microsoft lo adoptó. Un puñado de grandes proveedores siguieron su ejemplo. La teoría era sólida.
Por Qué Falló el Experimento
La conclusión del IETF, documentada en el borrador, es directa: ARC no ha logrado “ni adopción notable ni impacto suficiente” a pesar de años de desarrollo.
El problema central fue el modelo de confianza. Para que ARC funcione, un receptor al final de la cadena tiene que decidir si respetar los sellos ARC dejados por el intermediario. Esa decisión requiere confiar en el intermediario. Pero el IETF nunca logró establecer consenso sobre en qué firmas ARC se debería confiar a nivel de internet.
No existe un registro de confianza ARC. No existe un mecanismo globalmente aceptado para que un receptor determine si un servidor de lista de correo que nunca ha visto antes opera legítimamente. Sin eso, la decisión de confianza queda relegada a una política específica de cada receptor: Google confía en ciertos intermediarios que ha identificado; Microsoft confía en su propio conjunto. Los sellos dejados por un servidor de lista de correo más pequeño o menos conocido pueden ser o no respetados, dependiendo enteramente de dónde esté el buzón del destinatario final.
En la práctica, esto significaba que los operadores de listas de correo publicaban sellos ARC, los propietarios de dominios dependían de ellos y la protección era parcial, inconsistente e invisible para ambas partes. El borrador es explícito: ARC no debe “ser desplegado ni utilizado entre remitentes y receptores dispares”.
Los grandes proveedores que ya procesan cadenas ARC, específicamente Gmail y Microsoft 365, continuarán haciéndolo para las cadenas en las que confían. El IETF no los obliga a eliminar el código existente. Pero la orientación para los implementadores es dejar de añadir nueva dependencia en ARC, y para los nuevos intermediarios, no desplegarlo en absoluto.
Qué Cambia DKIM2
La lección de ARC está informando la próxima generación de autenticación de correo: DKIM2.
DKIM2 es un proyecto activo del grupo de trabajo DKIM del IETF, con un documento de motivación inicial publicado el 4 de mayo de 2026. Está diseñado para reemplazar el estándar DKIM actual (RFC 6376) en lugar de añadirse sobre él.
El problema de reenvío e intermediarios se aborda de manera diferente en DKIM2. En lugar de hacer que los intermediarios añadan sus propias afirmaciones de confianza (el enfoque ARC), DKIM2 define un álgebra para deshacer modificaciones comunes de mensajes. Se espera que un intermediario que altera cabeceras registre el valor anterior de la cabecera de forma legible por máquina. Un receptor puede entonces revertir las modificaciones para comparar el mensaje final recibido con el original, y verificar firmas en múltiples puntos de la cadena sin un tejido de confianza separado.
Otras mejoras en la propuesta DKIM2 incluyen defensa contra ataques de repetición (una debilidad de larga data en DKIM1), requisitos criptográficos más sólidos y prácticas de rotación de claves simplificadas que hacen que los cambios regulares de claves sean operativamente viables.
Calendario: el documento de trabajo actual expira en octubre de 2026, lo que requiere una nueva iteración antes de esa fecha. Se espera que los grandes proveedores tengan implementaciones DKIM2 funcionales antes de finales de 2026. La compatibilidad con versiones anteriores es una elección de diseño deliberada, lo que significa que las claves DKIM1 existentes continúan funcionando a medida que comienza la transición.
Qué Deben Hacer Ahora los Equipos DMARC
El retiro de ARC y el desarrollo de DKIM2 crean un período de transición práctico. Esto es en lo que actuar hoy.
Si tu dominio está en p=quarantine o p=reject: Comprueba si tus flujos de correo legítimo incluyen suscripciones a listas de correo o rutas de reenvío donde tus propios usuarios son los remitentes. Una suscripción a un boletín donde recibes copias, un alias de soporte que se distribuye a múltiples agentes, una comunidad de clientes donde las respuestas fluyen a través de un servidor de lista, todos estos dependen de ARC si involucran que tu dominio aparezca en la cabecera From.
Audita con informes agregados. Tus informes agregados DMARC (RUA) te muestran cada fuente que envía correo que afirma ser de tu dominio, incluidas las rutas de reenvío. Si ves fuentes que no puedes explicar, algunas de ellas pueden ser infraestructura de reenvío legítima donde ARC estaba haciendo el trabajo de pasar la autenticación. A medida que ARC deja de ser la solución universal, esas rutas necesitan atención directa: o consigues la firma DKIM a nivel del administrador de la lista, o aceptas que algunos correos reenviados fallarán DMARC y ajustas en consecuencia.
No esperes a DKIM2. La respuesta operativa para los problemas de reenvío hoy es la alineación DKIM en la fuente. Si ejecutas una lista de correo, firma los mensajes salientes con una clave DKIM del propio dominio de tu lista (no del dominio del remitente original), y configura una alineación From: que la lista controle. Esto evita tanto el problema de SPF roto como el problema de confianza ARC de una vez.
Rastrea el comportamiento específico de cada proveedor. Hasta que se despliegue DKIM2, Gmail y Microsoft continuarán respetando cadenas ARC de intermediarios en sus listas de confianza. Si tus usuarios reciben correo de lista en direcciones Gmail, los fallos DMARC de reenvío son menos probables allí hoy. Pero “Gmail todavía lo respeta” es un hecho de política transitoria, no una solución arquitectónica a largo plazo.
No añadas sellos ARC a nuevos despliegues. La orientación del IETF es inequívoca. Si estás desplegando un nuevo administrador de listas de correo, un servicio de reenvío o cualquier infraestructura intermediaria, no implementes ARC. Invierte ese esfuerzo de ingeniería en preparación para DKIM2.
La Perspectiva General
El retiro de ARC es una señal de que la pila de autenticación de correo está madurando. La industria pasó varios años desplegando una solución parcial para un problema real. Esa solución resultó depender de un modelo de confianza para el que internet no estaba lista. DKIM2 es un rediseño más fundamental: en lugar de añadir nuevas afirmaciones de confianza, mejora el mecanismo de firma central para que los escenarios de reenvío y modificación puedan manejarse sin un tejido de confianza separado.
La ventana entre el retiro de ARC y el despliegue generalizado de DKIM2 es el período en que los propietarios de dominios con aplicación activa necesitan la mayor visibilidad sobre sus flujos de correo reales. Los informes agregados, la enumeración de fuentes y el inventario de claves DKIM son las herramientas que cierran esa brecha de visibilidad.
¿Necesitas ver cada fuente que envía como tu dominio, incluidas las rutas de reenvío y de listas? Excello Mail analiza tus informes agregados DMARC según los estándares RFC 9989, RFC 9990 y RFC 9991, muestra cada fuente de envío con su estado de alineación SPF y DKIM, y señala las rutas donde el reenvío probablemente está causando fallos. Regístrate gratis en Excello Mail y obtén visibilidad completa de tu postura de autenticación de correo antes de que la transición de ARC cree brechas que no puedes ver.