ARC: manter a confiança em um e-mail quando ele atravessa intermediários

Em poucas palavras: ARC (Authenticated Received Chain) é um padrão que permite aos relays (listas de distribuição, gateways antispam, redirecionamentos etc.) preservar e selar os resultados de autenticação (SPF, DKIM, DMARC) que observaram. Assim, o destinatário consegue decidir com base sólida se confia na mensagem mesmo quando SPF/DKIM falham legitimamente após uma alteração ou redirecionamento.

Por que precisamos de ARC?

Sem ARC, uma mensagem legítima pode ser rejeitada depois de ser redirecionada:

• SPF falha porque o IP remetente passa a ser o do relay;
• a assinatura DKIM original pode ficar inválida se o relay modificar cabeçalhos ou corpo (banner, rodapé, marcação antispam);
• em consequência, DMARC falha no destinatário, mesmo que o e-mail fosse válido na origem.

ARC permite que o relay declare: «Recebi uma mensagem que passou em SPF/DKIM/DMARC; aqui estão meus resultados e estou assinando eles.»
O servidor final analisa a cadeia de selos para decidir se o e-mail continua confiável.

Como o ARC funciona (visão geral)

Em cada relay são adicionados três cabeçalhos ARC, com índice i=1, i=2, …:

1. ARC-Authentication-Results (AAR) — reproduz os resultados de SPF/DKIM/DMARC do ponto de vista do relay.
2. ARC-Message-Signature (AMS) — assinatura criptográfica da mensagem conforme observada pelo relay (análogo ao DKIM).
3. ARC-Seal (AS) — um selo que assina o conjunto (AAR + AMS + selos anteriores) para encadear a confiança.

Exemplo de cabeçalhos ARC (simplificado)

ARC-Seal: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.org; dkim=pass header.d=example.org; dmarc=pass header.from=example.org

• i=: posição na cadeia (1 no primeiro relay, depois +1 por salto).
• d= / s=: domínio e selector (como no DKIM) usados para publicar a chave pública no DNS.
• cv= (em ARC-Seal): Chain Validation declarada pelo relay para a cadeia que ele vê; valores comuns: none, pass, fail.
• h=, bh=, b=: campos padrão da assinatura (lista de cabeçalhos assinados, hash do corpo, assinatura).

"Vejo cabeçalhos ARC sem redirecionamento, isso é normal?"

Sim. Grandes provedores (webmail, suítes colaborativas, gateways de segurança) assinam sistematicamente o tráfego de entrada com ARC.
Objetivos: estabelecer um ponto de verdade interno, rastrear a passagem pela infraestrutura e facilitar redirecionamentos posteriores sem perder confiança.

Como o destinatário avalia a cadeia ARC?

1. Verificar todas as assinaturas ARC-Message-Signature e ARC-Seal, começando pelo maior i.
2. Checar a continuidade: nenhum i faltando; cada selo precisa cobrir os anteriores.
3. Observar cv= no último ARC-Seal (a declaração do signatário sobre a cadeia).
4. Cruzar com DMARC: se os SPF/DKIM atuais falharem, decidir se os resultados registrados em ARC-Authentication-Results confiáveis merecem crédito.

Importante: ARC não obriga aceitar uma mensagem; ele fornece contexto verificável para uma decisão mais precisa por parte do destinatário.

Boas práticas (lado operador)

• Assine e valide ARC nos seus relays (listas, aliases, gateways de segurança).
• Preserve os cabeçalhos ARC existentes; não remova selos válidos.
• Gerencie as chaves (rotação, TTL de DNS, monitoramento de falhas de verificação).
• Limite alterações na mensagem após o selo (banners, reescritas) ou selo novamente depois de modificar.
• Registre as decisões DMARC influenciadas por ARC para medir o impacto.

Erros comuns

• Adicionar um ARC-Authentication-Results sem ARC-Message-Signature e ARC-Seal.
• Quebrar a cadeia (índices i duplicados/ausentes, selo que não cobre o anterior).
• Confiar cegamente em qualquer domínio d= desconhecido. A reputação do signatário importa.

Perguntas frequentes

ARC substitui DKIM/DMARC?
Não. Ele complementa SPF/DKIM/DMARC preservando os resultados observados pelos relays.

Quem pode adicionar ARC?
Qualquer intermediário de transporte (MTA, gateway, serviço de e-mail) que manuseie a mensagem.

O que exatamente significa cv=?
É a declaração do signatário sobre o estado da cadeia que ele enxerga: none (sem cadeia anterior), pass (cadeia coerente e verificável), fail (cadeia inválida). O destinatário ainda faz sua própria validação.

Por que a mesma mensagem tem vários i=?
Cada relay incrementa i e adiciona seu próprio trio AAR/AMS/AS.

Para saber mais

• IETF - RFC 8617: Authenticated Received Chain (ARC) : https://datatracker.ietf.org/doc/html/rfc8617
• RFC 8601 - Authentication-Results Header Field (contexto para AAR): https://datatracker.ietf.org/doc/html/rfc8601

---

Resumo rápido

• Objetivo: preservar e selar os resultados SPF/DKIM/DMARC ao longo dos relays.
• 3 cabeçalhos: ARC-Authentication-Results (resultados) + ARC-Message-Signature (assinatura da mensagem) + ARC-Seal (selo da cadeia).
• Decisão do destinatário: assinaturas válidas + reputação do signatário + política DMARC interna.