ARC fue diseñado para realizar evaluaciones de autenticación a través de intermediarios que pueden cambiar un mensaje. Agrega evidencia sobre un manejo anterior; no convierte al intermediario en el autor original ni exige que el receptor final acepte el mensaje. Lea un resultado ARC como una entrada para la decisión del receptor, junto con los controles actuales de autenticación y abuso.
Lea los tres componentes.
Referencias: RFC 8617 §4.1.1, RFC 8617 §4.1.2, RFC 8617 §4.1.3.
Un conjunto ARC contiene ARC-Authentication-Results , ARC-Message-Signature y ARC-Seal. El primero conlleva la valoración de un intermediario. El segundo firma el contenido del mensaje en el marco ARC . El sello une el material ARC en una cadena ordenada. Los números de instancia conectan los componentes que pertenecen a cada conjunto. RFC 8617, apartados 4 y 5, define las estructuras y el procesamiento.
El dmarc=pass informado anteriormente es una afirmación de un intermediario, no un resultado nuevo calculado por el receptor final. Un sello válido establece una relación criptográfica con el dominio firmante según las reglas de validación. No establece que el dominio sea un juez confiable, que sus sistemas no estuvieran comprometidos o que su evaluación anterior afirmada fuera correcta.
Sigue un camino sintético
Referencias: RFC 8617 §5.2, RFC 8617 §7.2.1.
Considere el envío author.example a forwarder.example , que registra un pase alineado antes de aplicar un pie de página. El mensaje final puede fallar actual DKIM debido a la modificación y falla alineada SPF porque llega a través del intermediario. ARC puede realizar la evaluación anterior de un receptor que valida la cadena y tiene una razón para confiar en ese intermediario.
El punto de control incluye una ilustración de encabezado que no se valida deliberadamente con i=1, los tres nombres de campo y cv=none. Los marcadores de posición de firma están visiblemente marcados como no firmas. Nunca debe pegarse en un mensaje como si fuera un conjunto ARC en funcionamiento. El modelo ejecutable complementario proporciona entradas de confianza y validez de la cadena y demuestra que ni una cadena válida que no es de confianza ni una cadena inválida de confianza califican para su anulación ilustrativa.
Separar una anulación de un pase
Referencias: RFC 8617 §7.2.1, RFC 8617 §9.3, RFC 9989 §7.4.
Un receptor puede utilizar evidencia anterior confiable al decidir la disposición, pero las observaciones localmente DMARC el resultado sigue siendo distinto. Registre la autenticación actual, la validación de la cadena, la confianza del sellador y el manejo final de forma independiente. Un mensaje aceptado a través de una política local no debe volver a etiquetarse como si hubiera pasado por un mecanismo de autenticación diferente.
El modelo de juguete también incluye contenido malicioso con entradas que de otro modo serían favorables. Su decisión de filtración aún rechaza ese caso. Este es un ejemplo de política conservadora original, no un algoritmo ARC normativo ni una predicción del comportamiento de Gmail o Microsoft. Ese primer modelo de juguete no realiza ninguna firma ni verificación. El laboratorio contratado a continuación registra la criptografía ARC real mediante una búsqueda de claves controlada, sin entrega del proveedor.
Mantener actualizado el estado de las normas
La verificación IETF Datatracker del 8 de noviembre de 2026 enumera RFC 8617 como Experimental. La revisión 01 de la propuesta para reclasificar ARC como Histórica es un Borrador de Internet activo, de fecha 21 de octubre de 2026. Su propuesta no es una reclasificación completa. Vuelva a verificar ambos registros antes de tomar una decisión de implementación y evalúe el soporte del proveedor por separado. Estado RFC y trabajo de reclasificación.
Para una dependencia existente, identifique qué intermediarios confiables y flujos comerciales realmente dependen de ARC antes de cambiar la configuración. Para una dependencia propuesta, documente la incertidumbre y las alternativas. La evidencia retenida incluye una cadena de encabezado local genuinamente firmada y un modelo de decisión de confianza local a continuación. La evidencia de implementación del receptor externo aún no está disponible.
Evidencia de laboratorio retenida
Referencias: RFC 8617 §5.1, RFC 8617 §5.2.
El laboratorio retenido el 7 de noviembre de 2026 verificó por primera vez la información real del autor original. firma DKIM y aportes SPF . Registra esos resultados en lab.forwarder.example , agrega el pie de página y usa dkimpy para crear una cadena ARC real de un solo conjunto con una clave RSA de reenviador temporal. Posteriormente, dkimpy valida el sello y la firma del mensaje. Un párrafo adjunto posterior al sellado provoca una falla en la validación ARC . El código de decisión del receptor acepta o rechaza por separado la elegibilidad de la cadena válida según un indicador de confianza configurado. Se conservan los mensajes completos firmados y manipulados, además de los detalles de validación. La firma ARC y la manipulación se produjeron fuera de línea después de la captura SMTP de seis mensajes; el indicador de confianza impulsa una función de decisión separada, no un resultado de entrega del proveedor.
Se inspeccionó el corredor retenido y la captura del 7 de noviembre de 2026; No se volvió a ejecutar ningún experimento de red para esta revisión. El experimento original utilizó únicamente loopback y no envió correo de Internet. Su receptor crea Authentication-Results de sus propios controles, dando a esos campos una procedencia de laboratorio conocida. El resultado y la disposición de la autenticación permanecen separados: las seis muestras SMTP reciben 250 bajo una política de captura explícita, incluidas las muestras fallidas. El límite de confianza es este laboratorio controlado, no un proveedor de buzones de producción. El adaptador DNS proporciona respuestas fijas retenidas en lugar de consultar DNS público, y el evaluador DMARC utiliza únicamente igualdad estricta de dominio. El descubrimiento completo del dominio organizacional, el análisis de políticas de producción y los resultados de la implementación en vivo aún no se han probado.
El borrador de reclasificación histórica activa recomienda no implementar o confiar en ARC entre remitentes y receptores dispares. Esta es una propuesta importante a considerar al planificar nuevas dependencias, no una jubilación completa o prueba de que un proveedor actual ha desactivado ARC . Conserve una evaluación de dependencia específica del proveedor fechada mientras continúa el proceso de estándares.