ARC passa ao status « Historic » na IETF: ainda vale a pena se preocupar em 2026?
Por CaptainDNS
Publicado em 8 de junho de 2026
- 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 você é proprietário de um domínio, provavelmente não tem nada a fazer com o ARC: reforce SPF, DKIM e DMARC, monitore 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 provedor 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 fato, por que a IETF decidiu assim e o que você 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, equipes DevOps e responsáveis por entregabilidade que leram uma manchete alarmista e querem uma decisão clara.
Verifique sua autenticação de e-mail em vez de adicionar ARC
A notícia, explicada corretamente: ARC rumo a « Historic » na IETF
Vamos começar estabelecendo os fatos, 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.
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 registra 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 se concentra agora em outro lugar.
Cronograma: rechartering do grupo DMARC e prazo
Essa iniciativa se insere 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 seu status atual; mas a trajetória é clara e pública.
O que « Historic » significa de fato (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 sua adoção não acompanhou, ou porque a experiência mostrou 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 sendo um documento publicado e legível, 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.
Por que essa virada? As razões da IETF
O ARC foi concebido para resolver um problema real e persistente: o encaminhamento de mensagens quebra a autenticação. A ideia era elegante. Por que, 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 se baseia 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 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 provedores 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. 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. Em outras palavras, um provedor que reenvia mensagens para o iCloud e que sela corretamente a cadeia ARC tem 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 usuário de ARC do mundo. Quando uma mensagem é encaminhada (redirecionamento automático, alias, lista de distribuição passando pela infraestrutura do Google), os forwarders do Google aplicam cabeçalhos ARC. Na recepção, o Gmail lê o resultado arc=pass para reconhecer que a autenticação de origem era válida antes do encaminhamento, 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 encaminhamento, mas um « trusted sealer » ARC preservou os resultados de origem, o Exchange Online Protection pode recuperar a mensagem e registra o reason code 130 em 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 fatos 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 encaminhamento 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 você deve fazer (ou não fazer).
Por que um redirecionamento ou uma lista de distribuição quebra a autenticação?
O encaminhamento 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 encaminhamento. É 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 você realmente controla: 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 sua conformidade depender de um mecanismo de terceiros.
Quem faz o quê: proprietário de domínio ou intermediário?
Esta é a seção mais importante para decidir. A confusão mais difundida consiste em acreditar que todo mundo « 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.
Você é proprietário de um domínio: você não implementa ARC
Se você gerencia o envio de mensagens para sua organização (um site, uma loja, notificações transacionais, uma equipe comercial), você é um proprietário de domínio, não um intermediário. Você não sela cadeias ARC, e o status Historic não exige de você nenhuma ação sobre o ARC. O que você deve fazer diz respeito à sua própria autenticação:
- Reforce o SPF. Declare todas as suas fontes de envio, monitore o limite de 10 consultas DNS que provoca um
permerror, e evolua o mecanismo final de~allpara-allquando dominar suas fontes. - Solidifique o DKIM. Assine todos os seus fluxos com uma chave alinhada ao seu domínio, e organize uma rotação de chaves regular.
- Faça o DMARC avançar. Passe de
p=none(observação) para uma política de aplicação (p=quarantinee depoisp=reject) assim que suas fontes estiverem sob controle. - Monitore seus relatórios DMARC. Os relatórios agregados revelam precisamente o que quebra no encaminhamento e quais fontes falham. É o seu painel.
- Não adicione ARC como remendo. Você não pode « ativar o ARC » para reparar um encaminhamento sofrido a jusante: seria papel do intermediário selar, não seu. Concentre o esforço no que você controla.
Para verificar o estado real da sua autenticação e a forma como 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.
Você é um intermediário: continue a selar ARC
Se você opera um serviço que reenvia mensagens para terceiros (um forwarder, uma plataforma de listas de distribuição, um gateway de segurança, um provedor de redirecionamento), você está envolvido com o ARC, e 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 encaminhadas. Parar de selar do dia para a noite degradaria a entregabilidade das mensagens que você retransmite para esses destinatários. O status Historic não obriga você 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á chegando. 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 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 detectável, porque uma mensagem reenviada fora de 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 você
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 você, 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 é o monitoramento. 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: novidades, remoções e datas-chave 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 você é proprietário de um domínio, não tem nada a fazer com o ARC, nem ontem nem hoje. Reforce SPF, DKIM e DMARC, monitore seus relatórios e nunca adicione ARC como remendo.
Se você é 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 todo mundo, 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 você 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 você gerencia o envio de mensagens para sua organização, nunca precisou 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 encaminhadas. Parar de selar degradaria a entregabilidade das mensagens que você retransmite para esses destinatários. O status Historic apenas convida você 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 recepção?
Sim, se você opera um receptor que já se apoia no ARC. O status Historic não pede para parar de verificar as cadeias existentes. Os grandes provedores continuam a ler arc=pass para evitar reprovar o DMARC em mensagens encaminhadas 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 detectá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 monitoramento.
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 encaminhamento que quebra o DMARC: esse problema está resolvido de outra forma?
Ainda não completamente. O encaminhamento 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 seus próprios SPF, DKIM e DMARC, monitorar 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. Você não implementa ARC, então o status não afeta sua configuração. O que vale lembrar é o rumo: não aposte no ARC para novos projetos, reforce 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.
Baixe as tabelas comparativas
Assistentes conseguem reutilizar os números consultando os arquivos JSON ou CSV abaixo.
📖 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 confiá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 encaminhamento.
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 encaminhados (ARC)
