O que é o DKIM e como funciona a assinatura?

O que uma assinatura DKIM realmente assina?

A RFC 6376 define o DKIM em torno de um cabeçalho DKIM-Signature que o servidor remetente adiciona à mensagem antes de ela sair. Esse cabeçalho carrega várias tags: v=1 para a versão, a= para o algoritmo de assinatura, d= para o domínio que assume a responsabilidade, s= para o seletor (visto adiante), h= para a lista de cabeçalhos assinados, bh= para um hash do corpo da mensagem, e b= para a assinatura em si. A RFC 8301 apertou a exigência de algoritmo em 2018: os assinantes devem usar rsa-sha256, e o rsa-sha1 não deve ser usado nem para assinar nem para verificar.

A verificação funciona de trás para frente a partir desse cabeçalho: o servidor receptor lê d= e s=, busca a chave pública correspondente no DNS e verifica se a assinatura em b= é válida para os cabeçalhos e o corpo que a mensagem realmente contém. Se algo coberto pela assinatura mudar depois de assinada, mesmo um único caractere, a verificação falha.

Onde a chave pública é publicada, e o que é um seletor?

A chave pública fica em um registro TXT de DNS em seletor._domainkey.dominio, onde seletor é o nome curto que o domínio escolheu ao configurar aquela chave específica. A RFC 6376 dá o exemplo de uma assinatura com d=example.com e s=foo.bar: o verificador consulta foo.bar._domainkey.example.com. O valor do registro segue uma sintaxe de tag=valor: v=DKIM1 para a versão, k=rsa para o tipo de chave, e p= guardando a chave pública em base64 (um valor p= vazio significa que a chave foi revogada).

Um domínio pode publicar vários seletores ao mesmo tempo, cada um apontando para uma chave diferente, e serviços diferentes costumam usar seletores diferentes. O Google Workspace assina com o seletor google, dando um registro em google._domainkey.seudominio. O Microsoft 365 usa dois seletores fixos, selector1 e selector2, mas os publica como registros CNAME apontando para a própria infraestrutura DKIM da Microsoft em vez de um valor TXT bruto, então a rotação de chaves acontece do lado da Microsoft sem que o dono do domínio precise mexer no DNS.

Por que a rotação de chaves usa seletores em vez de substituir uma chave no lugar?

Rotacionar uma chave de assinatura sobrescrevendo o registro DNS existente é arriscado: qualquer mensagem ainda em trânsito, ou qualquer servidor receptor com uma cópia em cache do registro antigo, falha na verificação no momento em que a chave nova substitui a antiga no mesmo nome. Os seletores evitam isso dando à chave nova o seu próprio nome de DNS. A sequência normal é publicar a chave nova sob um seletor novo enquanto o seletor antigo e o registro dele continuam no lugar, mudar o sistema de assinatura para o seletor novo assim que o registro novo tiver tido tempo de se propagar, e só remover o registro DNS do seletor antigo algum tempo depois que nada mais estiver assinando com ele. Como cada seletor é um nome de DNS independente, a chave antiga e a nova coexistem pelo tempo necessário sem nenhuma lacuna de verificação.

Quais cabeçalhos são assinados, e por que isso importa?

A tag h= lista exatamente quais campos de cabeçalho estão cobertos pela assinatura, e a RFC 6376 exige que o cabeçalho From sempre esteja entre eles. Além desse mínimo obrigatório, os assinantes costumam cobrir também To, Subject, Date, Message-ID e Content-Type, além do corpo da mensagem por meio do hash separado bh=. Qualquer cabeçalho não listado em h= pode ser adicionado, removido ou reordenado depois da assinatura sem quebrar a assinatura, e é por isso que o From ser obrigatório importa: é o único campo que o DKIM garante que não foi trocado depois que o domínio assinou a mensagem. Um cabeçalho que está listado mas é modificado no trânsito, ou um corpo que muda depois que o hash foi calculado, quebra a verificação.

Por que o DKIM sobrevive ao encaminhamento quando o SPF não sobrevive?

