Em 22 de abril de 2026, o grupo de trabalho DMARC do IETF publicou o draft-ietf-dmarc-arc-to-historic-00, solicitando a reclassificação do RFC 8617 como padrão Histórico. O grupo de trabalho havia recebido um novo mandato poucos dias antes, em 16 de abril de 2026, com a missão específica de produzir um documento de mudança de status para o ARC até novembro de 2026.
O experimento chamado ARC chegou ao fim, na linguagem formal do IETF.
Isso importa para qualquer organização que execute uma política DMARC em p=quarantine ou p=reject. O ARC era o mecanismo que deveria impedir que e-mails legítimos encaminhados falhassem ao encontrar sua política de aplicação. Entender o que está sendo aposentado, por que não funcionou e o que vem a seguir indica exatamente o que você precisa fazer hoje.
Qual Problema o ARC Foi Criado Para Resolver
O DMARC tem um problema estrutural conhecido com e-mails que passam por intermediários.
Considere uma mensagem que seu cliente envia do Gmail para uma lista de e-mails. O servidor administrador da lista recebe a mensagem original, adiciona um cabeçalho de lista, modifica o rodapé e a reencaminha para todos os assinantes. Quando essa mensagem chega à caixa de entrada de um assinante, duas coisas aconteceram:
- O SPF foi quebrado. O remetente do envelope original passou no SPF, mas a lista de e-mails agora está enviando a partir do próprio IP, que não está no seu registro SPF.
- O DKIM pode ter sido quebrado. Se o administrador da lista modificar o corpo da mensagem ou determinados cabeçalhos, a assinatura DKIM sobre essas partes não é mais válida.
Uma política DMARC de p=reject verifica o alinhamento SPF e o alinhamento DKIM. Se ambos falham, o DMARC falha. O servidor receptor está agora na posição de rejeitar uma mensagem que era completamente legítima quando entrou na cadeia de e-mails.
O encaminhamento de e-mail (o tipo que um usuário configura para redirecionar mensagens de um endereço para outro) cria o mesmo problema. O servidor de encaminhamento não está no seu registro SPF, pode modificar a mensagem e o resultado é uma falha de DMARC no destino final.
O ARC, Authenticated Received Chain (RFC 8617, publicado em julho de 2019), foi a correção proposta. Cada servidor intermediário que tocasse a mensagem adicionaria três cabeçalhos: ARC-Authentication-Results, ARC-Message-Signature e ARC-Seal. Juntos, criavam um registro criptograficamente verificável do estado de autenticação da mensagem em cada salto. Um receptor no final da cadeia poderia ler os cabeçalhos ARC, decidir se confia na assinatura do intermediário e aplicar essa confiança para substituir a aparente falha de DMARC.
O Gmail adotou. O Microsoft adotou. Um punhado de grandes provedores seguiu. A teoria era sólida.
Por Que o Experimento Falhou
A conclusão do IETF, documentada no rascunho, é direta: o ARC não conseguiu “adoção notável nem impacto suficiente” apesar de anos de desenvolvimento.
O problema central foi o modelo de confiança. Para que o ARC funcione, um receptor no final da cadeia precisa decidir se respeitar os selos ARC deixados pelo intermediário. Essa decisão exige confiar no intermediário. Mas o IETF nunca conseguiu estabelecer consenso sobre em quais assinaturas ARC deveria-se confiar na internet.
Não existe um registro de confiança ARC. Não existe um mecanismo globalmente aceito para um receptor determinar se um servidor de lista de e-mails que nunca viu antes está operando legitimamente. Sem isso, a decisão de confiança fica com uma política específica de cada receptor: o Google confia em certos intermediários que identificou; o Microsoft confia no seu próprio conjunto. Os selos deixados por um servidor de lista menor ou menos conhecido podem ou não ser respeitados, dependendo inteiramente de onde fica a caixa de entrada do destinatário final.
Na prática, isso significava que operadores de listas de e-mails publicavam selos ARC, os proprietários de domínios dependiam deles e a proteção era parcial, inconsistente e invisível para ambas as partes. O rascunho é explícito: o ARC não deve “ser implantado nem utilizado entre remetentes e receptores distintos”.
Os grandes provedores que já processam cadeias ARC, especificamente Gmail e Microsoft 365, continuarão fazendo isso para as cadeias em que confiam. O IETF não está forçando-os a remover código existente. Mas a orientação para os implementadores é parar de adicionar nova dependência no ARC, e para novos intermediários, não implantá-lo.
O Que o DKIM2 Muda
A lição do ARC está informando a próxima geração de autenticação de e-mail: DKIM2.
O DKIM2 é um projeto ativo do grupo de trabalho DKIM do IETF, adotado pelo grupo, com um documento de motivação inicial publicado em 4 de maio de 2026. Ele foi projetado para substituir o padrão DKIM atual (RFC 6376), não para se sobrepor a ele.
O problema de encaminhamento e intermediários é abordado de forma diferente no DKIM2. Em vez de fazer com que os intermediários adicionem suas próprias afirmações de confiança (a abordagem ARC), o DKIM2 define uma álgebra para desfazer modificações comuns de mensagens. Espera-se que um intermediário que altera cabeçalhos registre o valor anterior do cabeçalho de forma legível por máquina. Um receptor pode então reverter as modificações para comparar a mensagem final recebida com a original, e verificar assinaturas em vários pontos da cadeia sem um tecido de confiança separado.
Outras melhorias na proposta do DKIM2 incluem defesa contra ataques de repetição (uma vulnerabilidade de longa data no DKIM1), requisitos criptográficos mais fortes e práticas simplificadas de rotação de chaves que tornam as mudanças regulares de chaves operacionalmente viáveis.
Cronograma: o documento de trabalho atual expira em outubro de 2026, exigindo uma nova iteração antes dessa data. Espera-se que os grandes provedores tenham implementações DKIM2 funcionais antes do final de 2026. A compatibilidade retroativa é uma escolha deliberada de design, o que significa que as chaves DKIM1 existentes continuam funcionando à medida que a transição começa.
O Que as Equipes DMARC Precisam Fazer Agora
A aposentadoria do ARC e o desenvolvimento do DKIM2 criam um período de transição prático. Aqui está o que agir hoje.
Se o seu domínio está em p=quarantine ou p=reject: Verifique se seus fluxos de e-mail legítimos incluem assinaturas em listas de e-mails ou caminhos de encaminhamento onde seus próprios usuários são os remetentes. Uma assinatura de newsletter onde você recebe cópias, um alias de suporte que distribui para vários agentes, uma comunidade de clientes onde respostas fluem por um servidor de lista, todos esses dependem do ARC se envolverem seu domínio aparecendo no cabeçalho From.
Audite com relatórios agregados. Seus relatórios agregados DMARC (RUA) mostram cada fonte enviando e-mails que afirmam ser do seu domínio, incluindo caminhos encaminhados. Se você vir fontes que não consegue explicar, algumas podem ser infraestrutura de encaminhamento legítima onde o ARC estava fazendo o trabalho de passar a autenticação. À medida que o ARC deixa de ser a correção universal, esses caminhos precisam de atenção direta: ou você consegue a assinatura DKIM no nível do administrador da lista, ou aceita que alguns e-mails encaminhados falharão no DMARC e ajusta de acordo.
Não espere pelo DKIM2. A resposta operacional para problemas de encaminhamento hoje é o alinhamento DKIM na fonte. Se você executa uma lista de e-mails, assine as mensagens de saída com uma chave DKIM do próprio domínio da sua lista (não do domínio do remetente original), e configure um alinhamento From: que a lista controle. Isso contorna tanto o problema de SPF quebrado quanto o problema de confiança ARC de uma só vez.
Acompanhe o comportamento específico de cada provedor. Até que o DKIM2 seja implantado, o Gmail e o Microsoft continuarão respeitando cadeias ARC de intermediários em suas listas de confiança. Se seus usuários recebem e-mails de lista em endereços Gmail, falhas de DMARC por encaminhamento são menos prováveis lá hoje. Mas “o Gmail ainda respeita” é um fato de política transitório, não uma correção arquitetônica de longo prazo.
Não adicione selos ARC a novas implantações. A orientação do IETF é inequívoca. Se você estiver implantando um novo administrador de listas de e-mails, um serviço de encaminhamento ou qualquer infraestrutura intermediária, não implemente o ARC. Invista esse esforço de engenharia na preparação para o DKIM2.
A Perspectiva Geral
A aposentadoria do ARC é um sinal de que a pilha de autenticação de e-mail está amadurecendo. A indústria passou vários anos implantando uma correção parcial para um problema real. Essa correção acabou dependendo de um modelo de confiança para o qual a internet não estava pronta. O DKIM2 é um redesenho mais fundamental: em vez de adicionar novas afirmações de confiança, ele melhora o mecanismo de assinatura central para que cenários de encaminhamento e modificação possam ser tratados sem um tecido de confiança separado.
A janela entre a aposentadoria do ARC e a implantação generalizada do DKIM2 é o período em que os proprietários de domínios com aplicação ativa precisam da maior visibilidade sobre seus fluxos de e-mail reais. Relatórios agregados, enumeração de fontes e inventário de chaves DKIM são as ferramentas que fecham essa lacuna de visibilidade.
Precisa ver cada fonte enviando como o seu domínio, incluindo caminhos de encaminhamento e de listas? O Excello Mail analisa seus relatórios agregados DMARC nos padrões RFC 9989, RFC 9990 e RFC 9991, mostra cada fonte de envio com status de alinhamento SPF e DKIM, e sinaliza os caminhos onde o encaminhamento provavelmente está causando falhas. Cadastre-se gratuitamente no Excello Mail e obtenha visibilidade completa da sua postura de autenticação de e-mail antes que a transição do ARC crie lacunas que você não consegue ver.