DKIM2: em que ponto está a normalização e como se preparar

⚡TL;DR

• O DKIM2 não é um padrão: nenhuma RFC, nenhum documento em última chamada e um calendário da charter da IETF com cerca de sete meses de atraso.
• O trabalho decorre no grupo de trabalho dkim histórico, com nova charter em fevereiro de 2025. Não existe nenhum grupo « dkim2 ».
• A especificação atual (draft-ietf-dkim-dkim2-spec-04, 5 de julho de 2026) assenta em dois cabeçalhos: DKIM2-Signature por salto e Message-Instance para descrever as modificações sob a forma de receitas JSON.
• Quase toda a sintaxe de 2025 desapareceu: mv=, pp=, a=, b=, bh=, o cabeçalho Mail-Version:.
• Três implementações (Rust, Python, Go) demonstraram a sua interoperabilidade em julho de 2026, e desde então foi anunciada uma quarta, em C: a mudança de estado mais concreta do último ano.
• Proprietário de domínio: nada a fazer. As suas chaves e os seus registos _domainkey mantêm-se válidos tal como estão.

ℹ️ Os termos replay DKIM, backscatter, Message-Instance e receita estão definidos no glossário no final do artigo.

O DKIM2 arrasta uma reputação contraditória. Lê-se que vai substituir o DKIM « em breve », que vai tornar o DMARC caduco ou, pelo contrário, que só existe no papel. A realidade de julho de 2026 é mais simples: o protocolo continua sem estar normalizado, mas deixou de ser teórico, uma vez que três implementações independentes assinam, verificam e reconstroem mensagens em conjunto.

Porque é que o DKIM2 existe?

O DKIM (STD 76, RFC 6376) assina o conteúdo de uma mensagem. É essa a sua força e, ao fim de vinte anos de utilização, o seu limite: a assinatura nada diz sobre o caminho percorrido nem sobre os endereços realmente usados em cada salto SMTP.

O replay que o DKIM não fecha

Um atacante que obtenha uma mensagem legitimamente assinada pode reenviá-la em massa sem tocar naquilo que a assinatura cobre: esta mantém-se válida, o DMARC continua a passar, e é o domínio signatário que fica com a reputação degradada. É o replay DKIM, que nenhuma rotação de chave elimina verdadeiramente.

O reencaminhamento que quebra a assinatura

Uma lista de distribuição que acrescenta um rodapé, prefixa o assunto ou introduz um cabeçalho de cancelamento de subscrição invalida o hash assinado. O DKIM não oferece nenhuma forma de descrever a modificação e, por isso, nenhuma forma de recuar para verificar a assinatura de origem.

Os bounces que seguem para um terceiro

Quando um servidor aceita uma mensagem e só depois gera um bounce, esse bounce segue para o endereço de envelope, eventualmente falsificado. É o backscatter: uma vítima inocente recebe relatórios de não entrega por causa de correio que nunca enviou.

O DKIM2 ataca os três ao mesmo tempo: cada salto apõe a sua própria assinatura numerada, declara o envelope que usou e documenta o que modificou. O caminho torna-se verificável e as modificações reversíveis.

Em que ponto está a normalização?

Um grupo com nova charter, três documentos

Não existe nenhum grupo de trabalho « dkim2 » na IETF, e essa é a primeira fonte de erro. O trabalho decorre no grupo dkim histórico, cuja charter revista foi aprovada pelo IESG a 20 de fevereiro de 2025, sob a presidência de Murray Kucherawy e Pete Resnick.

Estão ativos três documentos do grupo:

• draft-ietf-dkim-dkim2-spec-04 (5 de julho de 2026), Standards Track, 43 páginas, expira a 6 de janeiro de 2027. Autores: Richard Clayton (Yahoo), Wei Chuang (Google), Bron Gondwana (Fastmail).
• draft-ietf-dkim-dkim2-bcp-00 (18 de junho de 2026), Todd Herr. Adotado, mas deliberadamente posto em espera enquanto o grupo não acumular experiência operacional.
• draft-ietf-dkim-dkim2-dns-00 (20 de julho de 2026), Wei Chuang.

