Resumo
- A revisão 01 da draft de boas práticas de DKIM2 do grupo DKIM ficou disponível em 9 de setembro de 2026. Ela é um Internet-Draft ativo, não uma BCP publicada nem uma decisão do IETF de aposentar mecanismos existentes.
- O texto recomenda assinar mensagens de saída com DKIM1 e DKIM2 até o DKIM2 ser “efetivamente onipresente”, sem fixar limiar, denominador, período, população ou responsável pela declaração.
- Percentuais diários de um receptor ajudam esse receptor a ajustar sua política. Não medem remetentes, encaminhadores e redes de destino que ele não observa.
- Um registro de saída agregado pode preservar escopo, exceções, decisão e condição de retorno sem criar um limiar mundial. Essa é uma proposta editorial de Daniel Kade, não uma exigência da draft.
O documento sabe para onde ir, mas não quando chegou
A revisão 01 surgiu em 9 de setembro. Seu histórico de mudanças registra reorganização, novos títulos e alterações amplas, atribuídas tanto ao desenvolvimento dinâmico do DKIM2 quanto ao tempo desde a revisão 00. No Datatracker, ela aparece como WG Document do grupo DKIM e I-D Exists no IESG, sem shepherd, Area Director responsável ou data de telechat.
O cabeçalho do arquivo indica Best Current Practice como status pretendido; a ficha do Datatracker mostra, por enquanto, Intended RFC status: None. Esse desencontro não autoriza escolher a leitura mais avançada. A revisão continua sendo trabalho em curso e pode mudar, expirar ou não chegar a um RFC.
A orientação de coexistência é direta: o remetente deve aplicar DKIM1 e DKIM2 até que a implantação de DKIM2 seja “efetivamente onipresente”. O adjetivo aparece duas vezes, mas não vem acompanhado de uma medida. A draft não esclarece se a unidade é mensagem, domínio, organização, conexão ou cadeia completa. Não determina uma janela nem uma população geográfica ou operacional.
Também não há um declarante único. Um remetente controla sua assinatura; um receptor controla sua verificação e disposição; um encaminhador controla seu trecho. A working group controla o texto da draft, não cada operação de correio. Essa distribuição é saudável, desde que cada decisão de saída preserve seu próprio alcance.
Há ainda duas redundâncias diferentes. A seção 3.2 recomenda mais de uma assinatura DKIM2, com algoritmos distintos. A seção 3.3 mantém DKIM1 e DKIM2 juntos. Estar pronto para diversidade criptográfica dentro do DKIM2 não prova que todo parceiro está pronto para abandonar a compatibilidade com DKIM1.
Um percentual correto pode usar o universo errado
Quando não há DKIM2, o receptor capaz de verificar DKIM1 deve recorrer à política de disposição DKIM1 que já possui. A revisão permite que essa política evolua conforme o percentual diário de mensagens com e sem DKIM2 e a forma como os usuários das caixas postais interagem com os dois grupos. Durante a transição, porém, a simples ausência de DKIM2 não deve, sozinha, motivar rejeição.
Isso impede que adoção parcial vire erro automático. Também torna a ausência ambígua. Ela pode apontar um remetente ainda não participante, um encaminhador fora do sistema, uma exceção conhecida, uma assinatura retirada no caminho ou uma falha de classificação.
Cada receptor vê um universo diferente. Um provedor de e-mail ao consumidor recebe grandes campanhas; uma empresa concentra fornecedores e clientes; uma lista de discussão recria caminhos; um serviço regional pode ter forte viés geográfico. Contar mensagens dá peso desproporcional a grandes emissores. Contar domínios esconde a escala. Contar só o que passou por filtros já exclui parte da população.
Portanto, precisão estatística não é o mesmo que abrangência institucional. A matemática pode estar impecável e a inferência, larga demais. O painel local sustenta mudança local. Para uma alegação que atravesse organizações, precisam aparecer denominador, ponderação, exclusões e janela.
As três condições classificam caminhos, não a Internet
A seção 6 oferece três rótulos. Never Left significa que todo domínio administrativo participante assinou na saída. In and Out mostra que alguns trechos participaram e outros não. Never Entered descreve uma mensagem que chegou sem assinatura DKIM2. São estados observados de um caminho, não graus universais de implantação.
O papel do encaminhador torna essa distinção decisiva. Um encaminhador participante precisa tentar verificar as assinaturas DKIM2 e DKIM1 existentes e acrescentar DKIM2 a toda mensagem que manuseia, mesmo sem modificar o conteúdo. A assinatura é aplicada no último salto antes de a mensagem deixar sua infraestrutura. Uma cadeia pode, assim, depender de atores intermediários invisíveis numa simples contagem de remetentes e receptores.
A seção 7.1 espera que receptores passem a depender principalmente de DKIM2 quando a implantação amadurecer, evitando manter para sempre duas trilhas de verificação. Mas “amadurecer” também não recebe teste. É um destino operacional, não um marco verificável.
As seções cercadas por pontos de interrogação sobre DMARC e SPF precisam ser lidas com a ressalva da própria introdução: são questões não resolvidas, e o texto é especulativo. A revisão considera possibilidades futuras; não estabelece consenso para aposentar DKIM1, DMARC ou SPF.
A ausência de quem já assinava é um evento diferente
Na parte de segurança, a draft descreve um possível downgrade durante a coexistência. Quem consegue retirar uma assinatura DKIM2 poderia levar um receptor que ainda não tornou DKIM2 obrigatório a voltar para um tratamento mais fraco, baseado apenas em DKIM1. O texto recomenda escrutínio adicional quando um domínio conhecido por usar DKIM2 aparece com DKIM1 plausível, mas sem DKIM2.
Não há registro de ataque real nem taxa medida no pacote de fontes. Ainda assim, o exemplo mostra por que um único grupo “sem DKIM2” é insuficiente. Um domínio jamais observado com o novo mecanismo e um domínio cuja assinatura desapareceu depois de um histórico consistente não carregam o mesmo sinal.
Também mostra por que uma decisão de saída precisa nascer reversível. Um aumento abrupto de domínios conhecidos chegando só com DKIM1, queda de cadeias completas ou piora de entrega numa coorte de exceção devem poder acionar retorno segundo uma regra definida antes da mudança.
Um registro de saída limitado e comparável
Em vez de um certificado global de onipresença, proponho um registro por operador e por decisão. Ele incluiria:
- declarante, papel operacional e decisão sob seu controle;
- coortes de remetentes, encaminhadores e receptores avaliadas;
- denominador, ponderação, exclusões e período observado;
- taxas de presença, cadeia completa, cadeia parcial e ausência;
- resultados de verificação e indicadores de entrega ou uso realmente empregados;
- domínios conhecidos por DKIM2 que chegaram sem DKIM2;
- exceções que ainda dependem de DKIM1;
- limiar e versão da política aplicada;
- momento da decisão, gatilho de retorno e próxima revisão.
O relatório público pode agregar tudo isso. Não precisa expor endereço de destinatário, comportamento individual ou conteúdo de mensagem. Precisa, porém, dizer se a conclusão vale para prontidão local, uma coorte nomeada de interconexão ou um conjunto comunitário mais amplo.
É a aplicação da especificação inicial mínima defendida por Heng Lu: padronizar a menor evidência compartilhada que permita coordenação futura e manter a adoção voluntária nas mãos de quem suporta seus efeitos.
Limite da evidência
O histórico confirma datas e estados; o diff oficial entre 00 e 01 mostra a extensão da revisão. A especificação-base e o documento DNS também são drafts ativas.
Os RFCs citados estabelecem o contexto de DKIM, SPF, Authentication-Results e DMARC; não medem DKIM2. As fontes não trazem censo representativo, custo total, volume de ataques ou calendário de aposentadoria. Nenhum desses números é inferido aqui.
Fontes
- Registro atual no Datatracker
- Histórico do documento
- Boas práticas de DKIM2, revisão 01
- Boas práticas de DKIM2, revisão 00
- Diff oficial 00–01
- Grupo de trabalho DKIM
- Especificação-base DKIM2
- Publicação DNS de DKIM2
- Método proposto de Authentication-Results para DKIM2
- RFC 6376: DKIM
- RFC 6377
- RFC 7208: SPF
- RFC 8601: Authentication-Results
- RFC 8617: DMARC
- RFC 9989: DMARC
- RFC 6973: privacidade
- Heng Lu, Minimum Initial Specification
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

