Listas de distribución y DMARC: por qué se rompe y cómo ARC lo recupera

Las salidas del lado de la lista: reescribir el From o no tocar nada

Ante ese muro, los operadores de listas convergieron en dos grandes estrategias de filosofías opuestas.

La primera: la reescritura del From. La lista deja de presentarse como simple relé y se convierte en la autora oficial del mensaje. El encabezado pasa a ser algo como From: "Marie Dupont via discusion" <discusion@listas.ejemplo.es>, con la dirección real del autor desplazada a Reply-To. DMARC evalúa a partir de ahí el dominio de la lista —que firma sus propios mensajes con DKIM y alinea su propio SPF— y todo pasa. GNU Mailman, omnipresente en las listas técnicas, ofrece este comportamiento como opción, a menudo activado solo cuando el dominio del autor publica una política restrictiva. El precio es semántico: la respuesta privada al autor se vuelve una lotería, las libretas de direcciones memorizan la dirección de la lista en lugar de la de la persona, y la identidad real del autor solo sobrevive en el nombre visible.

La segunda: la no modificación. La lista renuncia al prefijo de asunto, al pie de página, a cualquier retoque del cuerpo MIME. La firma DKIM original permanece entonces intacta y verificable a la llegada —y como DMARC solo exige un mecanismo alineado, ese DKIM superviviente basta: la desalineación de SPF ya no pesa nada—. Es la vía criptográficamente más limpia, adoptada por un número creciente de listas técnicas. Su coste es ergonómico: los marcadores familiares desaparecen del contenido visible, y la información migra a los encabezados normalizados List-Id, List-Post y List-Unsubscribe, invisibles para el ojo pero explotados por los clientes de correo modernos. Una tercera vía histórica —encapsular el mensaje original como adjunto de un mensaje nuevo emitido por la lista— lo preserva todo, pero degrada tanto la lectura que prácticamente ha desaparecido.

ARC, la cadena de custodia de los resultados de autenticación

Las dos salidas anteriores reparan el síntoma sacrificando algo: la identidad del autor o los usos de la lista. ARC (Authenticated Received Chain, RFC 8617, publicada en 2019 con estatus experimental) ataca el problema desde otro ángulo: en lugar de evitar la rotura, documenta la cadena de custodia, como un acta de entrega en cada eslabón.

El principio: cada intermediario que manipula el mensaje le estampa tres encabezados numerados (i=1, i=2…). ARC-Authentication-Results consigna los resultados de autenticación observados a la llegada a ese intermediario —por ejemplo spf=pass, dkim=pass, dmarc=pass en el momento en que la lista recibió el mensaje del autor—. ARC-Message-Signature firma el mensaje tal y como se retransmite, modificaciones incluidas. ARC-Seal sella el conjunto de la cadena, garantizando que ningún eslabón fue alterado a posteriori. El receptor final, ante el fallo DMARC, puede entonces remontar la cadena: si está intacta y el sello procede de un intermediario considerado digno de confianza, sabe que el mensaje estaba correctamente autenticado antes de la lista —y puede elegir entregarlo pese a la política—. El protocolo se desmonta en detalle en el funcionamiento de ARC.

El límite está en esa última frase: considerado digno de confianza. ARC autentica un testimonio, no la honestidad del testigo. Cualquier servidor puede sellar una cadena ARC formalmente válida que afirme que todo iba bien en el origen —incluido un spammer que sella su propia basura—. El valor de una cadena depende, pues, por completo de la reputación que el receptor conceda al sellador, y no existe ningún registro público de intermediarios de confianza: cada gran receptor mantiene el suyo. Gmail y Microsoft 365 sellan y honran ARC a gran escala; una pequeña lista autoalojada en un servidor anónimo verá, en cambio, sus sellos educadamente ignorados. ARC recupera así una gran parte de la rotura legítima en los grandes proveedores, pero no es ni una garantía universal ni una razón para renunciar a las buenas prácticas del lado de la lista.

Lo que muestra un informe RUA

