Após a atualização do rascunho DKIM2 em 2026, os desenvolvedores precisam alterar os testes de e-mail?

A versão draft-ietf-dkim-dkim2-spec-09, publicada em 1º de novembro de 2026, ainda é um Internet-Draft ativo, não um RFC publicado, conforme o registro do documento no Datatracker do IETF. Portanto, não substitua seus testes DKIM atuais nem altere o fluxo de envio em produção só por causa dessa atualização. Continue validando a assinatura DKIM que seu produto realmente usa e a chegada das mensagens. Só teste DKIM2 em paralelo se sua própria cadeia de testes tiver uma implementação identificável e meios para verificar o resultado.

Esta análise é para você que mantém o envio de e-mails e a autenticação de domínio do seu produto.
Também atende equipes de QA que precisam separar evidência de assinatura de evidência de recebimento.
Se você decide sobre experimentos de autenticação, use os critérios abaixo antes de reservar tempo de implementação.

Última atualização: 7 de novembro de 2026. A verificação de estado e versão foi feita com o registro do DKIM2 e o histórico do documento no Datatracker do IETF, a página de documentos do grupo de trabalho DKIM e as informações da especificação DKIM atual, RFC 6376. A versão e o estado de um rascunho podem mudar; confira esses registros novamente antes de alterar uma suíte de testes.

Maturidade: o que a versão do rascunho permite concluir

O Datatracker lista o documento de assinatura DKIM2 como um Internet-Draft ativo. Na verificação feita em 7 de novembro de 2026, a versão indicada era draft-ietf-dkim-dkim2-spec-09, com data de publicação de 1º de novembro de 2026. Esses são dados de estado e versão, não uma declaração de que o protocolo foi finalizado ou implantado por provedores.

A distinção importa para quem mantém um produto. Um Internet-Draft registra uma proposta em discussão e pode ser revisado. Ele não equivale a um padrão publicado, não garante compatibilidade entre implementações e não informa, por si só, quais serviços de recebimento aceitam uma determinada implementação. Para acompanhar mudanças, consulte tanto a página do documento quanto os materiais do grupo de trabalho. Evite usar notícias, previsões ou comentários de terceiros como prova de uma decisão formal ou de suporte em produção.

A referência para o fluxo DKIM que seu sistema já utiliza continua sendo a especificação publicada RFC 6376. A comparação adequada, portanto, não é “DKIM antigo versus DKIM2 pronto para substituir”. É “comportamento atual documentado e implementado versus uma proposta que ainda precisa amadurecer e ser adotada”. Se o seu produto não gera assinaturas DKIM2, não existe um resultado DKIM2 a exigir na regressão atual.

Compatibilidade: não transforme uma proposta em requisito de produção

O DKIM atual valida uma assinatura associada à mensagem. A especificação vigente fornece a base para interpretar essa assinatura e verificar o comportamento que você espera do seu sistema. O rascunho DKIM2 descreve uma abordagem que envolve registrar mudanças ao longo do processamento da mensagem e formar uma cadeia verificável. Isso não permite concluir que um servidor ou provedor específico já implementa o mecanismo.

Para transformar essa ideia em um teste executável, você precisa conhecer a implementação concreta sob teste: o que ela assina, em que etapa aplica o mecanismo, como representa as mudanças e qual ferramenta verifica o resultado. Esses detalhes dependem do rascunho e da implementação. Confira a terminologia e os requisitos diretamente no documento DKIM2 vigente; não adapte uma expectativa com base em uma versão anterior sem registrar essa diferença.

Mantenha separados os dois objetivos:

Regressão DKIM atual: verifica se a mensagem real do seu produto recebe a assinatura prevista pela configuração existente e se o resultado continua aceitável no destino controlado.
Experimento DKIM2: verifica uma implementação identificada contra uma versão declarada do rascunho, com configuração isolada e método de validação compatível.
Teste de recebimento: confirma que uma mensagem de teste chegou ao endereço controlado e pode ser inspecionada. Não prova, sozinho, que o DKIM2 foi assinado ou validado.

