Si eres un remitente normal y una guía te ha dicho que despliegues ARC, esa guía se equivoca por partida doble. ARC es algo que añade un intermediario mientras retransmite el mensaje de otro, así que un remitente originador no tiene nada que sellar. Y el grupo de trabajo del IETF que lo tiene a su cargo publicó en abril de 2026 un borrador pidiendo que la especificación se reclasifique como Histórica, con el argumento de que el experimento ha terminado.
Nada de esto hace que ARC sea inútil de leer. Sigue explicando por qué se entregó o se rechazó un mensaje reenviado, y Apple sigue pidiéndolo en el correo reenviado a sus buzones. Leerlo y desplegarlo son decisiones distintas, y solo una de las dos se está retirando.
ARC registra lo que vio un reenviador, y por eso un remitente no tiene nada que sellar
DMARC se rompe con el reenvío. Una lista de correo o una dirección de reenvío retransmite tu mensaje desde sus propios servidores, así que SPF falla en un dominio de sobre que no es el tuyo, y cualquier modificación de las cabeceras o del cuerpo rompe tu firma DKIM. El mensaje era legítimo cuando lo enviaste y falla la autenticación cuando llega.
ARC fue la respuesta propuesta. Cada intermediario registra los resultados de autenticación que vio a la llegada, firma ese registro y sella la cadena de todo lo anterior. Un receptor al final puede así ver el resultado original tal como lo observó el primer salto, aunque la prueba en sí haya desaparecido.
Quien hace esa firma es el reenviador, no tú. Para ARC no publicas nada, no hay ningún registro DNS en tu dominio más allá de la clave DKIM que usaría un intermediario si resultara que lo eres, y el conjunto de cabeceras aparece solo en mensajes que se han retransmitido. Una guía que le dice a un dominio de envío normal que "active ARC" lo ha confundido con DKIM.
La cadena son tres cabeceras por salto, y la numeración es la comprobación
Cada salto añade tres cabeceras, y el RFC 8617, sección 5.2, hace estricto tanto el conjunto como la secuencia.
| Cabecera | Qué lleva |
|---|---|
| ARC-Authentication-Results | Los resultados de autenticación que vio este salto a la llegada |
| ARC-Message-Signature | Una firma sobre el mensaje tal como lo recibió este salto |
| ARC-Seal | Una firma sobre la cadena hasta aquí, con el estado de validación de la cadena |
Cuatro reglas convierten esas cabeceras en una cadena y no en un montón:
- Los números de instancia van desde 1 hacia arriba, de forma continua, hasta un máximo de 50. Un hueco o una repetición es una cadena mal formada, no una cadena a la que le falta un eslabón.
- Cada instancia tiene exactamente una de cada una de las tres cabeceras. Un duplicado es un fallo.
- El sello de la instancia 1 debe llevar
cv=none, y toda instancia posterior debe llevarcv=pass. Ese valor es la declaración del firmante sobre todo lo anterior. - Un
cv=failen la instancia más alta termina ahí la cadena. Una vez que un salto registra un fallo, nada posterior la restaura.
La estructura se puede comprobar sin conexión y las firmas no, y esa es toda la forma de lo que cualquier herramienta de cabeceras puede decirte con honestidad. Un lector que mira la instancia más alta e informa del valor que encuentra se ha saltado la comprobación que importa, porque es la continuidad desde 1 lo que hace que la secuencia signifique algo.
El IETF está retirando ARC, y lo dice sin rodeos
draft-ietf-dmarc-arc-to-historic-00, publicado el 22 de abril de 2026 por Todd Adams, de Proofpoint, y John Levine, de Taughannock Networks, es un documento de grupo de trabajo, no una propuesta individual. Deja obsoleto el RFC 8617 si se aprueba y pide que la especificación se marque como Histórica.
Sus conclusiones son inusualmente directas. El experimento ha terminado. Quienes lo implementan y lo operan no deberían depender de ARC en adelante y deberían cesar los despliegues a escala de Internet. Quienes ya lo tienen desplegado deberían planificar su retirada o confinar su uso a contextos controlados dentro de un mismo dominio. Se desaconsejan los despliegues nuevos porque es improbable que aporten información útil para el procesamiento del correo.
La razón que se da no es que la criptografía fallara. Es que la verificación sin reputación no puede anular con seguridad una política de aplicación. Quien evalúa tiene que decidir si se fía de cada firmante de la cadena antes de actuar sobre sus afirmaciones, lo que significa operar un sistema de reputación de intermediarios, y después de diez años nadie construyó uno que funcione a escala de Internet. Lo que sí construyeron quienes desplegaron fueron listas de permitidos de intermediarios en los que ya confiaban, que funciona de forma bilateral y no generaliza. El borrador lo llama la lección central: las firmas no son confianza.
Una segunda limitación es más concreta. Cuando un intermediario modifica un mensaje, ARC identifica quién lo modificó pero no tiene mecanismo para decir qué cambió ni por qué, así que el receptor vuelve a juzgar la reputación del intermediario. Las piezas útiles se están incorporando al trabajo sucesor de DKIM, llamado por ahora DKIM2, que evita una cadena paralela y un tejido de confianza aparte salto a salto.
Anota el estado con honestidad: esto es un Internet-Draft, no un RFC. Caduca en octubre de 2026 si no avanza. Lo que documenta, eso sí, no es tanto una propuesta como una descripción de dónde ya se ha detenido el esfuerzo.
Apple es el único proveedor que sigue pidiéndolo, y se lo pide al reenviador
Los requisitos para remitentes de Apple, publicados en febrero de 2025, piden ARC en el correo reenviado a los buzones de Apple. Es el único de los cuatro grandes proveedores que lo pide, y es la razón honesta para mostrar ARC en un comprobador en vez de ignorarlo.
Lee el alcance con cuidado, porque es donde esto se cuenta mal. La petición cubre el correo reenviado a buzones de Apple, y quien está en posición de satisfacerla es el reenviador. Si operas un servicio de reenvío, una lista de correo o una pasarela de correo, esto va contigo. Si envías correo comercial o transaccional desde tu propio dominio, no, y ningún cambio de configuración por tu parte produce una cadena ARC.
Los otros tres grandes proveedores de buzones piden SPF, DKIM y DMARC, y ninguno menciona ARC. En los dominios que probamos para el Unspam 2026 Email Deliverability Benchmark, el 48% publica una política DMARC, que es el trabajo que de verdad está sin terminar.
Qué hacer en su lugar cuando el reenvío te rompe DMARC
El problema para el que se construyó ARC es real y sigue necesitando solución. Las respuestas disponibles son menos exóticas.
- Asegúrate de que DKIM está alineado y firma las cabeceras que sobreviven. DKIM es el identificador que atraviesa un reenvío, porque cubre el mensaje y no la conexión. Si solo está alineado SPF, el reenvío te quita el único identificador que pasaba.
- Mantén conservadora la lista de cabeceras firmadas. Una firma sobre cabeceras que los intermediarios reescriben habitualmente se rompe más a menudo que una sobre lo esencial.
- Lee tus informes DMARC antes de dar por hecho que la causa es el reenvío. Los reenviadores aparecen como fuentes que no reconoces pasando DKIM y fallando SPF, que es una forma distintiva y fácil de separar de los problemas reales.
- No te quedes en
p=nonepor culpa del reenvío. El correo que pasa DKIM alineado sobrevive al reenvío, y los informes te dicen qué fuentes no lo hacen antes de que apliques nada. - Si operas un intermediario, sigue el trabajo de DKIM2 en vez de empezar ahora un despliegue de ARC.
Nuestra guía sobre registros DMARC cubre la política y los informes, y el identificador que el reenvío rompe primero es el tema de nuestra guía sobre el Return-Path.
Qué puede informar un comprobador, y qué debería negarse a informar
Una cadena ARC en un mensaje que recibiste es evidencia sobre su camino, y merece la pena leerla exactamente en esos términos.
Nuestro analizador de cabeceras de correo informa de la estructura de la cadena: cuántos conjuntos hay, si los números de instancia forman una secuencia continua desde 1, si cada conjunto está completo, si los valores cv siguen la regla de su posición, y el dominio que selló cada salto. Informa de un cv=fail como el punto en el que la cadena terminó.
Lo que no hace es verificar las firmas, y no te dice que la cadena sea de fiar. Son afirmaciones distintas, y el borrador es explícito en que la validez de la cadena sin un juicio de reputación no es base para una decisión de entrega. Una herramienta que imprime una insignia ARC en verde está afirmando algo sobre lo que ningún receptor actuaría.
Para los registros que sí deciden la entrega, nuestra guía sobre autenticación del correo cubre cómo dependen unos de otros SPF, DKIM y DMARC. Para ver los resultados de autenticación en un mensaje real, incluida cualquier cadena ARC que haya recogido por el camino, haz una prueba de spam gratis.
