ARC passa ao status « Historic » na IETF: ainda vale a pena se preocupar em 2026?

⚡TL;DR

• A IETF reclassifica o ARC (RFC 8617) como status « Historic » por meio do draft draft-ietf-dmarc-arc-to-historic, depositado em 22 de abril de 2026, após o rechartering do grupo DMARC em 16 de abril de 2026.
• Não, não se trata de « uma ferramenta que remove o ARC »: a fonte é uma decisão de padronização da IETF, não um fornecedor de software.
• « Historic » desencoraja novas implantações e a confiança entre domínios de terceiros. Isso não invalida a RFC 8617 e não obriga ninguém a parar de verificar as cadeias existentes.
• O ARC continua exigido na prática em 2026: iCloud (grandes remetentes), forwarders do Gmail (arc=pass), Microsoft 365 (trusted sealers, reason code 130).
• Se é proprietário de um domínio, provavelmente não tem nada a fazer com o ARC: reforce SPF, DKIM e DMARC, monitorize os seus relatórios e fique de olho no DKIM2.

Uma manchete circula desde o fim de abril de 2026: « ARC is dead ». Nos fóruns e em algumas newsletters, já se lê que tal ferramenta de diagnóstico « remove o ARC », que o protocolo estaria abandonado, que seria preciso reconfigurar tudo. A realidade é mais tranquila e, sobretudo, mais sutil. O ARC não desaparece do dia para a noite, e a notícia não vem de nenhum fornecedor de software.

A fonte exata é um documento da IETF: o draft draft-ietf-dmarc-arc-to-historic, depositado em 22 de abril de 2026 por J. Trent Adams (Proofpoint) e John Levine. Ele propõe reclassificar a RFC 8617, que especifica o ARC, como status « Historic ». É uma decisão do processo de padronização, tomada dentro do grupo de trabalho DMARC recém-rechartered. Nada a ver com um fornecedor que desativaria uma funcionalidade.

Este guia não reexplica em profundidade a mecânica do ARC (os cabeçalhos de selagem, a cadeia de resultados). Para isso, leia nosso artigo de fundo O que é o ARC (Authenticated Received Chain)?. Aqui, o objetivo é de decisão: o que « Historic » muda de facto, porque a IETF decidiu assim e o que deve fazer conforme o seu papel. Na maioria das vezes, a resposta cabe em uma palavra: nada, ao menos nada específico do ARC. Este artigo é voltado para administradores de e-mail, equipas DevOps e responsáveis por entregabilidade que leram uma manchete alarmista e querem uma decisão clara.

A notícia, explicada corretamente: ARC rumo a « Historic » na IETF

Vamos começar estabelecendo os factos, porque o boato já distorceu o essencial. Nenhuma ferramenta « remove » o ARC. O que acontece é uma mudança de status documental na IETF, o organismo que padroniza os protocolos da Internet.

O que diz o draft draft-ietf-dmarc-arc-to-historic?

O draft draft-ietf-dmarc-arc-to-historic é um documento curto cujo único objetivo é solicitar a reclassificação da RFC 8617 (a especificação do ARC, publicada em 2019) do status atual para o status « Historic ». Ele foi depositado em 22 de abril de 2026 por J. Trent Adams, da Proofpoint, e John Levine, dois colaboradores de longa data dos padrões de e-mail. O documento continua na revisão -00: desde o depósito não surgiu nenhuma versão nova e o texto ainda não foi submetido ao IESG.

Um documento desse tipo não modifica o conteúdo técnico do ARC. Ele não reescreve o protocolo, não adiciona nem remove cabeçalhos. É um « status-change document »: ele regista um consenso da comunidade sobre o lugar que o ARC deve ocupar dali em diante no panorama dos padrões. A motivação cabe em uma frase: a adoção e a confiança entre domínios que o ARC pressupunha nunca se materializaram na escala esperada, e o esforço de padronização concentra-se agora em outro lugar.

Cronograma: rechartering do grupo DMARC e prazo

Essa iniciativa se introduz em uma reorganização. O grupo de trabalho DMARC da IETF foi rechartered em 16 de abril de 2026, poucos dias antes do depósito do draft. Um rechartering redefine o escopo e as prioridades de um grupo; aqui, ele sinaliza que a comunidade quer encerrar certos projetos e abrir outros.

O draft de reclassificação segue então o processo habitual: discussão em grupo, chamado a último comentário (« last call ») e, depois, revisão pelo IESG. O prazo visado para finalizar o status-change é por volta de novembro de 2026. Enquanto o processo não termina, a RFC 8617 mantém formalmente o seu status atual; mas a trajetória é clara e pública.

