ARC pasa al estado «Historic» en el IETF: ¿hay que seguir preocupándose en 2026?
Por CaptainDNS
Publicado el 8 de junio de 2026
- El IETF reclasifica ARC (RFC 8617) como estado «Historic» mediante el draft
draft-ietf-dmarc-arc-to-historicpresentado el 22 de abril de 2026, tras la redefinición de la carta del grupo DMARC el 16 de abril de 2026. - No, no se trata de «una herramienta que retira ARC»: la fuente es una decisión de estandarización del IETF, no un proveedor de software.
- «Historic» desaconseja los nuevos despliegues y la confianza entre dominios de terceros. No invalida la RFC 8617 ni obliga a nadie a dejar de verificar las cadenas existentes.
- ARC sigue siendo exigido en la práctica en 2026: iCloud (grandes remitentes), forwarders de Gmail (
arc=pass), Microsoft 365 (trusted sealers, reason code 130). - Si eres propietario de un dominio, probablemente no tengas nada que hacer con ARC: refuerza SPF, DKIM y DMARC, vigila tus informes y no pierdas de vista DKIM2.
Un titular circula desde finales de abril de 2026: «ARC is dead». En los foros y en algunas newsletters ya se lee que tal herramienta de diagnóstico «retira ARC», que el protocolo estaría abandonado, que habría que reconfigurarlo todo. La realidad es más tranquila y, sobre todo, más matizada. ARC no desaparece de la noche a la mañana, y la noticia no viene de ningún proveedor de software.
La fuente exacta es un documento del IETF: el draft draft-ietf-dmarc-arc-to-historic, presentado el 22 de abril de 2026 por J. Trent Adams (Proofpoint) y John Levine. Propone reclasificar la RFC 8617, que especifica ARC, al estado «Historic». Es una decisión del proceso de estandarización, tomada dentro del grupo de trabajo DMARC recién redefinido. Nada que ver con un proveedor que desactivaría una funcionalidad.
Esta guía no vuelve a explicar la mecánica de ARC en profundidad (las cabeceras de sellado, la cadena de resultados). Para eso, lee nuestro artículo de fondo ¿Qué es ARC (Authenticated Received Chain)?. Aquí el objetivo es de decisión: lo que «Historic» cambia realmente, por qué lo ha decidido el IETF y lo que debes hacer según tu rol. La mayoría de las veces, la respuesta cabe en una palabra: nada, al menos nada específico de ARC. Este artículo va dirigido a los administradores de correo, a los equipos DevOps y a los responsables de entregabilidad que han leído un titular alarmista y quieren una decisión clara.
Verifica tu autenticación de correo en lugar de añadir ARC
La noticia, explicada correctamente: ARC hacia «Historic» en el IETF
Empecemos por establecer los hechos, porque el rumor ya ha deformado lo esencial. Ninguna herramienta «retira» ARC. Lo que ocurre es un cambio de estado documental en el IETF, el organismo que estandariza los protocolos de Internet.
¿Qué dice el draft draft-ietf-dmarc-arc-to-historic?
El draft draft-ietf-dmarc-arc-to-historic es un documento corto cuyo único objeto es pedir la reclasificación de la RFC 8617 (la especificación de ARC, publicada en 2019) del estado actual al estado «Historic». Fue presentado el 22 de abril de 2026 por J. Trent Adams, de Proofpoint, y John Levine, dos colaboradores de larga trayectoria en los estándares de correo.
Un documento así no modifica el contenido técnico de ARC. No reescribe el protocolo, no añade ni elimina ninguna cabecera. Es un «status-change document»: deja constancia de una valoración de la comunidad sobre el lugar que ARC debe ocupar en adelante dentro del panorama de los estándares. La motivación cabe en una frase: la adopción y la confianza entre dominios que ARC presuponía nunca se materializaron a la escala esperada, y el esfuerzo de estandarización se concentra ahora en otra parte.
Calendario: redefinición de la carta del grupo DMARC y plazo
Este paso se inscribe en una reorganización. El grupo de trabajo DMARC del IETF redefinió su carta el 16 de abril de 2026, pocos días antes de la presentación del draft. Una redefinición de carta replantea el alcance y las prioridades de un grupo; aquí indica que la comunidad quiere cerrar ciertos frentes y abrir otros.
El draft de reclasificación sigue después el proceso habitual: discusión en grupo, llamada a últimos comentarios («last call») y, luego, revisión del IESG. El plazo previsto para finalizar el status-change se sitúa en torno a noviembre de 2026. Mientras el proceso no concluya, la RFC 8617 conserva formalmente su estado actual; pero la trayectoria es clara y pública.
Lo que «Historic» significa realmente (y lo que no)
La palabra «Historic» suena como un certificado de defunción. En el vocabulario del IETF (definido por el proceso de la RFC 2026), tiene un sentido mucho más preciso y mucho menos dramático.
«Historic» califica a un estándar que ya no se recomienda, generalmente porque ha sido reemplazado, porque su adopción no acompañó, o porque la experiencia ha mostrado sus límites. En concreto, el estado Historic significa esto:
- desaconseja los nuevos despliegues del protocolo;
- indica que la comunidad ya no apuesta por este mecanismo de cara al futuro;
- invita a no construir nuevas dependencias entre dominios basadas en este protocolo.
En cambio, «Historic» no significa esto:
- no es una invalidación: la RFC 8617 sigue siendo un documento publicado y legible, y sus cabeceras siguen siendo sintácticamente válidas;
- no es una prohibición: nadie está obligado a dejar de producir o de verificar las cadenas ARC existentes;
- no es un interruptor: ningún servidor deja de funcionar porque se presente un draft.
Esta distinción es el núcleo del artículo. Obsoleto sobre el papel no significa muerto en la práctica. Lo que sigue lo demuestra.
¿Por qué este giro en el IETF?
ARC se diseñó para resolver un problema real y persistente: el reenvío de correo rompe la autenticación. La idea era elegante. ¿Por qué entonces la comunidad lo coloca hoy entre los estándares históricos? Se conjugan tres razones.
Una adopción limitada y una confianza frágil
ARC parte de una hipótesis fuerte: que un receptor confíe en el sellado aplicado por un intermediario que no controla. Pero esa confianza no se decreta. En la práctica, solo unos pocos actores muy grandes publicaron y mantuvieron listas de «sealers de confianza», y la coordinación entre dominios a gran escala nunca llegó a asentarse. Un mecanismo cuyo valor depende de una confianza generalizada pierde su interés cuando esa confianza queda limitada a un puñado de operadores.
Un fallo de fondo que ARC no cierra
ARC documenta una cadena de resultados de autenticación, pero no protege contra el replay («reenvío abusivo»). Un mensaje legítimamente firmado puede ser capturado y luego reexpedido en masa sin que la firma quede invalidada, porque ni DKIM ni ARC vinculan la firma con el sobre ni con la ruta real del mensaje. ARC añade trazabilidad, no una garantía de integridad de extremo a extremo. La comunidad acabó considerando que invertir más en ARC equivalía a reforzar una tirita en lugar de tratar la herida.
Un esfuerzo que se concentra en el sucesor
El IETF prefiere orientar el trabajo hacia un mecanismo que ataque la causa, en lugar de seguir afinando ARC. Ese sucesor es DKIM2, en proceso de estandarización, que firma a la vez el origen y el destino de cada salto y cierra el fallo de replay. Reclasificar ARC como Historic es también una señal de rumbo: no gastes más energía en extender ARC, mira hacia DKIM2. Volvemos sobre ello al final del artículo.
La paradoja: ARC sigue siendo exigido en la práctica en 2026
Esto es lo que olvidan los titulares alarmistas. En el mismo momento en que el IETF coloca ARC entre los estándares históricos, los tres mayores proveedores de correo del mundo lo utilizan activamente. Para una bandeja de entrada, ARC está muy vivo.
Apple e iCloud: ARC para los grandes remitentes
Desde el 25 de febrero de 2025, Apple aplica requisitos reforzados para los remitentes de gran volumen hacia iCloud. Su documentación describe explícitamente el uso de ARC para preservar los resultados de autenticación cuando un mensaje transita por un intermediario antes de llegar a un buzón iCloud. Dicho de otro modo, un proveedor que reenvía correo hacia iCloud y que sella correctamente la cadena ARC ve su tráfico mejor tratado que el de quien no lo hace.
Google y Gmail: los forwarders firman, Gmail lee arc=pass
Gmail es seguramente el mayor usuario de ARC del mundo. Cuando un mensaje se reenvía (redirección automática, alias, lista de distribución que pasa por la infraestructura de Google), los forwarders de Google aplican cabeceras ARC. Al recibirlo, Gmail lee el resultado arc=pass para reconocer que la autenticación de origen era válida antes del reenvío, y evita así que DMARC falle en un mensaje legítimo solo porque ha sido retransmitido. Aquí ARC es un engranaje cotidiano de la entregabilidad, invisible pero decisivo.
Microsoft 365: trusted sealers y reason code 130
Microsoft 365 integra ARC en su veredicto de autenticación compuesta. Cuando un mensaje habría fallado en DMARC a causa de un reenvío, pero un «trusted sealer» ARC ha preservado los resultados de origen, Exchange Online Protection puede recuperar el mensaje e inscribe el reason code 130 en su cabecera compauth. Ese código indica precisamente que un sellado ARC de confianza ha sustituido a un fallo DMARC. El mecanismo de los trusted sealers, del reason code 130 y del indicador oda=1 se detalla en nuestra guía Compauth=fail en Microsoft 365.
Obsoleto sobre el papel, no muerto en la bandeja de entrada
El contraste es nítido. En el IETF, ARC pasa a ser «Historic». En las infraestructuras de Apple, Google y Microsoft, ARC sigue siendo una señal leída y aprovechada cada día. Ambos hechos no se contradicen. El estado Historic dice «no construyas nuevas dependencias de ARC ni cuentes con él de cara al futuro»; no dice «deja inmediatamente de procesar las cadenas ARC que los grandes operadores siguen produciendo». Confundir ambas cosas es leer un draft de estandarización como un comunicado de cese de servicio.
El problema de fondo no ha desaparecido: el reenvío rompe SPF, DKIM y DMARC
Si ARC se considera insuficiente, el problema al que apuntaba sigue intacto. Entender ese problema ayuda a decidir lo que debes hacer (o no hacer).
¿Por qué una redirección o una lista de distribución rompe la autenticación?
El reenvío de correo daña los tres pilares de la autenticación, cada uno a su manera.
SPF falla porque verifica la dirección IP emisora frente al dominio del sobre. Cuando un servidor de redirección reexpide el mensaje, es su IP la que se presenta al destinatario, y esa IP casi nunca está declarada en el SPF del dominio de origen. Resultado: SPF deja de alinearse.
DKIM falla en cuanto el intermediario modifica el mensaje. Una lista de distribución que añade un pie de página, reescribe el asunto con un prefijo [Lista] o retoca una cabecera rompe el hash firmado. La firma DKIM, que cubre el cuerpo y ciertas cabeceras, queda invalidada.
DMARC, que se apoya en la alineación de SPF o de DKIM con el dominio del From:, falla a su vez en cuanto ambos se rompen a la vez. Un mensaje perfectamente legítimo acaba en dmarc=fail tras un simple reenvío. Es este escenario, frecuente, el que ARC buscaba rescatar transportando la prueba de que la autenticación era buena antes del relé.
ARC era una tirita, no una cura
ARC nunca reparó SPF ni DKIM. Añadió una capa de testimonio: «en el momento en que recibí este mensaje, estos son los resultados de autenticación que constaté, y los sello». Útil, pero condicionado a la confianza que el receptor otorga al sellador, e impotente frente al replay. Por eso, precisamente, la respuesta duradera no consiste en apilar ARC, sino en reforzar lo que de verdad controlas: tu propia autenticación. El futuro estándar DMARCbis, que detallamos en la guía de DMARCbis, aclara además la alineación y la gestión de las políticas, sin hacer que tu conformidad dependa de un mecanismo de terceros.
Quién debe hacer qué: ¿propietario de dominio o intermediario?
Esta es la sección más importante para decidir. La confusión más extendida consiste en creer que todo el mundo «implementa ARC». Falso. ARC es un mecanismo de intermediario. La gran mayoría de los lectores de este artículo nunca ha tenido, ni tendrá, que desplegarlo.
Eres propietario de un dominio: no implementas ARC
Si gestionas el envío de correo de tu organización (un sitio, una tienda, notificaciones transaccionales, un equipo comercial), eres un propietario de dominio, no un intermediario. No sellas cadenas ARC, y el estado Historic no te pide ninguna acción sobre ARC. Lo que debes hacer tiene que ver con tu propia autenticación:
- Refuerza SPF. Declara todas tus fuentes de envío, vigila el límite de 10 consultas DNS que provoca un
permerror, y haz evolucionar el mecanismo final de~alla-allcuando controles tus fuentes. - Solidifica DKIM. Firma todos tus flujos con una clave alineada con tu dominio, y organiza una rotación de claves regular.
- Haz avanzar DMARC. Pasa de
p=none(observación) a una política de aplicación (p=quarantiney luegop=reject) una vez tus fuentes estén bajo control. - Vigila tus informes DMARC. Los informes agregados revelan con precisión qué se rompe en el reenvío y qué fuentes fallan. Es tu panel de control.
- No añadas ARC como parche. No puedes «activar ARC» para reparar un reenvío sufrido aguas abajo: sería el intermediario quien debería sellar, no tú. Concentra el esfuerzo en lo que controlas.
Para verificar el estado real de tu autenticación y la forma en que se reciben tus mensajes, una prueba de entregabilidad vale más que una suposición; nuestra guía de la prueba de entregabilidad explica cómo leer los resultados.
Eres un intermediario: sigue sellando ARC
Si operas un servicio que reexpide correo de terceros (un forwarder, una plataforma de listas de distribución, una pasarela de seguridad, un proveedor de redirección), ARC te concierne, y tu modo de proceder es matizado.
Primero, no cortes nada de golpe. Apple, Google y Microsoft siguen leyendo las cadenas ARC para recuperar mensajes legítimos reenviados. Dejar de sellar de un día para otro degradaría la entregabilidad del correo que retransmites hacia esos destinatarios. El estado Historic no te obliga en absoluto a detenerte.
Después, lee Historic como una consigna de rumbo, no de parada. No construyas nuevas dependencias de ARC que supongan una confianza generalizada entre dominios, no inviertas en extensiones ARC ambiciosas, y prepara la transición hacia el sucesor. Vigila la evolución del proceso del IETF y los anuncios de los grandes receptores: son ellos quienes, en la práctica, fijarán el ritmo real de la salida de ARC.
¿Y después? DKIM2, el sucesor
Reclasificar ARC como Historic solo tiene sentido porque llega una herramienta mejor. Ese sucesor es DKIM2.
Lo que DKIM2 corrige
DKIM2 cambia el enfoque. Allí donde DKIM firma el contenido y ARC añade un testimonio sellado, DKIM2 hace firmar cada salto SMTP vinculando el origen y el destino del mensaje. Cada relé añade su propia firma numerada, y el sobre utilizado en cada salto queda cubierto. Consecuencia directa: el replay, ese fallo que ninguno de los dos mecanismos anteriores cerraba, se vuelve detectable, porque un mensaje reexpedido fuera de su ruta firmada deja de corresponder con la cadena esperada. DKIM2 trata la causa allí donde ARC trataba el síntoma.
Calendario y lo que cambia para ti
DKIM2 está todavía en la fase de los Internet-Drafts en el IETF. La sintaxis exacta de las cabeceras y de los parámetros puede cambiar, y los primeros despliegues solo se esperan a partir de finales de 2026. Para ti, propietario de dominio, esto no exige ninguna acción hoy: no hay nada que publicar ni que configurar para DKIM2 por ahora. La postura correcta es la vigilancia. Entender los principios, seguir los drafts y mantener una infraestructura DKIM sana, porque DKIM2 se apoyará en los mismos cimientos DNS. Nuestro artículo DKIM2: novedades, eliminaciones y fechas clave detalla las nuevas cabeceras y la cronología de los drafts.
Conclusión: pánico evitado, rumbo a DKIM2
La noticia es real pero benigna. El IETF reclasifica ARC como «Historic»: una señal de fin de ciclo, no un cese de servicio. Recapitulemos según tu rol.
Si eres propietario de un dominio, no tienes nada que hacer con ARC, ni ayer ni hoy. Refuerza SPF, DKIM y DMARC, vigila tus informes y no añadas nunca ARC como parche.
Si eres un intermediario, sigue sellando ARC mientras Apple, Google y Microsoft lo lean, pero no construyas nuevas dependencias sobre él y prepara la transición.
Y para todo el mundo, el rumbo es el mismo: la próxima etapa de la autenticación de correo se llama DKIM2. Nada que hacer hoy, todo que entender para mañana.
FAQ
¿ARC está muerto o abandonado en 2026?
No. El IETF reclasifica ARC (RFC 8617) como estado «Historic» mediante el draft draft-ietf-dmarc-arc-to-historic presentado el 22 de abril de 2026. «Historic» desaconseja los nuevos despliegues e indica que la comunidad ya no apuesta por ARC de cara al futuro, pero no invalida la especificación ni obliga a nadie a dejar de producir o verificar cadenas ARC. En la práctica, Apple, Google y Microsoft lo siguen usando activamente.
¿Hay que implementar ARC en 2026 si aún no se ha hecho?
Para la gran mayoría de las organizaciones, no. ARC es un mecanismo de intermediario (forwarders, listas de distribución, pasarelas), no un protocolo que los propietarios de dominio publiquen por su cuenta. Si gestionas el envío de correo de tu organización, nunca has tenido que desplegar ARC, y el estado Historic no cambia nada en eso. Concéntrate en SPF, DKIM y DMARC.
Ya he desplegado ARC en un forwarder o una pasarela: ¿debo retirarlo?
No, no cortes nada de golpe. Apple, Google y Microsoft siguen leyendo las cadenas ARC para recuperar mensajes legítimos reenviados. Dejar de sellar degradaría la entregabilidad del correo que retransmites hacia esos destinatarios. El estado Historic solo te invita a no construir nuevas dependencias de ARC y a preparar la transición hacia DKIM2, no a detenerte de inmediato.
¿Hay que seguir verificando las cabeceras ARC en recepción?
Sí, si operas un receptor que ya se apoya en ARC. El estado Historic no pide dejar de verificar las cadenas existentes. Los grandes proveedores siguen leyendo arc=pass para evitar que DMARC falle en mensajes reenviados legítimos. Mientras esas cadenas circulen, ignorarlas penalizaría correo legítimo.
ARC frente a DKIM2: ¿qué reemplaza a ARC, y cuándo?
El sucesor es DKIM2, en proceso de estandarización en el IETF. A diferencia de ARC, que añade un testimonio sellado sin cerrar el fallo de replay, DKIM2 hace firmar cada salto vinculando el origen y el destino, lo que hace el replay detectable. DKIM2 está todavía en fase de drafts; los primeros despliegues solo se esperan a partir de finales de 2026. No se requiere ninguna acción hoy, solo vigilancia.
¿Se va a eliminar la RFC 8617 o quedará invalidada con el estado Historic?
No. El estado «Historic», en el sentido del proceso del IETF, no elimina ni invalida un documento. La RFC 8617 sigue publicada, legible y técnicamente válida: las cabeceras ARC siguen siendo sintácticamente correctas y las implementaciones existentes siguen funcionando. Historic es una señal documental que desaconseja los nuevos usos, no una retirada de la especificación.
ARC resolvía el problema del reenvío que rompe DMARC: ¿se resuelve ese problema de otra forma?
Todavía no del todo. El reenvío rompe SPF (la IP del relé no está en el SPF de origen) y a menudo DKIM (modificación del cuerpo o de las cabeceras), por lo que DMARC falla. ARC era una tirita que transportaba la prueba de autenticación previa al relé. La respuesta duradera consiste en reforzar tu propio SPF, DKIM y DMARC, vigilar tus informes y seguir DKIM2, que ataca la causa firmando cada salto.
«Historic» en el IETF: ¿qué cambia en concreto para un administrador?
Para un administrador de dominio, a corto plazo: nada. No implementas ARC, así que el estado no toca tu configuración. Lo que hay que retener es el rumbo: no apuestes por ARC para nuevos proyectos, refuerza tu propia autenticación y prepárate mentalmente para DKIM2. Para un operador intermediario, el cambio es una consigna de trayectoria, no una orden de parada inmediata.
Descarga las tablas comparativas
Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.
📖 Glosario
- Historic (estado IETF): clasificación del proceso de estandarización (RFC 2026) que indica que un protocolo ya no se recomienda para nuevos despliegues, sin quedar invalidado ni prohibido.
- RFC 8617: la especificación de ARC (Authenticated Received Chain), publicada en 2019.
- ARC (Authenticated Received Chain): mecanismo por el cual un intermediario sella los resultados de autenticación observados antes de reexpedir un mensaje.
- Trusted sealer: intermediario cuya firma ARC un receptor considera fiable, por ejemplo Microsoft 365.
- Replay (reenvío abusivo): reutilización abusiva de un mensaje legítimamente firmado, reexpedido sin invalidar la firma; fallo que ARC no cierra y que DKIM2 busca corregir.
- DKIM2: sucesor en proceso de estandarización en el IETF, que firma el origen y el destino de cada salto para resistir el replay y el reenvío.