O que diz o calendário

Nenhum destes documentos está em última chamada do grupo (WG Last Call), nenhum foi submetido ao IESG, não existe nenhuma RFC. Ora, os marcos da charter apontavam para « todos os documentos submetidos ao IESG a 31 de dezembro de 2025 »: o atraso é de cerca de sete meses, e o calendário não foi revisto.

Os marcos reais do período decorrido são poucos. Novembro de 2025: os drafts motivation, header e mailversion deixam de ser mantidos. 20 de março de 2026, na IETF 125: a especificação de Richard Clayton torna-se o documento principal e o formato JSON é escolhido para descrever as modificações. 24 de março de 2026: primeiro draft de grupo da especificação. 24 de junho de 2026: o spec-03 introduz a tag nd=. 24 de julho de 2026: sessão DKIM na IETF 126, em Viena.

Os documentos mortos

Qualquer conteúdo escrito em 2025 sobre DKIM2 remete para drafts hoje abandonados ou substituídos: verifique sempre os nomes e as revisões citados. O draft-ietf-dkim-dkim2-motivation-02 expirou; o draft-ietf-dkim-dkim2-header-00 e o draft-gondwana-dkim2-mailversion-00 estão marcados como « Dead WG Document ». O seu conteúdo foi absorvido, reescrito ou abandonado.

Outro erro que circula: várias publicações afirmam que o grupo teria adotado um « perfil de implantação através de milter ». É falso. A 8 de maio de 2026, o presidente do grupo escreveu que « the working group does not wish to pursue adoption at this time ».

O que o DKIM2 muda concretamente

A mecânica assenta em dois cabeçalhos distintos.

O cabeçalho DKIM2-Signature

Cada salto acrescenta uma linha. O parágrafo 8 da especificação fixa as obrigações: « The i=, m=, t=, d= and s= tags MUST be present. There MUST be either an nd= tag or both mf= and rt= tags. The other tags are optional. »

Tag	Obrigatória	Função
i=	sim	Número de sequência do salto. O emissor de origem assina com i=1 e cada salto seguinte incrementa. Basta uma lacuna na numeração para que toda a mensagem seja considerada não assinada.
m=	sim	Número do Message-Instance mais elevado no momento da assinatura.
t=	sim	Carimbo temporal, expresso em segundos epoch UTC (um inteiro, não uma data formatada).
d=	sim	Domínio signatário. É ele que serve para construir a consulta DNS de obtenção da chave.
s=	sim	Trio seletor:algoritmo:assinatura-base64.
mf=	condicional	MAIL FROM usado na emissão, codificado em base64, incluindo os sinais < e >.
rt=	condicional	RCPT TO, base64, com os < e > incluídos. Podem ser listados vários destinatários.
nd=	condicional	Domínio que assinará o salto seguinte. Mutuamente exclusivo com mf= e rt=.
n=	não	Nonce livre, com 64 caracteres no máximo.
f=	não	Flags.

A tag s= segue a ABNF sig-set = selector ":" sig-name ":" message-sig, em que sig-name vale rsa-sha256 ou ed25519-sha256; podem coexistir várias assinaturas de algoritmos diferentes, mas « a different selector MUST necessarily be used for each signature ». Já o d= tem de corresponder exatamente aos labels mais à direita do domínio indicado em mf=: por outras palavras, d= é idêntico a esse domínio ou é um dos seus domínios pai. Assim, mf=<user@mail.example.com> combina com d=example.com, ao passo que o inverso, mf=<user@example.com> com d=mail.example.com, é recusado. Só um mf= vazio, ou seja <>, o caso dos relatórios de não entrega, fica dispensado desta correspondência.

