Todo administrador de correo se ha topado con este ticket de soporte: "Reenvié un correo importante a mi colega y terminó en su carpeta de spam. ¿Por qué?" La respuesta implica uno de los casos límite más frustrantes del email—la forma en que el reenvío rompe la autenticación.
Cuando reenvías un correo, en esencia lo estás volviendo a enviar desde un servidor diferente. El registro SPF original autorizaba el servidor del remitente, no el tuyo. La firma DKIM original cubría el contenido exacto del mensaje, que el reenvío a menudo modifica. Para cuando el correo llega a su destino final, todas las comprobaciones de autenticación fallan. El mensaje parece una falsificación, aunque sea completamente legítimo.
ARC—Authenticated Received Chain—fue diseñado para resolver este problema. Crea una cadena de custodia de los resultados de autenticación, permitiendo que cada servidor que maneja un mensaje responda por lo que observó.
Por qué el reenvío rompe la autenticación
Para entender ARC, necesitas comprender exactamente cómo el reenvío rompe las cosas.
SPF verifica si la dirección IP del servidor de envío está autorizada para el dominio en la dirección del envelope 'from'. Cuando reenvías un correo, tu servidor se convierte en el remitente. Tu IP no está en el registro SPF del remitente original, así que SPF falla. Esto funciona como se diseñó: SPF debe fallar cuando un servidor no autorizado envía correo.
DKIM es más complicado. Una firma DKIM cubre partes específicas del mensaje, típicamente incluyendo el cuerpo y ciertas cabeceras. Muchos sistemas de reenvío modifican los mensajes: añaden pies de página, cambian las líneas de asunto, envuelven contenido. Cualquier modificación invalida la firma. Incluso si el servidor que reenvía no modifica nada, algunas implementaciones de DKIM son lo suficientemente frágiles como para que cambios menores en espacios en blanco u orden de las cabeceras rompan la validación.
DMARC las vincula. Si tanto SPF como DKIM fallan, DMARC falla. Y si el remitente original tiene una política DMARC estricta (p=reject), el mensaje reenviado se rechaza por completo. El destinatario nunca lo ve.
Esto crea un problema real. Las listas de correo, los servicios de reenvío de correo y el enrutamiento de correo corporativo implican reenvío legítimo. Sin una solución, las políticas de autenticación estrictas romperían grandes porciones del uso normal del correo.
Cómo funciona ARC
ARC no arregla SPF ni DKIM: trabaja junto a ellos. La idea es simple: cada servidor que maneja un mensaje registra lo que observó y firma ese registro. Los servidores posteriores pueden ver el historial completo de resultados de autenticación.
Cuando un mensaje llega a un servidor con ARC habilitado, el servidor realiza las comprobaciones de autenticación normales: SPF, DKIM, DMARC. Luego crea tres cabeceras nuevas.
La cabecera ARC-Authentication-Results registra lo que el servidor observó. ¿SPF pasó o falló? ¿DKIM se validó? ¿Cuál fue el resultado de DMARC? Esto es esencialmente una instantánea del estado de autenticación en este punto del recorrido del mensaje.
La cabecera ARC-Message-Signature es una firma similar a DKIM que cubre el contenido del mensaje. Esto permite a los servidores posteriores verificar que el mensaje no ha sido modificado desde que este servidor lo manejó.
La cabecera ARC-Seal lo une todo. Firma las propias cabeceras ARC, creando una cadena que evidencia cualquier manipulación. Cada servidor añade su propio conjunto de cabeceras ARC, incrementa un número de secuencia y firma tanto todas las cabeceras ARC previas como las suyas.
El resultado es una cadena de custodia. El destinatario final puede ver: "El Servidor A recibió este mensaje y SPF pasó. El Servidor B lo reenvió y DKIM seguía siendo válido. El Servidor C lo está entregando ahora". Aunque la autenticación actual falle, la cadena muestra que la autenticación fue válida antes.
ARC en la práctica
Veamos un escenario real. Envías un correo desde el dominio de tu empresa a una lista de correo. La lista lo reenvía a todos los suscriptores.
Tu correo sale de tu servidor con SPF y DKIM válidos. Llega al servidor de la lista. El servidor de la lista comprueba la autenticación—todo pasa. Añade cabeceras ARC que registran estos resultados y las firma.
El servidor de la lista luego reenvía el mensaje a los suscriptores. Al hacerlo, añade un pie de página y cambia el remitente del envelope (para que los rebotes vuelvan a la lista, no a ti). Estos cambios rompen tu firma DKIM original y hacen que SPF falle.
Cuando el mensaje llega al servidor de correo de un suscriptor, la autenticación actual falla. Pero el servidor ve la cadena ARC. Puede verificar las firmas ARC y ver que, cuando la lista de correo recibió el mensaje, la autenticación pasó. Si el servidor confía en la lista de correo (según su reputación), puede aceptar el mensaje a pesar de los fallos de autenticación actuales.
Esta es la idea clave: ARC no hace que el correo reenviado sea confiable automáticamente. Proporciona información que los servidores receptores pueden usar para tomar mejores decisiones. La confianza aún depende de la reputación de los intermediarios.
Implementar ARC
Si operas un servidor de correo que reenvía mensajes—una lista de correo, un servicio de reenvío o un enrutamiento de correo corporativo—deberías implementar ARC. Tú eres quien rompe la autenticación; deberías proporcionar la cadena de custodia que ayuda a los destinatarios a confiar en el resultado.
La mayoría del software moderno de servidores de correo soporta ARC. Postfix, Exim y Microsoft Exchange tienen capacidades ARC. La configuración típicamente implica generar un par de claves (similar a DKIM), publicar la clave pública en DNS y habilitar la firma ARC en la configuración de tu servidor.
El registro DNS se parece a un registro DKIM porque esencialmente lo es. ARC usa el mismo formato de clave y mecanismo de validación. Publicas un registro TXT en selector._domainkey.yourdomain.com que contiene tu clave pública.
Para servidores receptores, la validación ARC suele ser automática si tu software la soporta. La decisión de si confiar en los resultados ARC—y en qué intermediarios confiar—es una decisión de política. La mayoría de los servidores usan datos de reputación: si un operador de listas de correo conocido firma una cadena ARC, eso pesa más que un servidor desconocido.
Limitaciones de ARC
ARC no es una bala de plata. Tiene limitaciones reales que deberías entender.
Primero, ARC requiere confiar en los intermediarios. Si un servidor malicioso añade cabeceras ARC falsas alegando que la autenticación pasó, los servidores posteriores podrían ser engañados. Por eso la reputación importa: no deberías confiar en cadenas ARC de fuentes desconocidas o de baja reputación.
Segundo, ARC no ayuda si el primer salto es malicioso. Si un atacante envía un mensaje suplantado directamente a una lista de correo, la lista registrará fielmente que la autenticación falló y lo reenviará de todos modos. ARC preserva los resultados de autenticación; no crea autenticación donde no la había.
Tercero, la adopción aún es incompleta. Aunque proveedores grandes como Google y Microsoft validan ARC, muchos servidores de correo más pequeños no lo hacen. Tu cadena ARC cuidadosamente construida podría ignorarse por completo.
Por último, ARC añade complejidad. Más cabeceras, más firmas, más cosas que pueden romperse. Depurar problemas de entrega se vuelve más difícil cuando necesitas seguir múltiples capas de validación ARC.
Interacción entre ARC y DMARC
La relación entre ARC y DMARC es importante. Las políticas DMARC indican a los receptores qué hacer cuando la autenticación falla. ARC proporciona contexto adicional que puede cambiar esa decisión.
Cuando un mensaje falla DMARC pero tiene una cadena ARC válida que muestra un éxito de autenticación anterior, el receptor enfrenta una elección. Seguir estrictamente la política DMARC implicaría rechazar el mensaje. Pero la cadena ARC sugiere que es correo legítimo que fue reenviado.
La mayoría de los receptores que soportan ARC anularán fallos de DMARC para mensajes con cadenas ARC confiables. Este es el objetivo: permitir que el correo reenviado legítimo pase a pesar de fallos de autenticación. Pero esto es una decisión de política local, no un requisito estándar.
Si eres propietario de un dominio con una política DMARC estricta, entiende que ARC podría hacer que tu política se anule para correo reenviado. Generalmente esto es lo que quieres: probablemente no quieres que tus correos sean rechazados solo porque alguien los reenviara. Pero si tienes requisitos de seguridad específicos, deberías comprender esta interacción.
¿Deberías preocuparte por ARC?
Si operas infraestructura de correo que reenvía mensajes, sí. Implementar ARC es ser un buen ciudadano—estás ayudando a que el ecosistema del correo funcione mejor.
Si solo envías correo desde tu dominio, ARC es menos relevante de forma directa. No necesitas hacer nada especial; ARC lo gestionan los intermediarios. Pero entender ARC te ayuda a depurar problemas de entrega cuando tus correos se reenvían.
Si estás evaluando la entregabilidad del correo, conocer ARC ayuda a explicar por qué algunos mensajes reenviados tienen éxito y otros fallan. Un mensaje reenviado a través de un proveedor grande con una buena implementación de ARC tendrá mejor resultado que uno reenviado a través de un servidor pequeño sin soporte ARC.
Frequently asked questions
¿ARC reemplaza a DKIM?
No. ARC complementa a DKIM. Sigues necesitando DKIM en tus mensajes salientes. ARC ayuda a preservar los resultados de autenticación cuando los mensajes se reenvían y las firmas DKIM se rompen.
¿Puedo implementar ARC sin DKIM?
Técnicamente sí, pero no tiene mucho sentido. ARC está diseñado para preservar resultados de autenticación, incluido DKIM. Si no haces DKIM, hay menos que preservar.
¿Cómo sé si mis correos están siendo firmados con ARC al ser reenviados?
Revisa las cabeceras de los mensajes reenviados. Busca las cabeceras ARC-Authentication-Results, ARC-Message-Signature y ARC-Seal. Estas indican que se realizó procesamiento ARC.
¿Gmail admite ARC?
Sí. Google fue uno de los desarrolladores principales de ARC y admite completamente tanto la firma como la validación. Los mensajes reenviados a través de Gmail tendrán cabeceras ARC, y Gmail considera las cadenas ARC al evaluar el correo entrante.