Essa separação evita um erro frequente em pipelines: adicionar uma expectativa “DKIM2 passou” quando o serviço de envio nem sequer produz essa assinatura. Uma falha desse tipo não revela um defeito do fluxo atual; revela que o teste pede uma capacidade que não foi implementada.

Evidências: assinatura, autenticação e chegada respondem a perguntas diferentes

Um resultado de autenticação no cabeçalho da mensagem é evidência sobre a avaliação que determinado sistema fez. O campo Authentication-Results é definido em RFC 8601. Ele pode ajudar você a entender o resultado registrado pelo destinatário, mas deve ser interpretado no contexto de quem o inseriu e da mensagem que foi examinada. Não trate qualquer texto com esse nome, copiado de uma fonte não confiável, como prova independente.

O cabeçalho DKIM-Signature e a validação correspondente servem para investigar a assinatura DKIM da mensagem. Guarde a mensagem original e os cabeçalhos completos para comparar o que o emissor produziu com o que chegou. Se o envio usa SMTP, os registros do lado emissor e as respostas de transporte ajudam a reconstruir o percurso; a RFC 5321 descreve o protocolo SMTP. Uma resposta de aceitação na transmissão, porém, não garante que a mensagem terminou na caixa de entrada: filtros, políticas e processamento posterior ainda podem influenciar o resultado.

Por fim, a mensagem visível em uma caixa controlada responde a outra pergunta: o fluxo conseguiu entregar uma cópia observável a esse destino? Você pode inspecionar conteúdo e cabeçalhos recebidos e comparar com os registros do emissor. Isso é útil para a aceitação do envio atual, mas não prova que uma assinatura DKIM2 foi gerada, que uma cadeia DKIM2 foi verificada ou que todos os destinatários terão o mesmo resultado.

Use a combinação de evidências conforme o objetivo:

Para autenticação DKIM atual, examine a mensagem e o resultado de validação da assinatura.
Para investigar uma tentativa de envio, compare o identificador e os registros do emissor com a resposta de transporte disponível.
Para confirmar recebimento em um destino de teste, confira se a mensagem chegou e se os cabeçalhos observados correspondem ao envio.
Para DKIM2, exija evidência produzida por uma implementação DKIM2 e verificada por um método compatível com a versão do rascunho.

Nenhuma dessas observações, isoladamente, garante a entrada na caixa principal, a ausência de filtragem ou a conclusão de uma ação do usuário. Se sua suíte também precisa distinguir tempo de espera, rejeição e entrega tardia, defina uma janela observável e registre o resultado em vez de converter “não apareceu ainda” em “DKIM falhou”. As considerações sobre janela de recebimento de uma mensagem de teste ajudam a separar a espera pela mensagem da análise de autenticação.

Decisão: continuar, experimentar ou aguardar

Opção	Quando escolher	O que validar	Limite da evidência
Continuar a regressão atual	Seu produto assina com DKIM atual e não tem uma implementação DKIM2 identificada	Assinatura DKIM esperada, resultado de autenticação disponível e recebimento da mensagem controlada	Não demonstra suporte ou conformidade DKIM2
Executar um experimento isolado	Você controla uma implementação DKIM2, um domínio de teste e um método de verificação compatível	Resultado da implementação contra a versão do rascunho registrada no experimento	Não deve ser apresentado como resultado de produção ou prova de adoção geral
Aguardar e acompanhar	Você não tem implementação, domínio controlado ou verificador adequado	A regressão DKIM existente; mudanças oficiais no documento e no estado	Não há base para criar uma asserção DKIM2 executável

Escolha a primeira opção se a cadeia de envio atual só oferece DKIM. Isso preserva um teste válido para o comportamento que seu produto realmente entrega. Escolha a segunda apenas se você consegue apontar para o componente que gera a assinatura experimental, controlar o domínio usado e reproduzir a verificação. Se uma dessas condições faltar, aguarde: um teste que não consegue produzir nem verificar a evidência não melhora a cobertura.