O que « Historic » significa de facto (e o que não significa)

A palavra « Historic » soa como uma certidão de óbito. No vocabulário da IETF (definido pelo processo da RFC 2026), ela tem um sentido muito mais preciso e muito menos dramático.

« Historic » qualifica um padrão que não é mais recomendado, geralmente porque foi substituído, porque a sua adoção não acompanhou, ou porque a experiência mostrou os seus limites. Concretamente, o status Historic quer dizer o seguinte:

• ele desencoraja as novas implantações do protocolo;
• ele sinaliza que a comunidade não aposta mais nesse mecanismo para o futuro;
• ele convida a não construir nova dependência entre domínios baseada nesse protocolo.

Em contrapartida, « Historic » não quer dizer o seguinte:

• não é uma invalidação: a RFC 8617 continua a ser um documento publicado e legível, os seus cabeçalhos continuam sintaticamente válidos;
• não é uma proibição: ninguém é obrigado a parar de produzir ou de verificar cadeias ARC existentes;
• não é um interruptor: nenhum servidor para de funcionar porque um draft foi depositado.

Essa distinção é o cerne do artigo. Depreciado no papel não significa morto na prática. O que vem a seguir demonstra isso.

Porque essa virada? As razões da IETF

O ARC foi concebido para resolver um problema real e persistente: o reencaminhamento de mensagens quebra a autenticação. A ideia era elegante. Porque, então, a comunidade o coloca hoje entre os padrões históricos? Três razões se combinam.

Uma adoção limitada e uma confiança frágil

O ARC baseia-se em uma hipótese forte: que um receptor confie no selo aplicado por um intermediário que ele não controla. Ora, essa confiança não se decreta. Na prática, apenas alguns grandes atores publicaram e mantiveram listas de « sealers de confiança », e a coordenação entre domínios em larga escala nunca se firmou. Um mecanismo cujo valor depende de uma confiança generalizada perde o seu interesse quando essa confiança permanece restrita a um punhado de operadores.

Uma falha de fundo que o ARC não fecha

O ARC documenta uma cadeia de resultados de autenticação, mas não protege contra o replay (« reenvio abusivo »). Uma mensagem legitimamente assinada pode ser capturada e reenviada em massa sem que a assinatura seja invalidada, porque nem o DKIM nem o ARC vinculam a assinatura ao envelope nem à rota real da mensagem. O ARC adiciona rastreabilidade, não uma garantia de integridade de ponta a ponta. A comunidade acabou considerando que investir mais no ARC equivalia a reforçar um curativo em vez de tratar a ferida.

Um esforço que se concentra no sucessor

A IETF prefere orientar o trabalho para um mecanismo que ataque a causa, em vez de continuar a refinar o ARC. Esse sucessor é o DKIM2, em processo de padronização, que assina ao mesmo tempo a origem e o destino de cada salto e fecha a falha de replay. Reclassificar o ARC como Historic é também um sinal de rumo: não gaste mais energia em estender o ARC, olhe para o DKIM2. Voltamos a isso no fim do artigo.

O paradoxo: o ARC continua exigido na prática em 2026

Eis o que as manchetes alarmistas esquecem. No exato momento em que a IETF coloca o ARC entre os padrões históricos, os três maiores fornecedores de e-mail do mundo o utilizam ativamente. Para uma caixa de entrada, o ARC está bem vivo.

Apple e iCloud: ARC para os grandes remetentes

Desde 25 de fevereiro de 2025, a Apple aplica exigências reforçadas para os remetentes de alto volume rumo ao iCloud. A sua documentação descreve explicitamente o uso do ARC para preservar os resultados de autenticação quando uma mensagem transita por um intermediário antes de chegar a uma caixa iCloud. Por outras palavras, um fornecedor que reenvia mensagens para o iCloud e que sela corretamente a cadeia ARC tem o seu tráfego mais bem tratado do que aquele que não faz isso.

Google e Gmail: os forwarders assinam, o Gmail lê arc=pass

O Gmail é provavelmente o maior utilizador de ARC do mundo. Quando uma mensagem é reencaminhada (redirecionamento automático, alias, lista de distribuição passando pela infraestrutura do Google), os forwarders do Google aplicam cabeçalhos ARC. Na receção, o Gmail lê o resultado arc=pass para reconhecer que a autenticação de origem era válida antes do reencaminhamento, e evita assim reprovar o DMARC em uma mensagem legítima apenas porque ela foi retransmitida. Aqui o ARC é uma engrenagem diária da entregabilidade, invisível mas decisiva.

