// 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, concv=(validación de la cadena) con valornone(primer salto),passofail.
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 enselector._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
- 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. - Lee las cabeceras del mensaje recibido en el buzón final ("Mostrar original" en Gmail, "View message source" en Outlook). Localiza cada
ARC-Sealy anotai=,cv=,d=ys=. El primer sello concv=fail, o el salto justo anterior, es donde se rompió. Consulta cómo leer las cabeceras de un email. - 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
- Asegúrate de que DKIM pasa y está alineado con tu dominio From. DKIM sobrevive a un reenvío simple mucho mejor que SPF.
- Para las listas de correo, lee las listas de correo y Google Groups rompen DMARC.
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
- Tu dominio no tiene registro DMARCDMARC indica a los receptores qué hacer con los emails que fallan SPF y DKIM, y te envía informes. Gmail y Yahoo lo exigen a los envíos masivos. Empieza con un registro seguro de monitorización.
- DMARC falla: SPF y DKIM no coinciden con tu dominioSPF o DKIM pueden superarse y DMARC fallar igualmente, porque se superaron para otro dominio. Haz que al menos uno use el mismo dominio que tu dirección From.
- Pasar DMARC de p=none a quarantine o reject sin riesgosp=none solo observa. Para frenar de verdad los emails falsos con tu dominio, pasa poco a poco a quarantine y a reject, sin bloquear tus propios emails.
- Requisitos de Gmail y Yahoo para envíos masivosDesde 2024, Gmail y Yahoo exigen a los grandes remitentes autenticar sus emails, ofrecer la baja en un clic y mantener las quejas por spam muy bajas. Aquí tienes la lista de comprobación.
- Rebote de Gmail «550 5.7.26»: email no autenticadoGmail rechazó tu email porque no pudo confirmar que viene de tu dominio. SPF, DKIM o DMARC falta o falla. Así puedes solucionarlo.