O SPF autentica a conexão, o endereço IP de qualquer servidor que esteja falando SMTP com o destinatário no momento. O DKIM autentica o conteúdo da mensagem, por meio de uma assinatura que viaja dentro da própria mensagem em vez de depender de onde ela veio. Uma mensagem encaminhada por um servidor intermediário mantém os cabeçalhos e o corpo originais intactos na maioria das configurações de encaminhamento simples, então a mesma assinatura DKIM que era válida quando a mensagem foi enviada pela primeira vez continua válida quando chega ao destino final, independentemente de qual servidor a retransmitiu no caminho. Esse é o principal motivo pelo qual DKIM e SPF são usados juntos em vez de isolados: o SPF quebra assim que uma mensagem muda de mãos, enquanto o DKIM continua funcionando desde que o conteúdo assinado não seja alterado. Uma lista de discussão ou serviço de encaminhamento que reescreve o assunto ou adiciona um rodapé ao corpo ainda pode quebrar o DKIM, já que isso muda conteúdo coberto pela assinatura, só que por um motivo diferente do que quebra o SPF.

Como encontrar o seletor DKIM de um domínio quando você não o conhece?

A fonte mais direta é uma mensagem que o domínio realmente enviou: abra os cabeçalhos brutos dela e procure a linha DKIM-Signature, depois leia o valor depois de s=. Esse é o seletor exato que o domínio usou para aquela mensagem. Quando não há uma mensagem de amostra disponível, verificar os seletores conhecidos de provedores comuns é um próximo passo razoável, google._domainkey para o Google Workspace, selector1._domainkey e selector2._domainkey para o Microsoft 365, consultando diretamente o registro TXT (ou CNAME):

dig TXT google._domainkey.example.com +short

Um registro com um valor v=DKIM1 confirma que o seletor está ativo; nenhuma resposta significa que esse seletor específico não está em uso, e um seletor diferente, ou um provedor diferente, está assinando o e-mail.

O DKIM é uma peça de uma configuração mais ampla: veja o que é um registro SPF para a verificação de autorização de remetente que roda junto com ele, e o que é o DMARC para como um servidor receptor junta SPF e DKIM em uma única decisão de aprovar ou reprovar. A ferramenta gratuita de consulta MX lista os servidores de e-mail de um domínio a partir da rede de pontos de verificação da HostTracker, útil junto com uma verificação de DKIM ao confirmar a configuração geral de e-mail de um domínio.

Perguntas frequentes

O DKIM criptografa o e-mail?

Não. O DKIM só assina a mensagem para provar sua integridade e origem; qualquer pessoa que interceptar a mensagem ainda consegue ler o conteúdo dela. A criptografia é uma questão separada que o DKIM não aborda.

Um domínio pode usar mais de uma chave DKIM ao mesmo tempo?

Sim. Seletores diferentes podem guardar chaves totalmente diferentes, e é exatamente assim que vários serviços de envio, um sistema de suporte e uma ferramenta de marketing, por exemplo, assinam cada um com a própria chave sob o mesmo domínio sem conflitar.

Que tamanho de chave o DKIM deve usar?

A RFC 6376 exige pelo menos 1024 bits para uma chave de longa duração, e a RFC 8301 recomenda ir além: os assinantes devem usar pelo menos 2048 bits, enquanto os verificadores precisam conseguir checar assinaturas de 1024 até 4096 bits. A maioria dos provedores que emitem chaves novas hoje usa 2048 bits por padrão.

O que acontece se uma mensagem falhar na verificação DKIM?

O DKIM em si não rejeita nem coloca nada em quarentena, ele só informa se passou ou falhou. O que um servidor receptor faz com um resultado de falha é uma decisão de política tomada em outro lugar, na maioria das vezes pelo registro DMARC coberto no próximo guia.

O DKIM é obrigatório para toda mensagem de saída pelo protocolo?

Não, o DKIM é opcional no nível do protocolo. Na prática, os grandes provedores de caixa de entrada pesam tanto a ausência dele na filtragem de spam que enviar e-mail sem nenhuma assinatura DKIM costuma cair na pasta de spam mesmo quando nada mais na mensagem parece suspeito.