Do lado da encriptação, a especificação impõe RSA de pelo menos 1024 bits na assinatura e exige que os verificadores aceitem de 1024 a 2048 bits, sendo facultativo o suporte de chaves maiores. O expoente público é 65537, o preenchimento é PKCS#1 v1.5, o hash não é truncado, o SHA256 é obrigatório e o Ed25519 usa a variante PureEdDSA (RFC 8032, parágrafo 5.1): « Signers SHOULD implement both RSA-SHA256 and Ed25519-SHA256, Verifiers MUST implement both ». Uma assinatura com mais de 14 dias pode ser ignorada, mas trata-se de um MAY, não de uma obrigação.

As flags f= foram reformuladas. exploded indica que a mensagem segue para mais do que um endereço; a sua ausência autoriza um MTA a supor que existe uma única cópia, e é precisamente essa a alavanca anti-replay. donotexplode e donotmodify são proibições dirigidas aos intermediários. feedback pede um retorno, a sua ausência significa que esse retorno não é desejado, e feedhere permite que um intermediário reencaminhe esse retorno sem revelar o destino final. Qualquer flag desconhecida deve ser ignorada.

Um verificador produz um dos quatro estados, PASS, FAIL, PERMERROR ou TEMPERROR, alinhados com a RFC 8601.

O Message-Instance

O segundo cabeçalho descreve o estado da mensagem e a forma de regressar ao estado anterior: « The m= and h= tags MUST be present. The r= tag is optional. »

A tag m= é o número de revisão: 1 na origem, incrementado a cada nova instância; uma lacuna na sequência torna a mensagem inverificável. A tag h= assume a forma sha256:<hash dos cabeçalhos>:<hash do corpo>, ambos em base64, e podem coexistir vários conjuntos. A tag r= contém « the base64 encoded version of the JSON object that contains the recipes that allow the previous instance of the message to be recreated ».

Ponto importante para os operadores: se não modificar nada, não acrescenta nenhum Message-Instance; um relay que transmite a mensagem tal como está não tem nada a descrever.

As receitas formam um objeto JSON, identificado pelo esquema https://dkim2.org/schemas/recipe-v1, com uma chave "h" para os cabeçalhos e/ou "b" para o corpo. Cada receita é um array de passos com exatamente uma chave: {"c": [início, fim]} copia um intervalo de linhas ou de instâncias, {"d": ["..."]} emite dados literais. Um "b": null assinala um corpo anterior não reconstruível; um array vazio associado a um nome de campo significa « apaga todas as suas instâncias ». Armadilha clássica: os cabeçalhos são numerados de baixo para cima, as linhas do corpo de cima para baixo.

As suas chaves DNS não mudam

A chave pública obtém-se em <seletor>._domainkey.<d=>, exatamente como hoje: « these keys are no different, and are stored in the same locations as those for DKIM1 ». Nenhum novo tipo de registo, nenhuma migração de DNS a preparar.

nd= ou mf=/rt=: a cadeia de custódia

Uma sequência de vários DKIM2-Signature com nd= é permitida, mas « MUST end with a DKIM2-Signature that contains mf= and rt= tags », e o domínio declarado em nd= tem de corresponder exatamente ao d= da assinatura seguinte na ordem dos i=.

O parágrafo 9.3 apresenta esta variante como uma cadeia de custódia para saltos imaginários. Pense num sistema que recebe correio num domínio e o reencaminha a partir de outro: a continuidade entre o rt= do salto anterior e o mf= do salto seguinte fica quebrada. Em vez de fabricar uma assinatura com mf= e rt= inventados, que poluiriam a cadeia com endereços fictícios, esse sistema anuncia com nd= quem será o próximo signatário. É esta a opção que a especificação incentiva.

Exemplo de cabeçalhos

O spec-04 não contém nenhum exemplo de mensagem ou de cabeçalho: o draft que os devia fornecer, draft-robinson-dkim2-message-examples-00, expirou em 2025. O exemplo abaixo é, por isso, reconstruído a partir da gramática ABNF do documento e não tem qualquer valor normativo.

Cenário com dois saltos: um remetente escreve para uma lista de distribuição, a lista acrescenta um cabeçalho List-Unsubscribe e reencaminha.