Microsoft 365: trusted sealers e reason code 130

O Microsoft 365 integra o ARC ao seu veredito de autenticação composto. Quando uma mensagem teria reprovado no DMARC por causa de um reencaminhamento, mas um « trusted sealer » ARC preservou os resultados de origem, o Exchange Online Protection pode recuperar a mensagem e regista o reason code 130 no seu cabeçalho compauth. Esse código indica precisamente que um selo ARC de confiança substituiu uma reprovação DMARC. O mecanismo dos trusted sealers, do reason code 130 e do indicador oda=1 é detalhado em nosso guia Compauth=fail no Microsoft 365.

Depreciado no papel, não morto na caixa de entrada

O contraste é nítido. Na IETF, o ARC torna-se « Historic ». Nas infraestruturas da Apple, do Google e da Microsoft, o ARC continua um sinal lido e aproveitado todos os dias. Esses dois factos não se contradizem. O status Historic diz « não construa mais novas dependências ARC e não conte com ele para o futuro »; ele não diz « pare imediatamente de tratar as cadeias ARC que os grandes operadores ainda produzem ». Confundir os dois é ler um draft de padronização como um comunicado de descontinuação de serviço.

O problema de fundo não desapareceu: o reencaminhamento quebra SPF, DKIM e DMARC

Se o ARC é considerado insuficiente, o problema que ele visava continua inteiro. Entender esse problema ajuda a decidir o que deve fazer (ou não fazer).

Porque um redirecionamento ou uma lista de distribuição quebra a autenticação?

O reencaminhamento de mensagens compromete os três pilares da autenticação, cada um à sua maneira.

O SPF falha porque verifica o endereço IP emissor em relação ao domínio do envelope. Quando um servidor de redirecionamento reenvia a mensagem, é o seu IP que se apresenta ao destinatário, e esse IP quase nunca está declarado no SPF do domínio de origem. Resultado: o SPF deixa de se alinhar.

O DKIM falha assim que o intermediário modifica a mensagem. Uma lista de distribuição que adiciona um rodapé, reescreve o assunto com um prefixo [Lista] ou retoca um cabeçalho quebra o hash assinado. A assinatura DKIM, que cobre o corpo e certos cabeçalhos, torna-se inválida.

O DMARC, que se apoia no alinhamento do SPF ou do DKIM com o domínio do From:, falha por sua vez assim que os dois quebram ao mesmo tempo. Uma mensagem perfeitamente legítima acaba em dmarc=fail após um simples reencaminhamento. É esse cenário, comum, que o ARC buscava recuperar ao transportar a prova de que a autenticação estava boa antes do relay.

O ARC era um curativo, não um remédio

O ARC nunca reparou o SPF nem o DKIM. Ele acrescentou uma camada de testemunho: « no momento em que recebi esta mensagem, eis os resultados de autenticação que constatei, e eu os selo ». Útil, mas condicionado à confiança que o receptor deposita no selador, e impotente diante do replay. É justamente por isso que a resposta duradoura não consiste em empilhar ARC, mas em reforçar o que realmente controla: a sua própria autenticação. O futuro padrão DMARCbis, que detalhamos no guia DMARCbis, aliás esclarece o alinhamento e a gestão das políticas, sem fazer a sua conformidade depender de um mecanismo de terceiros.

Quem faz o quê: proprietário de domínio ou intermediário?

Esta é a secção mais importante para decidir. A confusão mais difundida consiste em acreditar que toda a gente « implementa ARC ». Falso. O ARC é um mecanismo de intermediário. A grande maioria dos leitores deste artigo nunca teve, e nunca terá, de implantá-lo.

É proprietário de um domínio: não implementa ARC

Se gere o envio de mensagens para a sua organização (um site, uma loja, notificações transacionais, uma equipa comercial), é um proprietário de domínio, não um intermediário. Não sela cadeias ARC, e o status Historic não lhe exige qualquer ação sobre o ARC. O que deve fazer diz respeito à sua própria autenticação:

1. Reforce o SPF. Declare todas as suas fontes de envio, monitorize o limite de 10 consultas DNS que provoca um permerror, e evolua o mecanismo final de ~all para -all quando dominar as suas fontes.
2. Solidifique o DKIM. Assine todos os seus fluxos com uma chave alinhada ao seu domínio, e organize uma rotação de chaves regular.
3. Faça o DMARC avançar. Passe de p=none (observação) para uma política de aplicação (p=quarantine e depois p=reject) assim que as suas fontes estiverem sob controlo.
4. Monitorize os seus relatórios DMARC. Os relatórios agregados revelam precisamente o que quebra no reencaminhamento e quais fontes falham. É o seu painel.
5. Não adicione ARC como remendo. Não pode « ativar o ARC » para reparar um reencaminhamento sofrido a jusante: seria papel do intermediário selar, não seu. Concentre o esforço no que controla.

