DKIM2: o que há de novo, o que muda e as datas-chave

TL;DR — DKIM2 é uma reescrita que está avançando como Internet-Drafts no IETF. Ela busca assinar a origem e o destino de cada salto SMTP, encadear assinaturas (i=1, i=2, ...), documentar as modificações feitas pelos intermediários e tornar os bounces (DSN) rastreáveis ao longo da cadeia. DKIM2 ainda não é um padrão: evolui rapidamente, mas os blocos principais já existem.

ℹ️ Os termos DKIM replay e backscatter estão definidos no glossário ao final do artigo.

Por que falar de DKIM2 agora?

DKIM (STD 76, RFC 6376) é amplamente implantado para assinar o conteúdo dos e-mails. Mas ele mostra limites diante do DKIM replay, das modificações feitas por listas/forwarders e do backscatter (bounces enviados a terceiros). DKIM2 propõe um modelo em que cada relay adiciona sua própria assinatura numerada e declara explicitamente o par origem → destino do próximo salto, o que permite:

• detectar e limitar replays;
• encaminhar bounces e relatórios ao longo da rota autenticada;
• descrever e, quando possível, reverter alterações de corpo/header para validar a assinatura original.

Principais mudanças (em comparação com DKIM "v1")

1. Novo header DKIM2-Signature (sem campo de versão)

   • Numeração com i= (1, 2, ...). Um gap na sequência invalida a cadeia.
   • Timestamp t=; o verificador pode considerar a assinatura expirada após uma janela (ex.: 14 dias).
   • Algoritmos: RSA-SHA256 e Ed25519-SHA256 são o alvo inicial, com agilidade criptográfica planejada.
   • Chaves no DNS: como no DKIM, em selector._domainkey.domínio.

2. Encadeamento e alinhamento com o envelope SMTP

   • mf= (MAIL FROM) e rt= (RCPT TO) descrevem o envelope usado no salto assinado.
   • Cada novo salto precisa corresponder ao destino anterior (ou ser "proxy assinado" via pp=).
   • O verificador valida primeiro a assinatura mais recente (maior i).

3. Modelagem das modificações

   • O draft introduz o header MailVersion para descrever como retornar à versão anterior (receitas de corpo/header).
   • A assinatura carrega mv= para a versão da mensagem coberta.
   • Um campo f= (flags) pode indicar modifiedbody, modifiedheader, exploded, donotmodify, feedback etc.

4. Bounces e feedback

   • DSN e feedback são enviados de volta pela cadeia para um ator envolvido, limitando o backscatter.
   • Possibilidade de indicar preferências de feedback (dependendo da versão do draft).

5. Compatibilidade e coexistência

   • DKIM2 não torna DKIM (RFC 6376) obsoleto imediatamente: espera-se uma fase de transição com coexistência.
   • Os registros DNS permanecem em _domainkey. A assinatura por procuração (pp=) está prevista, com restrições de alinhamento e provas de autorização via DNS (ex.: registro dedicado ou relação MX), segundo os drafts.

O que desaparece ou muda significativamente

• Sem v= em DKIM2-Signature (se ocorrer uma ruptura grande, surgiria um futuro "DKIM3-Signature" em vez de aumentar um número interno).
• Lista simplificada de headers assinados: existe uma base de campos obrigatórios; h= continua disponível para casos específicos.
• Gestão de expiração simplificada: depende de t= e de recomendações do lado do verificador em vez de um campo estritamente normativo.
• Parâmetros herdados do DKIM considerados complexos demais (ex.: z=) são abandonados nos primeiros drafts.

⚠️ DKIM2 está em elaboração: a sintaxe exata (nomes de tags, flags, prazos) ainda pode mudar. Consulte as versões de draft citadas abaixo.

Exemplo de headers (drafts atuais)

DKIM2-Signature: i=1; t=2025-10-24T08:01:02Z; d=example.com; s=sel2025;
  a=ed25519-sha256; bh=BASE64(...); b=BASE64(...);
  rt=user@dest.tld; mf=bounce@example.com; mv=2; f=modifiedheader,feedback

MailVersion: v=2; bh=BASE64(...);
  h.Subject=d:*,t:[Re] Oferta especial;
  h.From=d:*,b=am9obi5kb2VAZXhhbXBsZS5jb20=

Impacto operacional (resumo)

