Todo administrador de e-mail já enfrentou este chamado de suporte: "Eu encaminhei um e-mail importante para meu colega e ele foi para a caixa de spam. Por quê?" A resposta envolve um dos casos de borda mais frustrantes do e-mail — a forma como o encaminhamento quebra a autenticação.
Quando você encaminha um e-mail, está essencialmente reenviando-o a partir de um servidor diferente. O registro SPF original autorizou o servidor do remetente, não o seu. A assinatura DKIM original cobria o conteúdo exato da mensagem, que o encaminhamento frequentemente modifica. Quando o e-mail chega ao destino final, toda verificação de autenticação falha. A mensagem parece uma falsificação, apesar de ser completamente legítima.
ARC — Authenticated Received Chain — foi projetado para resolver esse problema. Ele cria uma cadeia de custódia para os resultados de autenticação, permitindo que cada servidor que manipula uma mensagem ateste o que observou.
Por que o encaminhamento quebra a autenticação
Para entender o ARC, você precisa compreender exatamente como o encaminhamento quebra as coisas.
SPF verifica se o endereço IP do servidor de envio está autorizado para o domínio no endereço 'from' do envelope. Quando você encaminha um e-mail, seu servidor se torna o remetente. Seu IP não está no registro SPF do remetente original, então o SPF falha. Isso funciona como projetado — o SPF deve falhar quando um servidor não autorizado envia e-mails.
DKIM é mais complicado. Uma assinatura DKIM cobre partes específicas da mensagem, normalmente incluindo o corpo e certos cabeçalhos. Muitos sistemas de encaminhamento modificam mensagens: adicionando rodapés, alterando linhas de assunto, encapsulando o conteúdo. Qualquer modificação invalida a assinatura. Mesmo que o encaminhador não modifique nada, algumas implementações de DKIM são suficientemente frágeis para que mudanças mínimas em espaços em branco ou na ordem dos cabeçalhos quebrem a validação.
DMARC conecta tudo isso. Se tanto SPF quanto DKIM falharem, DMARC falha. E se o remetente original tiver uma política DMARC rígida (p=reject), a mensagem encaminhada é rejeitada integralmente. O destinatário nunca a vê.
Isso cria um problema real. Listas de discussão, serviços de encaminhamento de e-mail e roteamento de e-mail corporativo envolvem encaminhamento legítimo. Sem uma solução, políticas de autenticação rígidas quebrariam grandes partes do uso normal de e-mail.
Como o ARC funciona
ARC não corrige SPF ou DKIM — ele funciona ao lado deles. A ideia é simples: cada servidor que manipula uma mensagem registra o que observou e assina esse registro. Servidores posteriores podem então ver o histórico completo dos resultados de autenticação.
Quando uma mensagem chega a um servidor com ARC habilitado, o servidor realiza verificações de autenticação normais: SPF, DKIM, DMARC. Em seguida, ele cria três novos cabeçalhos.
O cabeçalho ARC-Authentication-Results registra o que o servidor observou. SPF passou ou falhou? DKIM validou? Qual foi o resultado de DMARC? Isso é essencialmente um snapshot do status de autenticação neste ponto da jornada da mensagem.
O cabeçalho ARC-Message-Signature é uma assinatura semelhante ao DKIM que cobre o conteúdo da mensagem. Isso permite que servidores posteriores verifiquem que a mensagem não foi modificada desde que este servidor a manipulou.
O cabeçalho ARC-Seal amarra tudo. Ele assina os próprios cabeçalhos ARC, criando uma cadeia com evidências de adulteração. Cada servidor adiciona seu próprio conjunto de cabeçalhos ARC, incrementa um número de sequência e assina todos os cabeçalhos ARC anteriores mais os seus.
O resultado é uma cadeia de custódia. O destinatário final pode ver: "O Servidor A recebeu esta mensagem e o SPF passou. O Servidor B a encaminhou e o DKIM ainda era válido. O Servidor C está entregando agora." Mesmo se a autenticação atual falhar, a cadeia mostra que a autenticação era válida anteriormente.
ARC na prática
Vamos traçar um cenário real. Você envia um e-mail do domínio da sua empresa para uma lista de discussão. A lista o encaminha para todos os inscritos.
Seu e-mail sai do seu servidor com SPF e DKIM válidos. Ele chega ao servidor da lista. O servidor da lista verifica a autenticação — tudo passa. Ele adiciona cabeçalhos ARC registrando esses resultados e os assina.
O servidor da lista então encaminha a mensagem para os inscritos. Ao fazer isso, ele adiciona um rodapé e muda o remetente do envelope (para que os bounces voltem para a lista, não para você). Essas mudanças quebram sua assinatura DKIM original e fazem o SPF falhar.
Quando a mensagem chega ao servidor de e-mail de um inscrito, a autenticação atual falha. Mas o servidor vê a cadeia ARC. Ele pode verificar as assinaturas ARC e ver que, quando a lista de discussão recebeu a mensagem, a autenticação passou. Se o servidor confiar na lista (com base na sua reputação), pode aceitar a mensagem apesar das falhas de autenticação atuais.
Este é o ponto-chave: ARC não torna automaticamente confiável o e-mail encaminhado. Ele fornece informações que servidores receptores podem usar para tomar decisões melhores. A confiança ainda depende da reputação dos intermediários.
Implementando ARC
Se você opera um servidor de e-mail que encaminha mensagens — uma lista de discussão, um serviço de encaminhamento ou roteamento de e-mail corporativo — você deve implementar ARC. É você quem está quebrando a autenticação; você deve fornecer a cadeia de custódia que ajuda os destinatários a confiar no resultado.
A maioria dos softwares modernos de servidor de e-mail suporta ARC. Postfix, Exim e Microsoft Exchange têm recursos de ARC. A configuração normalmente envolve gerar um par de chaves (semelhante ao DKIM), publicar a chave pública no DNS e habilitar a assinatura ARC na configuração do seu servidor.
O registro DNS se parece com um registro DKIM porque essencialmente é um. ARC usa o mesmo formato de chave e mecanismo de validação. Você publica um registro TXT em selector._domainkey.yourdomain.com contendo sua chave pública.
Para servidores de recebimento, a validação ARC é geralmente automática se seu software a suportar. A decisão de confiar ou não nos resultados de ARC — e em quais intermediários confiar — é uma decisão de política. A maioria dos servidores usa dados de reputação: se um operador de lista de discussão bem conhecido assina uma cadeia ARC, isso pesa mais do que um servidor desconhecido.
Limitações do ARC
ARC não é uma bala de prata. Ele tem limitações reais que você deve entender.
Primeiro, ARC requer confiança nos intermediários. Se um servidor malicioso adicionar cabeçalhos ARC falsos alegando que a autenticação passou, servidores posteriores podem ser enganados. É por isso que a reputação importa — você não deve confiar em cadeias ARC de fontes desconhecidas ou de baixa reputação.
Segundo, ARC não ajuda se o primeiro salto for malicioso. Se um atacante enviar uma mensagem falsificada diretamente para uma lista de discussão, a lista registrará fielmente que a autenticação falhou e a encaminhará mesmo assim. ARC preserva resultados de autenticação; ele não cria autenticação onde ela não existe.
Terceiro, a adoção ainda é incompleta. Embora grandes provedores como Google e Microsoft validem ARC, muitos servidores de e-mail menores não o fazem. Sua cadeia ARC cuidadosamente construída pode ser completamente ignorada.
Por fim, ARC adiciona complexidade. Mais cabeçalhos, mais assinaturas, mais coisas que podem quebrar. Depurar problemas de entrega fica mais difícil quando você precisa rastrear múltiplas camadas de validação ARC.
Interação entre ARC e DMARC
A relação entre ARC e DMARC é importante. Políticas DMARC dizem aos receptores o que fazer quando a autenticação falha. ARC fornece contexto adicional que pode mudar essa decisão.
Quando uma mensagem falha em DMARC mas tem uma cadeia ARC válida mostrando sucesso de autenticação anterior, o receptor enfrenta uma escolha. Seguir estritamente a política DMARC rejeitaria a mensagem. Mas a cadeia ARC sugere que é um e-mail legítimo que foi encaminhado.
A maioria dos receptores que suporta ARC vai se sobrepor às falhas de DMARC para mensagens com cadeias ARC confiáveis. Esse é o objetivo — permitir que e-mails encaminhados legítimos passem apesar das falhas de autenticação. Mas isso é uma decisão de política local, não um requisito do padrão.
Se você é proprietário de um domínio com uma política DMARC rígida, entenda que ARC pode fazer sua política ser sobreposta para e-mails encaminhados. Em geral, é isso que você quer — você provavelmente não quer que seus e-mails sejam rejeitados só porque alguém os encaminhou. Mas se você tiver requisitos específicos de segurança, deve entender essa interação.
Você deve se importar com ARC?
Se você opera infraestrutura de e-mail que encaminha mensagens, sim. Implementar ARC é um ato de boa cidadania — você ajuda o ecossistema de e-mail a funcionar melhor.
Se você apenas envia e-mail do seu domínio, ARC é menos diretamente relevante. Você não precisa fazer nada especial; ARC é tratado pelos intermediários. Mas entender ARC ajuda a depurar problemas de entrega quando seus e-mails são encaminhados.
Se você está avaliando entregabilidade de e-mail, conhecer ARC ajuda a explicar por que alguns e-mails encaminhados têm sucesso e outros falham. Uma mensagem encaminhada por um grande provedor com uma boa implementação de ARC terá um desempenho melhor do que uma encaminhada por um servidor pequeno sem suporte a ARC.
Frequently asked questions
ARC substitui DKIM?
Não. ARC complementa DKIM. Você ainda precisa de DKIM nas suas mensagens de saída. ARC ajuda a preservar resultados de autenticação quando mensagens são encaminhadas e assinaturas DKIM quebram.
Posso implementar ARC sem DKIM?
Tecnicamente sim, mas não faz muito sentido. ARC foi projetado para preservar resultados de autenticação, incluindo DKIM. Se você não usa DKIM, há menos o que preservar.
Como sei se meus e-mails estão sendo assinados com ARC quando são encaminhados?
Verifique os cabeçalhos das mensagens encaminhadas. Procure pelos cabeçalhos ARC-Authentication-Results, ARC-Message-Signature e ARC-Seal. Eles indicam que houve processamento ARC.
O Gmail suporta ARC?
Sim. O Google foi um dos principais desenvolvedores do ARC e suporta totalmente tanto a assinatura quanto a validação. Mensagens encaminhadas pelo Gmail terão cabeçalhos ARC, e o Gmail considera cadeias ARC ao avaliar e-mails recebidos.