Para verificar o estado real da sua autenticação e a forma como as suas mensagens são recebidas, um teste de entregabilidade vale mais do que uma suposição; nosso guia do teste de entregabilidade explica como ler os resultados.

É um intermediário: continue a selar ARC

Se opera um serviço que reenvia mensagens para terceiros (um forwarder, uma plataforma de listas de distribuição, um gateway de segurança, um fornecedor de redirecionamento), está envolvido com o ARC, e a sua conduta a adotar é sutil.

Primeiro, não corte nada bruscamente. Apple, Google e Microsoft ainda leem as cadeias ARC para recuperar mensagens legítimas reencaminhadas. Parar de selar do dia para a noite degradaria a entregabilidade das mensagens que retransmite para esses destinatários. O status Historic não o obriga de forma alguma a parar.

Em seguida, leia Historic como uma instrução de rumo, não de parada. Não construa nova dependência ARC que pressuponha uma confiança entre domínios generalizada, não invista em extensões ARC ambiciosas, e prepare a transição para o sucessor. Acompanhe a evolução do processo da IETF e os anúncios dos grandes receptores: são eles que, na prática, definirão o ritmo real da saída do ARC.

E depois? DKIM2, o sucessor

Reclassificar o ARC como Historic só faz sentido porque uma ferramenta melhor está a chegar. Esse sucessor é o DKIM2.

O que o DKIM2 corrige

O DKIM2 muda a abordagem. Onde o DKIM assina o conteúdo e onde o ARC acrescenta um testemunho selado, o DKIM2 faz assinar cada salto SMTP vinculando a origem e o destino da mensagem. Cada relay adiciona a sua própria assinatura numerada, e o envelope usado em cada salto é coberto. Consequência direta: o replay, aquela falha que nenhum dos dois mecanismos anteriores fechava, torna-se detetável, porque uma mensagem reenviada fora da sua rota assinada não corresponde mais à cadeia esperada. O DKIM2 trata a causa onde o ARC tratava o sintoma.

Cronograma e o que isso muda para si

O DKIM2 ainda está no estágio dos Internet-Drafts na IETF. A sintaxe exata dos cabeçalhos e dos parâmetros pode mudar, e as primeiras implantações só são esperadas a partir do fim de 2026. Para si, enquanto proprietário de domínio, isso não exige nenhuma ação hoje: não há nada a publicar nem a configurar para o DKIM2 por enquanto. A postura certa é a monitorização. Entender os princípios, acompanhar os drafts e manter uma infraestrutura DKIM saudável, pois o DKIM2 se apoiará nas mesmas fundações DNS. Nosso artigo DKIM2: em que ponto está a normalização detalha os novos cabeçalhos e a cronologia dos drafts.

Conclusão: pânico evitado, rumo ao DKIM2

A notícia é real, mas benigna. A IETF reclassifica o ARC como « Historic »: um sinal de fim de ciclo, não uma descontinuação de serviço. Recapitulando conforme o seu papel.

Se é proprietário de um domínio, não tem nada a fazer com o ARC, nem ontem nem hoje. Reforce SPF, DKIM e DMARC, monitorize os seus relatórios e nunca adicione ARC como remendo.

Se é um intermediário, continue a selar ARC enquanto Apple, Google e Microsoft o leem, mas não construa mais nenhuma nova dependência sobre ele e prepare a transição.

E para toda a gente, o rumo é o mesmo: a próxima etapa da autenticação de e-mail chama-se DKIM2. Nada a fazer hoje, tudo a entender para amanhã.

FAQ

O ARC está morto ou abandonado em 2026?

Não. A IETF reclassifica o ARC (RFC 8617) como status « Historic » por meio do draft draft-ietf-dmarc-arc-to-historic, depositado em 22 de abril de 2026. « Historic » desencoraja as novas implantações e sinaliza que a comunidade não aposta mais no ARC para o futuro, mas não invalida a especificação e não obriga ninguém a parar de produzir ou de verificar cadeias ARC. Na prática, Apple, Google e Microsoft ainda o utilizam ativamente.

Ainda é preciso implementar ARC em 2026 se ainda não o tem?