• ESP / relays: assinar cada salto, gerenciar mf=/rt=, registrar/reverter modificações simples (receitas) e reenviar para domínios de destino alinhados.
• Destinatários: verificar primeiro a assinatura mais recente (i=Max) e voltar caso necessário; rejeitar cedo diante de falhas críticas.
• DNS: seletores e chaves inalterados em _domainkey; planejar autorizações "proxy" conforme o mecanismo DNS definido nos drafts.
• DMARC: enquanto DMARCbis fizer referência a DKIM (RFC 6376), DMARC continuará apoiado em DKIM. A migração DMARC→DKIM2 não é imediata.

Cronograma: marcos recentes

• 5 nov. 2024: primeiros artigos públicos de análise sobre DKIM2 (ex.: Red Sift).
• 20 nov. 2024: posts de anúncio por fornecedores DMARC.
• 3 set. 2025: o grupo de trabalho do IETF adota o documento Motivation (draft-ietf-dkim-dkim2-motivation-01).
• 17–20 out. 2025: publicação dos drafts -spec-02 (especificação), -dns-03 (DNS), -header-04 (headers) e -modification-algebra-04 (MailVersion).

Plano de preparação

1. Inventariar onde você já assina/verifica DKIM (fluxos, saltos, SRS/VERP, listas).
2. Prototipar nos relays: calcular mf=/rt=, adicionar i=, escolher algoritmos (Ed25519 recomendado) e gerenciar t=.
3. Mapear modificações comuns (rodapés de listas, reescrita de From:) e testar a reversão via MailVersion.
4. DNS: padronizar o ciclo de rotação de chaves; preparar o mecanismo de autorização "proxy" se necessário.
5. Verificação: aplicar a estratégia "último i= primeiro", devolver 5xx durante a troca SMTP quando a assinatura falhar, 4xx em caso de TEMPFAIL de DNS.
6. Monitorar os drafts (abaixo) e planejar feature flags para acompanhar mudanças de campo.

Glossário

DKIM replay

• Definição: reutilização (replay) de uma mensagem já assinada com DKIM por um domínio legítimo para reenviá-la em massa ou a outros alvos sem alterar o que a assinatura cobre. A assinatura permanece válida porque DKIM assina o conteúdo (corpo/headers), mas não o envelope SMTP nem a rota.
• Por quê?: um atacante obtém a cópia de um e-mail assinado (ex.: newsletter) e o redistribui como está; DMARC pode continuar aprovando se From: permanecer alinhado.
• Sintomas: picos de volume na mesma assinatura (bh= idêntico), reclamações de spam, reputação do domínio assinante degradada.
• Mitigações: limitar taxa por seletor, girar chaves, definir vencimentos curtos, endurecer DMARC (p=reject), filtragem comportamental na recepção.
• O que DKIM2 muda: a assinatura inclui o envelope por salto (mf=/rt=) e encadeia a rota (número i=), tornando o replay detectável (rota incoerente) e permitindo ações direcionadas.

Backscatter

• Definição: bounces não solicitados (NDR/DSN) ou auto-respostas enviadas a um terceiro inocente cujo endereço foi falsificado em MAIL FROM/Return-Path.
• Por quê?: servidores aceitam a mensagem primeiro e geram um bounce posterior; com endereço falsificado, o bounce volta para a vítima.
• Sintomas: enxurradas de DSN/auto-respostas em uma caixa legítima, reputação comprometida, possíveis listas de bloqueio.
• Mitigações: rejeitar durante a troca SMTP (não depois), SPF/DMARC rigorosos, SRS/VERP para rastrear bounces, regras contra auto-respostas.
• O que DKIM2 muda: DSN/feedback podem ser encaminhados para cima pela cadeia assinada, o que reduz o backscatter e faz o aviso chegar ao ator realmente envolvido.

Fontes e leituras recomendadas

• DKIM2 – especificação: draft-clayton-dkim2-spec-02 (20 de outubro de 2025, expira em 23 de abril de 2026).
• DKIM2 – DNS: draft-chuang-dkim2-dns-03 (20 de outubro de 2025).
• DKIM2 – headers: draft-gondwana-dkim2-header-04 (20 de outubro de 2025).
• DKIM2 – álgebra de modificações / MailVersion: draft-gondwana-dkim2-modification-algebra-04 (17 de outubro de 2025).
• Motivation (documento do grupo de trabalho do IETF): draft-ietf-dkim-dkim2-motivation-01 (3 de setembro de 2025, substitui as versões individuais).
• Recap DKIM: RFC 6376; atualizações: RFC 8301, RFC 8463.

DKIM2 continua sendo um trabalho em andamento. Atualizaremos esta página conforme os drafts avançarem para uma RFC.