DKIM2-Signature: i=2; m=2; t=1740001000; d=test2.dkim2.com;
  mf=PGJvdW5jZUB0ZXN0Mi5ka2ltMi5jb20+; rt=PHJlY2lwaWVudEBleGFtcGxlLmNvbT4=;
  s=ed25519:ed25519-sha256:FDYZopU8W+c7...;
DKIM2-Signature: i=1; m=1; t=1740000000; d=test1.dkim2.com;
  mf=PHNlbmRlckB0ZXN0MS5ka2ltMi5jb20+; rt=PGxpc3RAdGVzdDIuZGtpbTIuY29tPg==;
  s=ed25519:ed25519-sha256:oKZmf7rabJv4...;
Message-Instance: m=2; h=sha256:u4RFAizDeEqt...:SgG5fNGEg1x2...;
  r=eyJoIjp7Imxpc3QtdW5zdWJzY3JpYmUiOltdfX0=;
Message-Instance: m=1; h=sha256:SLtzk6LO68CC...:SgG5fNGEg1x2...;
Received: from test1.dkim2.com by relay.example.com; ...
List-Unsubscribe: <mailto:unsub@relay.example.com>
From: sender@test1.dkim2.com
To: list@test2.dkim2.com
Subject: ...

Vamos descodificar. Os valores de envelope estão em base64, com os < e > incluídos, tal como a especificação exige. No primeiro salto, mf= vale <sender@test1.dkim2.com> e rt= vale <list@test2.dkim2.com>. No segundo, a lista reencaminha: mf= vale <bounce@test2.dkim2.com> e rt= vale <recipient@example.com>. A continuidade da cadeia é visível a olho nu, e é aí que reside todo o interesse do mecanismo.

A passagem mais instrutiva é o r= do Message-Instance número 2. Descodificado a partir do base64, dá:

{"h":{"list-unsubscribe":[]}}

Por palavras simples: « para regressar à instância anterior, apaga todas as ocorrências do campo List-Unsubscribe ». Um verificador que queira validar a assinatura i=1 aplica esta receita, recupera a mensagem tal como o remetente a emitiu, recalcula o hash e compara. A modificação não quebrou a cadeia: foi declarada e tornada reversível.

Os valores de s= e os hashes do h= estão truncados: dependeriam de chaves privadas e de uma mensagem real, pelo que o leitor não os pode recalcular. O exemplo serve para mostrar a estrutura dos cabeçalhos, não para ser verificado.

O que mudou desde os drafts de 2025

Se leu um guia DKIM2 publicado no final de 2025, praticamente toda a sintaxe que ele descrevia desapareceu.

Elemento de 2025	Estado no spec-04
Cabeçalho único DKIM2: (Active/Historical)	Removido, substituído pelo par DKIM2-Signature e Message-Instance
Cabeçalho Mail-Version:	Removido, reformulado em Message-Instance; as receitas compactas dão lugar a JSON codificado em base64
mv=	Renomeado para m=
v=	Não existe nem virá a existir
pp= (procuração)	Removido; nd= ocupa esse lugar desde o spec-03 (24 de junho de 2026)
a=	Removido, fundido em s=
b=	Removido, absorvido por s=
bh=	Deslocado para o h= do Message-Instance
h= (lista dos campos assinados)	Sentido invertido: o DKIM2 assina tudo exceto uma lista de exclusão
t=	Passa de uma data-hora formatada para um inteiro epoch
f=modifiedbody, f=modifiedheader	Removidos, considerados redundantes com os dados de versão
f=donotforward	Removido
f=feedhere	Novo, apareceu no spec-03

A ausência de v= é deliberada

O parágrafo 8 justifica-a: « Experience from IMF onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, it is expected that header fields will be labelled as DKIM3 instead. » Uma rutura maior produziria, portanto, um cabeçalho DKIM3-Signature, e não um número de versão interno.

A inversão do h=