Para a grande maioria das organizações, não. O ARC é um mecanismo de intermediário (forwarders, listas de distribuição, gateways), não um protocolo que os proprietários de domínio publicam por conta própria. Se gere o envio de mensagens para a sua organização, nunca precisou de implantar o ARC, e o status Historic não muda isso. Concentre-se em SPF, DKIM e DMARC.

Eu já implantei ARC em um forwarder ou em um gateway: devo removê-lo?

Não, não corte nada bruscamente. Apple, Google e Microsoft ainda leem as cadeias ARC para recuperar mensagens legítimas reencaminhadas. Parar de selar degradaria a entregabilidade das mensagens que retransmite para esses destinatários. O status Historic apenas convida-o a não construir nova dependência ARC e a preparar a transição para o DKIM2, não a parar imediatamente.

É preciso continuar a verificar os cabeçalhos ARC na receção?

Sim, se opera um receptor que já se apoia no ARC. O status Historic não pede para parar de verificar as cadeias existentes. Os grandes fornecedores continuam a ler arc=pass para evitar reprovar o DMARC em mensagens reencaminhadas legítimas. Enquanto essas cadeias circulam, ignorá-las penalizaria mensagens legítimas.

ARC contra DKIM2: o que substitui o ARC, e quando?

O sucessor é o DKIM2, em processo de padronização na IETF. Ao contrário do ARC, que acrescenta um testemunho selado sem fechar a falha de replay, o DKIM2 faz assinar cada salto vinculando a origem e o destino, o que torna o replay detetável. O DKIM2 ainda está no estágio dos drafts; as primeiras implantações só são esperadas a partir do fim de 2026. Nenhuma ação é necessária hoje, apenas monitorização.

A RFC 8617 vai ser removida ou ficar inválida com o status Historic?

Não. O status « Historic », no sentido do processo da IETF, não remove nem invalida um documento. A RFC 8617 continua publicada, legível e tecnicamente válida: os cabeçalhos ARC continuam sintaticamente corretos e as implementações existentes continuam a funcionar. Historic é um sinal documental que desencoraja os novos usos, não uma retirada da especificação.

O ARC resolvia o problema do reencaminhamento que quebra o DMARC: esse problema está resolvido de outra forma?

Ainda não completamente. O reencaminhamento quebra o SPF (o IP do relay não está no SPF de origem) e muitas vezes o DKIM (modificação do corpo ou dos cabeçalhos), então o DMARC falha. O ARC era um curativo que transportava a prova de autenticação de antes do relay. A resposta duradoura consiste em reforçar os seus próprios SPF, DKIM e DMARC, monitorizar os seus relatórios e acompanhar o DKIM2, que ataca a causa ao assinar cada salto.

« Historic » na IETF: o que isso muda concretamente para um administrador?

Para um administrador de domínio, no curto prazo: nada. Não implementa ARC, então o status não afeta a sua configuração. O que vale lembrar é o rumo: não aposte no ARC para novos projetos, reforce a sua própria autenticação e prepare-se mentalmente para o DKIM2. Para um operador intermediário, a mudança é uma instrução de trajetória, não uma ordem de parada imediata.

Descarregue as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.

• Linha do tempo da IETF (CSV)
• Linha do tempo da IETF (JSON)
• Matriz de quem faz o quê (CSV)
• Matriz de quem faz o quê (JSON)

📖 Glossário

• Historic (status IETF): classificação do processo de padronização (RFC 2026) indicando que um protocolo não é mais recomendado para novas implantações, sem ser invalidado nem proibido.
• RFC 8617: a especificação do ARC (Authenticated Received Chain), publicada em 2019.
• ARC (Authenticated Received Chain): mecanismo pelo qual um intermediário sela os resultados de autenticação observados antes de reenviar uma mensagem.
• Trusted sealer: intermediário cuja assinatura ARC é considerada fiável por um receptor, por exemplo o Microsoft 365.
• Replay (reenvio abusivo): reutilização indevida de uma mensagem legitimamente assinada, reenviada sem invalidar a assinatura; falha que o ARC não fecha e que o DKIM2 busca corrigir.
• DKIM2: sucessor em processo de padronização na IETF, que assina a origem e o destino de cada salto para resistir ao replay e ao reencaminhamento.

Fontes

• draft-ietf-dmarc-arc-to-historic (IETF Datatracker)
• RFC 8617: The Authenticated Received Chain (ARC) Protocol
• Charter do grupo de trabalho DMARC da IETF
• Apple: exigências para os remetentes de mensagens rumo ao iCloud
• Google: prevenir a rejeição ou a marcação como spam dos e-mails reencaminhados (ARC)