Em março de 2026, durante um teste de roteamento interno, uma equipa de deliverability de um ESP europeu constata que os seus emails para listas de discussão Mailman falham sistematicamente na verificação DKIM, apesar de as chaves estarem corretamente configuradas. A mensagem é legítima, o domínio está em ordem, a lista é opt-in. No entanto, o Mailman reescreveu o cabeçalho From e a assinatura DKIM1 perdeu a validade nesse momento. DKIM2 visa corrigir este tipo de falha. O grupo de trabalho IETF dkim adotou os primeiros rascunhos do protocolo em março de 2026: ainda não é um RFC, nenhum deployment em produção, mas uma arquitetura que distribui a verificação em todo o caminho de entrega.
Porque o DKIM1 atinge os seus limites em 2026
O DKIM1, formalizado na RFC 6376 em 2011, cobre um âmbito específico: prova que o domínio signatário emitiu efetivamente a mensagem na origem. A especificação não sobrevive aos intermediários. Cada servidor que lida com a mensagem pode invalidar a assinatura: uma lista de discussão que acrescenta um rodapé, uma gateway de segurança que reescreve os URLs, um forwarder que modifica o envelope SMTP. Com uma adoção do DKIM perto dos 90% nos emails diretos em 2026, poder-se-ia pensar que o problema está resolvido. Mas essa taxa mede o sucesso nos emails que chegam diretamente, não aqueles que passam por listas de discussão ou forwarders.
O draft IETF draft-ietf-dkim-dkim2-motivation documenta três falhas estruturais que o DKIM1 não consegue corrigir. Primeiro: um email validamente assinado pode ser recebido sem qualquer prova de que o destinatário era efetivamente o destinatário pretendido. Segundo: o endereço de resposta pode referenciar domínios que não tiveram qualquer papel no trânsito da mensagem. Terceiro: não existe mecanismo para documentar as alterações legítimas dos forwarders ou das listas de discussão. Essas lacunas prendem-se com a própria concepção do protocolo original, não a erros de configuração.
Desde 2024, Google e Yahoo tornaram obrigatórios SPF, DKIM e DMARC para envios em massa. Esta pressão acelerou a adoção sem resolver os problemas arquiteturais. O trabalho foi delegado ao WG IETF dkim, que opera em vários rascunhos complementares: especificação principal, documento de motivação, perfil de deployment via interface Milter e guia de boas práticas.
A chain of signatures: sobreviver aos intermediários
O mecanismo central do DKIM2 chama-se cadeia de assinaturas. Em vez de pedir que cada servidor valide uma assinatura única emitida na origem, o protocolo exige que cada intermediário documente as modificações que efetuou e assine essa documentação. O destinatário final reconstitui assim a sequência completa das transformações e verifica a legitimidade de cada uma.
Richard Clayton, coautor da especificação DKIM2, descreve a abordagem como uma « modificação algébrica »: os intermediários especificam a natureza exata das suas modificações em vez de aplicar um simples carimbo de aceitação. Uma lista de discussão que acrescenta um rodapé declara-o na sua assinatura. Um gateway de segurança que reescreve URLs faz o mesmo. O destinatário avalia então se cada transformação era esperada e autorizada.
No terreno, os falsos positivos relacionados com as listas de discussão, atualmente uma fonte frequente de invalidação do DKIM1, saem do perímetro de responsabilidade do remetente. Clayton indicou em abril de 2026 que já existe código funcional e que são esperados testes junto de mailbox providers nos próximos meses. A especificação técnica principal (draft-ietf-dkim-dkim2-spec-01) tem data de 20 de abril de 2026.
DSNs assíncronos e VERP: eliminar o backscatter
O segundo ângulo técnico do DKIM2 aborda um problema menos visível mas dispendioso para a reputação dos remetentes: o backscatter. Quando um spammer falsifica o endereço de retorno com o domínio de um terceiro inocente, os bounces gerados por servidores legítimos caem na caixa desse inocente. IPs e domínios limpos acabam em listas negras devido a tráfego que nunca emitiram.
Steve Atkins da Word to the Wise, acompanha o dossiê há várias semanas, destaca que o DKIM2 resolve este problema através de dois mecanismos combinados. As Delivery Status Notifications (DSN) assíncronas permitem que um servidor aceite uma mensagem em SMTP e notifique a falha mais tarde, após análise completa. VERP (Variable Envelope Return Path) codifica as metadados necessárias diretamente no endereço de retorno, o que evita analisar o corpo do bounce. A combinação de ambos, de acordo com a Word to the Wise de 27 de abril de 2026, permite « reconhecer imediatamente o bounce e ignorar o DSN assíncrono sem qualquer tratamento ou armazenamento adicional. »
Para os managers de deliverability, os bounces no DKIM2 seguem um caminho criptograficamente assinado, retornando ao servidor anterior na cadeia em vez de para um endereço falsificado. O backscatter perde a sua principal superfície de ataque. Atkins avisa que os volumes de bounces assíncronos podem aumentar de vários ordens de magnitude durante o deployment inicial. Será necessária uma capacidade inbound aumentada do lado do ESP.
Anti-replay: timestamps e recipient binding
O DKIM1 apresenta uma vulnerabilidade conhecida mas subestimada: o replay attack. Uma assinatura DKIM válida pode ser reutilizada para enviar a mesma mensagem a destinatários não previstos. O atacante obtém um email legítimo, mantém a sua assinatura intacta e redistribui-o em grande escala. Os filtros de anti-spam veem uma assinatura válida e permitem a passagem.
O DKIM2 fecha esta janela através de dois mecanismos complementares. As assinaturas agora incluem os dados do envelope SMTP: remetente e destinatário. Uma mensagem assinada para alice@example.com não pode ser enviada para bob@example.com sem invalidar a assinatura. Flags controlam também a distribuição autorizada da mensagem. Este mecanismo de recipient binding, como destaca Al Iverson da SpamResource (que acompanha os trabalhos do WG IETF DKIM), poderia alterar a superfície de ataque das campanhas de spam mais sofisticadas.
Os timestamps completam o dispositivo. Uma assinatura DKIM2 tem uma validade temporal explícita, impedindo a reutilização de uma mensagem legítima antiga de várias semanas em uma campanha maliciosa. Iverson observa que as chaves DKIM em si mesmas não mudam necessariamente com o DKIM2. Os remetentes podem não ter que fazer quaisquer modificações significativas no lado DNS. É a infraestrutura de verificação e a cadeia de assinaturas que evoluem, não a configuração dos remetentes.
O que o DKIM2 não substitui: qualidade da lista
O DKIM2 assegura o caminho de entrega, sem alterar a qualidade dos destinatários. Uma assinatura que sobrevive aos intermediários, bounces roteados criptograficamente e uma proteção contra o replay pressupõem que os endereços de destino são válidos e comprometidos. Numa lista com 20% de endereços inválidos ou inativos, o DKIM2 não melhora a taxa de inbox. Ele autentica melhor os emails que os filtros continuarão a rejeitar por outras razões.
Os benchmarks públicos de deliverability publicados pelos principais routers convergem nesse ponto: as taxas de inbox variam mais em função da qualidade do engajamento da lista do que apenas dos parâmetros de autenticação. O DKIM2 reforça a camada de autenticação sem compensar uma lista mal mantida. A verificação de endereços antes do envio continua a ser o pré-requisito de qualquer pipeline de deliverability. O protocolo assegura o caminho uma vez validados os destinatários, nunca a priori.
Comparação DKIM1 e DKIM2 nos critérios-chave
| Critério | DKIM1 (RFC 6376) | DKIM2 (draft IETF 2026) |
|---|---|---|
| Resistência aos intermediários | Nenhuma: qualquer modificação invalida a assinatura | Cadeia de assinaturas: cada intermediário documenta as suas alterações |
| Proteção anti-replay | Ausente: uma assinatura válida é reutilizável | Binding do destinatário + timestamps: assinatura vinculada ao destinatário e a uma janela temporal |
| Gestão de bounces | Bounces assíncronos não criptográficos, possível backscatter | DSN assíncrono + VERP assinado: retorno ao servidor anterior na cadeia |
| Listas de discussão e forwarders | Quebra sistemática da assinatura | Modificações documentadas através de álgebra de modificação, assinatura mantida |
| Visibilidade RSSI | Limitada: sem rastreamento das modificações de trânsito | Auditoria completa da cadeia de trânsito documentada |
| Status | RFC publicada, implementada desde 2011 | Draft adotado pelo WG IETF em março de 2026, ainda não RFC |
O que observar antes do deployment
Quatro documentos foram adotados pelo WG IETF dkim: a especificação principal, um documento de motivação (draft-ietf-dkim-dkim2-motivation), um perfil de deployment via interface Milter e um guia de boas práticas. Todos são prefixados por draft-ietf-dkim, o que indica que estão oficialmente no pipeline do working group, não são propostas individuais.
- Acompanhamento da especificação principal: o draft-ietf-dkim-dkim2-spec expira em outubro de 2026. Sua renovação ou avanço para o status de Proposed Standard será o primeiro sinal concreto de uma trajetória rumo ao RFC.
- Testes junto aos mailbox providers: Richard Clayton mencionou deployments junto a mailbox providers nos próximos meses. Gmail, Yahoo ou Outlook que anunciem o suporte a DKIM2 mudariam imediatamente as prioridades do lado do ESP.
- Infraestrutura inbound dos ESP: o aumento esperado dos volumes de bounces assíncronos durante o deployment exige uma capacidade inbound fortalecida. Os ESP que prepararem a sua infraestrutura com antecedência terão menos pressão operacional.
- Política de remoção de endereços: os bounces assíncronos DKIM2 podem chegar 24 horas ou mais após o envio inicial. As regras de remoção automática terão de ser revistas para incorporar este atraso sem gerar falsos positivos nas listas de cancelamento.
Al Iverson lembra em abril de 2026 que a especificação ainda não está finalizada e que os detalhes estão sujeitos a alterações. O WG IETF organizou sessões interim em 2026 para acelerar os trabalhos. A agenda do meeting interim de 29 de abril de 2026 documenta os rascunhos em revisão.
Para acompanhar o progresso em tempo real: subscreva a lista de discussão ietf-dkim@ietf.org e verifique o estado dos drafts em datatracker.ietf.org/group/dkim, onde é decidido o cronograma efetivo do DKIM2.