O DKIM enumera os campos que assina. O DKIM2 faz o contrário: assina tudo, exceto sete famílias de campos listadas no parágrafo 4.1, a saber ARC-*, Authentication-Results, Delivered-To, DKIM-Signature, Received, Return-Path e X-*. Exatamente os campos que um intermediário é legitimamente levado a acrescentar ou modificar em trânsito.

O ARC vai para a reforma

O ARC respondia ao mesmo sintoma: o reencaminhamento quebra o SPF e o DKIM. Mas limitava-se a transportar um testemunho selado dos resultados de autenticação observados antes do relay, sem nunca fechar a falha de replay. É rastreabilidade, não integridade ponta a ponta. A IETF reclassifica-o hoje para o status « Historic » e concentra o esforço no DKIM2, que trata a causa em vez do sintoma. O detalhe desta reclassificação e as suas consequências práticas são objeto de um artigo dedicado.

Em que ponto estão as implementações?

É aqui que o ano foi decisivo: passou-se de zero implementações para três que se entendem, e desde então foi anunciada uma quarta.

A 4 de julho de 2026, uma demonstração de interoperabilidade juntou três implementações independentes: mail-auth em Rust (Stalwart Labs), a implementação em Python de Bron Gondwana e a implementação em Go de Steve Atkins. Assinatura, verificação e reconstrução por receitas foram testadas nos dois sentidos, incluindo em cadeias com vários saltos. Resultado anunciado: com a dobragem de cabeçalhos desativada, todas as combinações passam. Pelo caminho, foram identificados dois bugs de dobragem, um do lado Go (base64 estrito, sem remoção dos espaços), outro do lado Python (divisão pelo : sem desdobragem prévia).

A 8 de julho de 2026, Bron Gondwana centralizou o conjunto de testes na organização GitHub dkim2wg e mencionou uma quarta implementação, em C (PhoenixDKIM).

Quanto ao calendário, há prognósticos, datados e atribuídos. Laura Atkins (Word to the Wise, 23 de abril de 2026) espera ver DKIM2 funcional nos grandes fornecedores até ao final de 2026. Al Iverson (Spam Resource, 21 de abril de 2026) lembra que a especificação ainda não está finalizada e que as coisas podem mudar, e sublinha que as chaves, essas, para já não mudam. Nenhuma fonte primária anuncia uma data de obrigatoriedade para os remetentes, e os calendários de obrigatoriedade que circulam não assentam em nenhuma fonte primária.

O que ainda não está decidido

O grupo reuniu-se na IETF 126, em Viena, a 24 de julho de 2026. Os pontos seguintes foram aí colocados, não decididos; as atas da sessão ainda não foram publicadas.

1. Receitas nulas para os cabeçalhos: devem ser eliminadas, por falta de um caso de uso identificado?
2. Message-Instance falaciosos: os MUST NOT atuais são demasiado estritos e provocaram rejeições de mensagens durante os ensaios de interoperabilidade.
3. Algoritmo pós-quântico: o grupo procura o parecer de peritos, sendo a dificuldade identificada que chaves muito longas passam mal no DNS sobre UDP.
4. Maiúsculas e minúsculas nos nomes dos campos: devem impor-se as minúsculas nas receitas JSON?
5. Relatórios de não entrega: é preciso uma flag dedicada e a omissão do Message-Instance?
6. Alinhamento e DMARC: « The DKIM2 spec deliberately stays away from saying anything about DMARC », o assunto é remetido para o documento de boas práticas. A expectativa manifestada é um alinhamento entre o From: de origem, o MAILFROM inicial e o d= da primeira DKIM2-Signature, ao passo que hoje o DKIM2 só exige o alinhamento dos dois últimos.
7. Mensagens retransmitidas apenas com DKIM1: devem ser assinadas em DKIM2?
8. Ciclos de retorno: deve normalizar-se o seu formato?

Esta lista é a melhor medida da maturidade real do protocolo e a razão pela qual o documento de boas práticas continua congelado.

Impactos operacionais

As consequências não são as mesmas consoante o papel de cada um, e a repartição é desequilibrada.

