Resumen
El IETF ha publicado un borrador que recomienda marcar ARC (Authenticated Received Chain) como "Obsoleto" tras un experimento de 10 años. ARC fue diseñado para preservar la autenticación del correo electrónico cuando intermediarios como listas de correo y reenviadores modificaban los mensajes, pero no logró ofrecer una solución escalable debido a la falta de un sistema de reputación a escala de internet. Las lecciones aprendidas del experimento se incorporarán a DKIM2, el sucesor de próxima generación de DKIM.
Para las organizaciones, esto significa seguir centrándose en SPF, DKIM y DMARC como base de la seguridad del correo electrónico, que siguen siendo requisitos obligatorios de los principales proveedores de bandejas de entrada.
Red Sift OnDMARC ayuda a las organizaciones a lograr la aplicación total de DMARC en 6 a 8 semanas, protegiendo contra la suplantación de identidad y el phishing, a la vez que mantiene la capacidad de entrega del correo electrónico en todos los escenarios de intermediarios y reenvío.
El Internet Engineering Task Force (IETF) ha publicado un borrador en el que pide la conclusión del experimento ARC (Authenticated Received Chain) y recomienda que el RFC8617 se marque como "Obsoleto". Esto marca el final de un esfuerzo de una década para resolver uno de los desafíos más persistentes de la autenticación de correo electrónico: qué ocurre cuando intermediarios legítimos modifican los mensajes y rompen DMARC.
¿Qué es ARC y por qué se creó?
Tras el despliegue de DMARC, que alineó SPF y DKIM con los dominios de origen y aportó la aplicación de políticas, surgió una brecha crítica: el reenvío y las modificaciones de las listas de correo con frecuencia rompían la autenticación, provocando que correos legítimos fallaran las comprobaciones de DMARC.
ARC se introdujo como un protocolo experimental para abordar este problema mediante la creación de una "cadena de custodia" criptográfica para los correos electrónicos. El concepto era sencillo: cada intermediario que gestionara un mensaje (listas de correo, reenviadores, pasarelas) podía:
- Registrar los resultados de autenticación que observaron
- Firmar criptográficamente esas observaciones
- Crear una cadena verificable que mostrara lo ocurrido a lo largo de la ruta del mensaje
El objetivo era permitir que los receptores posteriores vieran que, aunque la autenticación actual pudiera estar rota, el mensaje era legítimo cuando se envió originalmente.
Cómo se suponía que funcionaba ARC
ARC definió tres campos de encabezado que los intermediarios podían añadir a los mensajes:
- ARC-Authentication-Results: Qué resultados de autenticación observó el intermediario
- ARC-Message-Signature: Una firma del mensaje y de los encabezados ARC anteriores
- ARC-Seal: Una firma que vincula toda la cadena
Cada gestor añadiría su propio conjunto de estos encabezados, construyendo una cadena que los evaluadores posteriores podrían verificar. Si la cadena era válida, los receptores podrían potencialmente confiar en que el mensaje era legítimo a pesar de los fallos de autenticación actuales.
Por qué el experimento ARC no tuvo éxito
Tras 10 años de experiencia operativa, el borrador del IETF identifica varias razones críticas por las que ARC no alcanzó sus objetivos:
Ausencia de un sistema de reputación escalable
ARC podía verificar que los intermediarios participaron en la cadena, pero no podía transmitir confianza. Sin una manera de determinar cuáles de los miles de posibles intermediarios eran fiables, los receptores no podían anular con seguridad los fallos de DMARC basándose únicamente en ARC. Las listas de permitidos ad hoc resultaron insuficientes y costosas de mantener.
Transparencia limitada
ARC mostraba que un mensaje había sido modificado, pero no qué se había cambiado ni por qué. Esto dejaba la interpretación completamente en manos de los evaluadores y de su capacidad para evaluar la reputación de los intermediarios, una carga que resultó operativamente impráctica a escala de internet.
Preocupaciones de seguridad
La separación entre "verificación" y "confianza" generaba riesgos. Los atacantes podían enrutar mensajes a través de intermediarios permisivos o comprometidos para obtener un trato favorable, aprovechándose eficazmente del sistema.
Carga operativa
El número de posibles reenviadores e intermediarios es enorme y cambia constantemente. Mantener registros de reputación para todos ellos resultó poco realista y, tras 10 años, no surgió ningún sistema de reputación a escala de internet, ni está previsto que surja.
¿Qué ocurre con el problema del reenvío?
El problema del reenvío que motivó ARC sigue siendo real. Cuando los mensajes se reenvían a través de listas de correo o reglas de reenvío automático:
- SPF falla porque la infraestructura de reenvío aparece como la IP de envío
- DKIM a menudo falla cuando los reenviadores modifican encabezados o cuerpos del mensaje
- DMARC falla como resultado, bloqueando potencialmente correos legítimos
Sin embargo, el borrador del IETF deja claro que el enfoque de ARC—confiar en la reputación de los intermediarios sin un marco de confianza escalable—no es la solución.
En su lugar, los elementos útiles de ARC (aserciones firmadas sobre el manejo) se incorporarán a DKIM2, el sucesor propuesto de DKIM. DKIM2 busca abordar los ataques de repetición, los patrones de enrutamiento modernos y el manejo por intermediarios de manera más integral, sin requerir cadenas de firmas paralelas ni sistemas de reputación salto a salto.
Qué significa esto para las organizaciones
- Sigue centrándote en SPF, DKIM y DMARC: Los fundamentos no han cambiado. SPF, DKIM y DMARC siguen siendo la base de la autenticación de correo electrónico y son exigidos por los principales proveedores de bandejas de entrada, incluidos Google, Yahoo y Microsoft, para remitentes masivos.
- No implementes nuevas implementaciones de ARC: El borrador del IETF recomienda que ARC ya no se implemente ni se utilice como base de confianza entre remitentes y receptores dispares. Cualquier procesamiento residual de ARC debe tratarse únicamente como diagnóstico. Nota: A menos que tu organización esté construyendo infraestructura de correo, esto probablemente no sea relevante.
- Prepárate para DKIM2: A medida que DKIM2 se desarrolle e incorpore las lecciones aprendidas del experimento ARC, las organizaciones deben mantenerse informadas sobre la evolución de los estándares de autenticación de correo electrónico.
- Mantén una aplicación estricta de DMARC: Independientemente del problema del reenvío, DMARC en modo de aplicación (p=reject o p=quarantine) sigue siendo la protección más eficaz contra la suplantación de dominio exacto y los ataques de phishing.
Red Sift OnDMARC: creado para los estándares de autenticación de correo electrónico que funcionan
Red Sift OnDMARC se centra en lo que las organizaciones necesitan hoy: una implementación rápida y fiable de SPF, DKIM y DMARC para protegerse contra la suplantación de identidad y mantener la capacidad de entrega.
Cómo OnDMARC resuelve los desafíos reales de autenticación de correo electrónico
- Implementación rápida: La mayoría de las organizaciones alcanzan la aplicación total de DMARC en 6-8 semanas con orientación automatizada y pruebas en tiempo real mediante Red Sift Investigate
- SPF dinámico: Evita el límite de 10 consultas sin necesidad de macros, garantizando la capacidad de entrega incluso en infraestructuras de envío complejas
- Gestión automatizada: Controla los registros SPF, DKIM, DMARC, BIMI y MTA-STS desde un único panel con un solo cambio de DNS
- DNS Guardian: Supervisión continua de configuraciones incorrectas de DNS y ataques de subdominio que eluden DMARC
- Resolución de problemas impulsada por IA: Red Sift Radar resuelve problemas de autenticación 10 veces más rápido con información basada en LLM
- Visibilidad clara: Los paneles en tiempo real transforman los complejos informes de DMARC en información procesable
Por qué las organizaciones eligen Red Sift
Red Sift OnDMARC es la solución DMARC mejor valorada en EMEA, con una calificación de 4.9/5 en G2, y cuenta con la confianza de más de 1200 organizaciones, incluidas Save the Children, ZoomInfo, Wise y Holland & Barrett.
Nuestro galardonado equipo de éxito de clientes te guía en cada paso, desde la implementación hasta la aplicación total, garantizando que logres protección rápidamente sin interrumpir la entrega de correo electrónico legítimo.
¿Listo para fortalecer tu autenticación de correo electrónico?
La conclusión del experimento ARC refuerza lo que los equipos de seguridad ya sabían: una autenticación de correo electrónico eficaz comienza con SPF, DKIM y DMARC correctamente implementados.
Red Sift OnDMARC hace esto posible para organizaciones de todos los tamaños, con automatización de nivel empresarial, orientación experta y tecnología de primera clase.
Jack leads content, PR, GEO, and email security research at Red Sift.