todas las guías

// cómo solucionarlo

ARC fail (arc=fail): qué significa la Authenticated Received Chain

Tus cabeceras muestran arc=fail o cv=fail. Qué es ARC, por qué la cadena se rompe con los reenvíos y las listas de correo, y qué puedes corregir de verdad.

Qué significa

ARC (Authenticated Received Chain, RFC 8617) ayuda a que los emails sobrevivan a los reenvíos. Cuando un reenviador o una lista de correo modifica un mensaje, SPF y DKIM suelen romperse. ARC permite que cada servidor intermedio anote cuáles eran los resultados de autenticación cuando recibió el mensaje y firme esa anotación. El receptor final puede decidir entonces fiarse de esos resultados anteriores.

Cada servidor que añade ARC escribe tres cabeceras con un número de instancia i=1, i=2...:

  • ARC-Authentication-Results: los resultados de SPF, DKIM y DMARC tal como los vio ese servidor.
  • ARC-Message-Signature: una firma del mensaje parecida a DKIM.
  • ARC-Seal: una firma de las cabeceras ARC, con cv= (validación de la cadena) con valor none (primer salto), pass o fail.

Un resultado como este significa que no se pudo validar la cadena:

Authentication-Results: mx.example.com; arc=fail (signature failed)
ARC-Seal: i=2; a=rsa-sha256; cv=fail; d=lists.example.org; s=arc; ...

En cuanto un sello indica cv=fail, la cadena queda rota para siempre: los servidores posteriores no pueden repararla.

Por qué ocurre

  • Un servidor modificó el mensaje después de sellarlo: un pie de página, una etiqueta en el asunto, una pasarela de seguridad que reescribe los enlaces o un antivirus que añade un aviso después de que se añadiera ARC.
  • Una clave ARC incorrecta o ausente: el selector de ARC-Seal (s=) no tiene clave pública en el DNS en selector._domainkey.domain, o la clave no coincide.
  • Orden roto o cabeceras ausentes: un salto eliminó o reordenó cabeceras ARC, o falta un número de instancia.
  • Demasiados saltos: el estándar permite como máximo 50 instancias.
  • Implementaciones con errores en una pasarela o en el software de una lista de correo.

Importante: arc=fail no significa que tu dominio esté mal configurado. Si enviaste el email directamente y SPF, DKIM y DMARC pasan, ARC solo importa para el correo reenviado. Además, arc=none solo significa que nadie añadió ARC, lo que es normal en el correo directo.

Cómo comprobarlo

  1. Prueba primero tus propios envíos. Envía un email a la dirección única de la página de inicio de Delivmail (/) directamente desde tu herramienta. Si SPF, DKIM y DMARC pasan, el problema está en el camino del reenvío, no en tu configuración.
  2. Lee las cabeceras del mensaje recibido en el buzón final ("Mostrar original" en Gmail, "View message source" en Outlook). Localiza cada ARC-Seal y anota i=, cv=, d= y s=. El primer sello con cv=fail, o el salto justo anterior, es donde se rompió. Consulta cómo leer las cabeceras de un email.
  3. Comprueba la clave ARC de quien selló:
    dig TXT arc._domainkey.lists.example.org +short

Cómo solucionarlo

Si gestionas el reenviador, la lista o la pasarela

  • Añade ARC después de cualquier modificación del mensaje. La inserción de pies de página y avisos debe hacerse antes del sellado.
  • Publica la clave pública ARC y comprueba el selector. Muchos servidores admiten ARC: por ejemplo, Rspamd tiene un módulo ARC y Mailman 3 admite la firma ARC.
  • Mejor reenviar sin modificar el cuerpo, y usar SRS para el SPF del correo reenviado.

Si eres el remitente original

Si eres el receptor final (Microsoft 365)

Si un servicio de confianza (una pasarela de seguridad, una lista) rompe DMARC pero sella correctamente con ARC, Microsoft 365 te permite declararlo como sellador ARC de confianza, en el portal de Defender o con PowerShell. El parámetro sustituye toda la lista, así que incluye los valores existentes:

Set-ArcConfig -Identity Default -ArcTrustedSealers "lists.example.org"

Confía solo en selladores que conozcas bien: un sellador de confianza puede hacer que un correo que falla parezca legítimo.

Comprueba que está solucionado

Envía un mensaje nuevo por el mismo camino y lee las cabeceras en el destino: el último ARC-Seal debe mostrar cv=pass y Authentication-Results debe mostrar arc=pass. Haz también una prueba en Delivmail para confirmar que tu propio SPF, DKIM y DMARC siguen pasando. Cada receptor decide si usa ARC, así que una cadena válida ayuda, pero no garantiza la entrega.

Comprueba que está solucionado

Un cambio de DNS puede tardar de unos minutos a unas horas. Después, envía un nuevo email de prueba o vuelve a escanear tu dominio.

Guías relacionadas