Proprietário de domínio: nada a fazer

Nenhuma ação a tomar hoje. A única coisa útil é manter um DKIM1 saudável, com uma rotação de chaves controlada, e um DMARC implementado: é essa a base sobre a qual o DKIM2 se apoiará.

Um esclarecimento que volta muitas vezes: o DMARC não desaparece. Conserva um valor próprio, nomeadamente os relatórios agregados ao nível do domínio e a deteção da falsificação do domínio do From:, que o DKIM2 não replica.

ESP, relays e listas de distribuição: o verdadeiro trabalho

Assinar em cada salto, registar as modificações sob a forma de receitas e, sobretudo, antecipar um efeito secundário subestimado: o afluxo de bounces assíncronos de entrada. O DKIM2 devolve a mensagem ao salto anterior, o que altera o volume e a natureza dos retornos a tratar, um ponto que Laura Atkins sublinha em particular.

Outro ponto de atenção: a dupla assinatura (a da marca e a da plataforma), tal como se prática hoje em DKIM, não se transpõe diretamente. Al Iverson observava, a 9 de maio de 2026, que não existem, em rigor, assinaturas múltiplas diretas.

Verificadores: começar por cima

A verificação está invertida face à intuição: parte-se do i= mais elevado, a assinatura mais recente, e sobe-se depois a cadeia aplicando as receitas para reconstruir as instâncias anteriores.

Plano de preparação

1. Inventarie os seus fluxos: onde assina, onde verifica, que saltos intermédios existem, que mecanismos de reescrita de envelope (SRS, VERP) estão em vigor.
2. Ponha o DKIM1 em ordem: seletores atualizados, chaves com um tamanho correto, rotação documentada.
3. Faça um protótipo do lado do relay, caso opere algum: mf= e rt= em base64 com os < e > incluídos, numeração i=, carimbo temporal epoch, escolha dos algoritmos.
4. Modele as suas modificações correntes sob a forma de receitas JSON: rodapé, prefixo de assunto, List-Unsubscribe. É o exercício que revela os casos difíceis.
5. Dimensione o tratamento dos bounces assíncronos de entrada, o ponto mais vezes esquecido.
6. Não mexa no seu DNS por causa do DKIM2: não há nada de novo para publicar.
7. Faça um acompanhamento regular do draft-ietf-dkim-dkim2-spec e preveja interruptores de funcionalidade: quatro revisões em pouco mais de três meses, a sintaxe ainda mexe.

FAQ

O DKIM2 é um padrão em 2026?

Não. A 25 de julho de 2026 não existe nenhuma RFC DKIM2: a especificação está na fase draft-ietf-dkim-dkim2-spec-04, publicada a 5 de julho de 2026, e nenhum documento do grupo está em última chamada nem foi submetido ao IESG. Os marcos da charter apontavam para uma submissão a 31 de dezembro de 2025, ou seja, cerca de sete meses de atraso.

Tenho de alterar os meus registos DNS por causa do DKIM2?

Não. A especificação indica que as chaves DKIM2 não são diferentes e são guardadas nos mesmos locais que as do DKIM1, em seletor._domainkey.seudominio. Nenhum novo tipo de registo, nenhuma migração de DNS a prever.

Qual é a diferença entre DKIM2-Signature e Message-Instance?

O DKIM2-Signature é acrescentado por cada salto SMTP: número de sequência i=, carimbo temporal, domínio signatário, assinatura e envelope usado. O Message-Instance descreve o estado da mensagem e a forma de regressar ao anterior, através de receitas JSON codificadas em base64 na tag r=. Um intermediário que não modifica nada acrescenta uma assinatura, mas não um Message-Instance.

O DKIM2 substitui o DMARC?

Não. O DMARC conserva um valor próprio que o DKIM2 não replica: relatórios agregados ao nível do domínio e deteção da falsificação do domínio do From:. Aliás, a especificação evita deliberadamente falar de DMARC e remete a questão do alinhamento para o documento de boas práticas.