Para el propietario del dominio del autor, todo esto deja una huella reconocible en los informes agregados. La firma típica del tráfico de lista: una IP de origen perteneciente al servidor de la lista, un SPF en fallo o en éxito no alineado (el dominio de sobre es el de la lista), un DKIM en fallo —o en éxito para el dominio de la lista, y por tanto tampoco alineado— y una disposición que sigue la política publicada. Cuando un receptor ha honrado una cadena ARC, la fila lo dice explícitamente:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>local_policy</type>
    <comment>arc=pass</comment>
  </reason>
</policy_evaluated>

Ese bloque se lee así: la política pedía una sanción, pero el receptor la anuló (local_policy) porque la cadena ARC atestiguaba una autenticación sana aguas arriba. Saber reconocer estas filas lo cambia todo en la interpretación de un informe. Contarlas como intentos de suplantación infla artificialmente la amenaza percibida y puede provocar un pánico injustificado; a la inversa, bajo p=reject, las mismas filas sin excepción ARC representan mensajes reales, escritos por usuarios reales, definitivamente perdidos. Una herramienta de análisis que nombra las fuentes —esta IP es un operador de listas conocido, aquella un servidor universitario— acorta el diagnóstico de horas a minutos.

Recomendaciones: operador de lista y propietario de dominio

Los dos roles no controlan las mismas palancas, y confundirlos lleva a planes de remediación imposibles.

Del lado del operador de lista, el orden de prioridades es claro. Primero, dejar de modificar los mensajes: sin prefijo de asunto ni pie de página, el DKIM original sobrevive y el problema desaparece en lo esencial —los encabezados List-* transportan perfectamente la información de baja—. Si la cultura de la lista impone los marcadores visibles, activar la reescritura del From, idealmente de forma condicional (solo para los autores cuyo dominio publica una política estricta). En todos los casos: firmar con DKIM usando el dominio de la propia lista, alinear el SPF y el DMARC de ese dominio, sellar con ARC si la plataforma lo permite, y vigilar el procesamiento de los rebotes para no volver a dar de baja a inocentes por la política de un tercero.

Del lado del propietario de dominio, todo depende de la población que hay detrás de las direcciones. Un dominio puramente aplicativo —transaccional, notificaciones, marketing— no tiene humanos que publiquen en listas: el problema es marginal y no justifica ningún retraso hacia la política estricta. Un dominio con buzones humanos reales, en cambio, obliga a observar los informes antes de endurecer: identificar el tráfico de listas, medir su volumen, avisar a los equipos afectados. La elección entre cuarentena y rechazo cobra aquí un sentido muy concreto: p=quarantine deja a los mensajes de lista una oportunidad de aterrizar —en spam, pero recuperables— allí donde p=reject los destruye sin más en los receptores que no honran ARC. El modo de prueba t=y de DMARCbis permite además evaluar el efecto de una política sin aplicarla, el tiempo necesario para cartografiar la exposición real del dominio a las listas.

En resumen

Una lista de distribución rompe DMARC dos veces: sus retoques al contenido invalidan la firma DKIM del autor, y su reenvío desde sus propios servidores deja SPF sin alineación —ninguno de los dos mecanismos sobrevive, y el mensaje legítimo falla—. El episodio fundacional de 2014 impuso dos salidas del lado de las listas, la reescritura del From y la no modificación del contenido, cada una con su sacrificio. ARC añade una tercera vía: una cadena sellada que atestigua la autenticación original y permite al receptor rehabilitar el mensaje —a condición de confiar en el sellador, lo que hoy reserva el beneficio a los grandes intermediarios conocidos—. En los informes RUA, este tráfico se reconoce por su huella característica y por las excepciones local_policy; leerlo correctamente evita tanto la falsa alarma como la pérdida silenciosa.

El punto de partida práctico no cuesta nada: pasar el dominio por un análisis DMARC gratuito revela el estado de los mecanismos de autenticación y cómo trataría la política actual el tráfico retransmitido. Para llegar hasta el final —identificar las listas dentro de los informes, seguir las excepciones ARC, endurecer la política sin perder un solo mensaje legítimo—, la creación de una cuenta abre la vigilancia continua de los informes, con el histórico necesario para distinguir, semana tras semana, la rotura de lista de la verdadera suplantación.