Na opção de aguardar, registre um gatilho de revisão, em vez de criar uma data arbitrária. Exemplos de gatilhos úteis são uma nova versão publicada no Datatracker, uma mudança explícita de estado no processo do IETF ou a disponibilidade de uma implementação interna com verificação reproduzível. Uma notícia sobre uma possível adoção pode motivar uma checagem, mas não deve, sem confirmação oficial, alterar o requisito de produção.

Custo e risco: mantenha o experimento fora da regressão principal

Um experimento de protocolo custa mais do que acrescentar uma linha de asserção. Você precisa rastrear a versão do documento, controlar a configuração, obter uma mensagem reproduzível e identificar qual ferramenta interpretou o resultado. Também precisa separar o efeito do componente DKIM2 dos filtros e mudanças que podem ocorrer durante o transporte.

Sem esse isolamento, surgem pelo menos três custos ocultos. Primeiro, uma mudança do rascunho pode tornar obsoleta uma expectativa que a equipe tratava como permanente. Segundo, diferenças entre ferramentas podem produzir resultados que parecem incompatíveis, embora cada uma esteja testando versões ou interpretações diferentes. Terceiro, uma falha experimental pode interromper a regressão do envio atual, mesmo que DKIM continue funcionando como esperado.

Separe os artefatos do experimento dos da regressão:

Identifique a versão completa do rascunho e a data em que a equipe a consultou.
Registre a implementação, a configuração de teste e o domínio controlado usados na execução.
Preserve a mensagem original e os cabeçalhos recebidos, sem substituir o material bruto por uma captura resumida.
Guarde o resultado do verificador junto com a versão e a configuração que o produziram.
Marque o resultado como experimental; não o use para declarar conformidade com um padrão publicado.
Ao atualizar o rascunho, revise primeiro os campos, os algoritmos e os requisitos relevantes. Só então decida se a expectativa isolada deve mudar.

Essa disciplina ajuda você a não confundir “passou com a versão testada” com “está compatível com qualquer versão futura”. Ela também mantém o histórico útil quando uma execução posterior divergir: você poderá comparar documentos, configuração, cabeçalhos e ferramenta, em vez de depender da memória de quem montou o teste.

Implementação: uma sequência prática para revisar sua suíte

Comece pelo fluxo que realmente envia as mensagens do seu produto. Não comece alterando o DNS nem trocando o provedor por causa de uma proposta. O primeiro objetivo é saber que comportamento a suíte já valida e que evidência está disponível.

Capture a mensagem enviada pelo fluxo atual. Use um cenário do seu próprio produto, em ambiente de teste ou autorizado. Preserve os cabeçalhos completos e o conteúdo recebido. Evite substituir a mensagem por um exemplo montado manualmente, porque ele pode não refletir o caminho real do emissor.
Confirme a assinatura que o produto pretende usar. Verifique a presença e o conteúdo da assinatura DKIM esperada segundo a configuração e a RFC 6376. Se não houver assinatura, investigue o fluxo de envio atual; não atribua automaticamente a falha à ausência de DKIM2.
Compare a mensagem observada com o resultado de autenticação. Consulte o campo Authentication-Results quando existir e identifique qual sistema o produziu. Compare essa informação com os cabeçalhos da mensagem e com os registros do emissor. Não trate um único campo como prova de que a mensagem chegou à caixa principal.
Confirme o recebimento em um endereço controlado. Inspecione a mensagem efetivamente recebida e registre se ela foi observada, rejeitada ou ainda não apareceu dentro da janela de teste definida pela equipe. O propósito é validar o caminho de envio e a observabilidade do teste, não inferir suporte a um protocolo que o emissor não implementa.
Procure evidência explícita de implementação DKIM2. Identifique o componente e a configuração que gerariam a assinatura experimental. Se ninguém consegue apontar para essa capacidade, deixe DKIM2 fora das asserções da suíte. Uma menção ao protocolo em documentação ou em uma discussão não equivale a suporte executável.
Se houver implementação, crie uma execução isolada. Use um domínio e uma configuração de teste controlados. Fixe a versão do rascunho e o verificador usados. Mantenha esse trabalho separado da aprovação de produção, para que uma alteração experimental não bloqueie a validação do envio DKIM atual.
Defina o que dispara uma revisão. Acompanhe os documentos do grupo de trabalho DKIM e o registro da especificação. Quando houver mudança de versão ou estado, compare o texto relevante e atualize o experimento somente depois de compreender a alteração. Registre por que a expectativa mudou e qual evidência passou a ser exigida.