Existem implementações do DKIM2 que funcionam?

Sim: três implementações demonstraram a sua interoperabilidade e, desde então, foi anunciada uma quarta que não participou na demonstração. A 4 de julho de 2026, uma demonstração de interoperabilidade juntou mail-auth em Rust (Stalwart Labs), uma implementação Python de Bron Gondwana e uma implementação Go de Steve Atkins, incluindo em cadeias com vários saltos. Uma quarta implementação em C, PhoenixDKIM, só foi mencionada depois, a 8 de julho de 2026, quando o conjunto de testes foi centralizado na organização GitHub dkim2wg.

O que devo fazer hoje se apenas giro o domínio de uma empresa?

Nada de específico ao DKIM2: verifique se o seu DKIM atual está corretamente publicado e assinado, se o seu DMARC está implementado e monitorizado e se a sua rotação de chaves está documentada. O verdadeiro trabalho de migração diz respeito aos ESP, aos relays e às listas de distribuição, não aos proprietários de domínio.

📖 Glossário

Replay DKIM

Reenvio massivo, ou para outros alvos, de uma mensagem já assinada por um domínio legítimo, sem alterar aquilo que a assinatura cobre: esta mantém-se válida, porque o DKIM assina o conteúdo mas não o envelope SMTP nem a rota. O domínio signatário vê a sua reputação degradar-se por causa de correio que não enviou, e nenhuma mitigação DKIM1 (limite de débito por seletor, rotação de chaves, endurecimento do DMARC) fecha a falha. Em DKIM2, a assinatura inclui o envelope do salto e encadeia o percurso através do número i=.

Backscatter

Bounces indesejados (NDR, DSN) ou respostas automáticas enviados a um terceiro inocente cujo endereço foi falsificado no MAIL FROM ou no Return-Path: a caixa desse terceiro fica inundada de relatórios de não entrega. Em DKIM1, rejeita-se durante a troca SMTP em vez de depois, com SRS ou VERP para rastrear os bounces; em DKIM2, os retornos sobem a cadeia assinada até ao salto anterior, ou seja, até um ator realmente envolvido.

Message-Instance

Cabeçalho DKIM2 que descreve o estado de uma mensagem num dado momento do seu percurso: m= (número de revisão) e h= (hash dos cabeçalhos e do corpo) obrigatórios, r= (receitas) facultativo.

Receita

Descrição JSON, codificada em base64 na tag r= de um Message-Instance, que permite reconstruir a instância anterior da mensagem.

Fontes

• draft-ietf-dkim-dkim2-spec, a especificação
• draft-ietf-dkim-dkim2-bcp, as boas práticas
• draft-ietf-dkim-dkim2-dns, a vertente DNS
• Documentos do grupo de trabalho dkim da IETF
• Ata da sessão DKIM na IETF 125
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8463: um novo método de assinatura para DKIM (Ed25519)
• Laura Atkins, « DKIM2: What it means for the future of email »
• Al Iverson, « What is DKIM2? »
• Al Iverson, « More on DKIM2: VERP, async bounces, signatures and hops »

O DKIM2 continua a ser um trabalho em curso. Esta página será atualizada ao ritmo das revisões do draft de especificação.

Verifique o seu DKIM atual

É a sua configuração DKIM (RFC 6376) atual que será reutilizada. Inspecione os seus seletores em tempo real com o DKIM Record Checker e valide a sintaxe de cada registo publicado com o DKIM Syntax Validator.

Guias de autenticação de e-mail relacionados

• O ARC passa ao status « Historic » na IETF - O que a reclassificação muda de facto, e o que não muda
• DMARCbis: as novidades do futuro padrão - As evoluções do DMARC com o DMARCbis
• O que é o ARC (Authenticated Received Chain)? - Compreender a cadeia de autenticação ARC
• BIMI, VMC e CMC: compatibilidade DNS - Guia completo sobre BIMI e os certificados de marca
• Gmail Bulk Sender: os novos requisitos - Conformidade com as regras de envio em massa do Gmail