O endereço usado na etapa de recebimento precisa ser controlado e adequado à finalidade. Um endereço temporário pode ajudar a observar uma mensagem de teste sem misturar esse fluxo à caixa principal, mas não substitui a inspeção de cabeçalhos nem o verificador do protocolo. Antes de adotá-lo no seu processo, confira as informações públicas do serviço e as condições do ciclo de vida de uma caixa de entrada temporária. O recebimento é uma parte da evidência; a validação DKIM2 continua dependendo de uma implementação e de um método de verificação compatíveis.

Perguntas frequentes

O DKIM2 já é um padrão oficial?

Não. Na consulta registrada em 7 de novembro de 2026, o Datatracker do IETF listava a especificação de assinatura DKIM2 como um Internet-Draft ativo. A versão indicada era draft-ietf-dkim-dkim2-spec-09, publicada em 1º de novembro de 2026. Um rascunho de trabalho não é um RFC publicado e não comprova implantação ampla por provedores de e-mail.

A atualização do DKIM2 muda meus testes de DKIM atuais?

Não por si só. Se seu produto assina mensagens com DKIM conforme a configuração atual, mantenha os testes dessa assinatura e da entrega real. Trate o DKIM2 como uma linha experimental separada, somente se houver implementação própria e um meio controlado de verificar o resultado. Não substitua uma validação funcional por uma expectativa baseada apenas no rascunho.

Devo verificar DKIM e DKIM2 ao mesmo tempo em cada mensagem de teste?

Verifique DKIM nas mensagens produzidas pelo fluxo atual. Só inclua uma asserção DKIM2 em uma execução isolada quando o sistema sob teste realmente gerar a assinatura experimental e você tiver um verificador compatível com a versão do rascunho. Caso contrário, essa asserção não valida o comportamento do produto e pode criar um falso bloqueio na regressão.

Como faço a validação se meu sistema não assina com DKIM2?

Continue testando a mensagem real do seu produto: confirme a assinatura DKIM esperada, examine o resultado de autenticação registrado pelo destinatário e confira se a mensagem chegou à caixa controlada. Registre essas evidências separadamente. Elas ajudam a validar o fluxo atual, mas não demonstram assinatura nem conformidade DKIM2.

Para validar o recebimento sem confundir as evidências

Se seu objetivo imediato é confirmar que uma mensagem do seu produto chegou a um destino controlado, o MyTempBox pode ser uma opção de recebimento para esse trecho do teste. Confira as capacidades descritas na página antes de incorporar o serviço ao fluxo. Use a mensagem recebida para inspecionar o resultado real de entrega e seus cabeçalhos; não a trate como prova de DKIM2, como garantia de chegada à caixa principal ou como substituto de um verificador compatível com o rascunho.

Perguntas frequentes

O DKIM2 já é um padrão oficial?

A atualização do DKIM2 muda meus testes de DKIM atuais?

Devo verificar DKIM e DKIM2 ao mesmo tempo em cada mensagem de teste?

Como faço a validação se meu sistema não assina com DKIM2?

Já confirmou que esta é uma tarefa curta e que pode ser refeita?

Abra uma caixa de entrada temporária e mantenha um único endereço até concluí-la. Se a tarefa se tornar permanente, migre primeiro o e-mail e só então encerre esta janela de recebimento.

Criar uma caixa de entrada descartável