Pular para o conteúdo
Segurança de E-mail

O que é DKIM (assinatura de e-mail)?

O DKIM é a assinatura criptográfica que o servidor de saída acrescenta ao cabeçalho de cada mensagem, provando duas coisas a quem recebe: que ela partiu mesmo de quem controla o domínio e que o trecho assinado não foi alterado no caminho. A chave que confere essa assinatura fica publicada no DNS do domínio, à vista de qualquer servidor do mundo. É o segundo dos três registros de autenticação de e-mail e o único que continua valendo quando a mensagem é repassada adiante sem ser alterada.

Zamak TechnologiesAtualizado em 6 de agosto de 2026

Como o DKIM funciona

O DKIM usa um par de chaves: uma fica guardada no servidor que envia e assina, a outra é publicada no DNS para que qualquer destinatário possa conferir. Nada da chave que assina sai do servidor.

1

Gera o par de chaves e escolhe um nome

O serviço de e-mail cria duas chaves ligadas entre si e um nome curto para identificar esse par, o seletor. Uma empresa pode ter vários seletores, um para cada sistema que envia.

2

Publica a chave de conferência no DNS

A chave pública entra como registro de texto no domínio, sob um endereço derivado do seletor, no formato seletor._domainkey.seudominio.com. Ela é pública de propósito: serve justamente para que qualquer servidor do mundo possa usá-la.

3

Assina a mensagem na saída

No momento do envio, o servidor calcula um resumo criptográfico dos cabeçalhos escolhidos e do corpo, sela esse resumo com a chave que só ele tem e grava o resultado num cabeçalho da própria mensagem.

4

O destino confere e decide

Quem recebe lê o seletor e o domínio no cabeçalho, busca a chave no DNS, recalcula o resumo e compara. Se bater, a assinatura é válida e o domínio assumiu responsabilidade pela mensagem.

Fonte: RFC 6376, a especificação oficial do DKIM publicada pelo IETF, que define a assinatura como declaração de responsabilidade de um domínio e a publicação da chave pública no DNS, a RFC 8301, que a atualiza no ponto dos algoritmos e do tamanho de chave, e o material de configuração de DNS de e-mail da N-able University.

Os limites do DKIM

  • Assinatura válida não significa mensagem confiável. O DKIM afirma que um domínio assumiu responsabilidade pela mensagem, e nada além disso. Um criminoso pode registrar um domínio, configurar DKIM impecável e assinar o próprio golpe com sucesso. E a própria especificação avisa que não define nenhum mecanismo contra reenvio abusivo: uma mensagem legítima capturada e redistribuída em massa chega com a assinatura ainda válida.
  • O domínio que assina não precisa ser o que você lê. A especificação separa a responsabilidade pelo envio da autoria aparente. É exatamente essa folga que o DMARC fecha ao exigir que os dois coincidam.
  • Alteração legítima quebra a assinatura. Listas de discussão e sistemas que acrescentam um rodapé ou mudam o assunto alteram o trecho assinado, e a conferência falha mesmo sem nenhuma má intenção.
  • Chave esquecida é chave enfraquecida. Um par gerado uma vez e deixado por anos, ou uma chave curta demais, transforma a assinatura em formalidade. Vale a rotação periódica e a remoção dos seletores de serviços que não são mais usados.

As partes de uma assinatura DKIM

  • O seletor O nome curto que identifica qual par de chaves foi usado. É o que permite ter várias assinaturas ativas ao mesmo tempo, uma por sistema que envia, e trocar uma delas sem derrubar as outras.
  • O domínio que assina O domínio que assume responsabilidade pela mensagem. É o dado que o DMARC compara com o remetente visível, e por isso o ponto que decide se a autenticação vai valer de verdade.
  • O resumo criptográfico Um cálculo feito sobre os cabeçalhos escolhidos e o corpo da mensagem. Qualquer alteração de conteúdo no trecho assinado, por menor que seja, faz a conta não fechar. O que fica de fora do trecho assinado, porém, não é protegido: a própria norma alerta que dá para acrescentar conteúdo depois do ponto assinado sem quebrar a assinatura.
  • A chave publicada no DNS A metade pública do par, disponível para qualquer servidor conferir. Sua exposição é intencional: com ela é possível verificar uma assinatura, nunca produzir uma. A ressalva é o tamanho: uma chave curta demais pode ser quebrada, e aí sim a metade publicada deixa de ser inofensiva.

Por que o DKIM é o que segura a autenticação de pé

2048
bits é o tamanho de chave que o padrão manda usar de preferência; abaixo de 1024 bits a assinatura tem de ser recusada como inválida (RFC 8301, que atualiza a RFC 6376)
1
chave do par nunca sai do servidor que assina; a outra metade é publicada no DNS de propósito, para o mundo inteiro conferir (RFC 6376)
0
alterações de conteúdo são toleradas no trecho assinado: um rodapé acrescentado ou um assunto reescrito já derrubam a conferência (RFC 6376)

O valor prático do DKIM aparece justamente onde o SPF falha. Quando alguém encaminha uma mensagem, o servidor que reencaminha vira a origem e deixa de estar na lista de autorizados do domínio original, então o SPF quebra sem que ninguém tenha errado. A assinatura do DKIM viaja dentro do cabeçalho da própria mensagem e continua válida depois do encaminhamento, desde que ninguém altere o conteúdo no caminho, o que a torna a perna mais resistente da autenticação e a razão pela qual publicar apenas SPF derruba e-mail legítimo. Existe, porém, um falso conforto específico deste registro: assinar com um domínio que não é o que aparece para o leitor. A conferência do DKIM passa, o relatório mostra assinatura válida, e ainda assim a mensagem falha no DMARC, porque o que a pessoa lê na tela continua sem prova nenhuma. Traduzido para o que a empresa sente: a proposta que o seu contato encaminha para o decisor, a cobrança que o cliente repassa para o financeiro e o comunicado que roda internamente são exatamente as mensagens que dependem do DKIM para chegar autenticadas ao fim do caminho. Sem assinatura, é justamente o e-mail que já venceu a primeira etapa da venda que some no filtro de spam de outra empresa. Assinar é necessário; assinar com o domínio certo é o que faz a assinatura contar.

Como aplicar o DKIM corretamente

O DKIM entrega o máximo quando cobre todos os caminhos de saída e assina com o domínio que o destinatário vê:

  1. Assine tudo que sai, não só o correio corporativoCada sistema que envia em nome da empresa precisa da própria assinatura: a plataforma de campanhas, o sistema de gestão, o emissor de notas, a ferramenta de suporte. O que não assina fica dependendo só do SPF, e o SPF quebra no encaminhamento.
  2. Use um seletor por serviçoSeparar os seletores permite trocar a chave de um sistema, ou desligá-lo, sem afetar os demais. Também torna óbvio, ao ler um cabeçalho, qual plataforma enviou aquela mensagem.
  3. Prefira a chave de 2048 bitsÉ o tamanho que a norma manda preferir. Abaixo de 1024 bits a assinatura já não pode ser considerada válida: chave curta demais pode ser quebrada e usada para forjar a assinatura do domínio, que é o único cenário em que publicar a chave vira risco.
  4. Confira o alinhamento com o remetente visívelDe nada adianta a assinatura ser válida se o domínio que assinou não é o que aparece para quem lê. É essa coincidência que o DMARC exige, e é ela que faz a autenticação valer.
  5. Rotacione as chaves e limpe o que não usa maisTroque os pares periodicamente e remova do DNS o seletor de todo serviço que foi descontinuado. Chave publicada de um sistema abandonado é superfície exposta sem contrapartida.

Na prática

O DKIM é o lacre da mensagem: ele não diz que o conteúdo é bom, diz que o pacote saiu de quem controla aquele domínio e que ninguém mexeu no conteúdo no caminho. Por isso um golpe pode chegar com assinatura perfeitamente válida, do domínio do golpista. A pergunta que importa nunca é apenas se existe assinatura, e sim de quem é a assinatura, e se ela bate com o nome que aparece na tela.

Como a Zamak trata o DKIM

A Zamak Technologies assina todos os caminhos de saída, mantém um seletor por sistema para poder rotacionar sem interromper nada e confere o alinhamento entre o domínio que assina e o remetente que o destinatário vê, ao lado da equipe que já administra o ambiente. A verificação de falsificação de e-mail mostra em segundos se o seu domínio publica assinatura hoje. A manutenção dessas chaves faz parte da Segurança de E-mail Gerenciada e da Cibersegurança gerenciada do Método Zamak.

Perguntas frequentes sobre DKIM

Qual a diferença entre SPF e DKIM?
O SPF autoriza servidores: diz de quais lugares o e-mail do domínio pode sair. O DKIM autentica a mensagem: prova, por assinatura criptográfica, que ela partiu de quem controla o domínio e que o trecho assinado não foi alterado. O SPF quebra quando a mensagem é encaminhada; o DKIM continua valendo, desde que o conteúdo não seja alterado. Por isso os dois são complementares, e não alternativas.
Publicar a chave no DNS não é um risco?
Não, e a exposição é proposital. A chave publicada serve apenas para conferir assinaturas, nunca para produzi-las. A que assina permanece guardada no servidor de envio e nunca é divulgada. É o mesmo princípio de um selo cuja marca todos reconhecem sem conseguir reproduzir. A única ressalva é o tamanho da chave: uma chave curta demais pode ser quebrada, e por isso o padrão manda usar 2048 bits e recusar qualquer coisa abaixo de 1024.
Recebi um e-mail com DKIM válido. Ele é confiável?
Não necessariamente. A assinatura válida prova que algum domínio assumiu responsabilidade pela mensagem, e o criminoso pode ter assinado com um domínio dele. O que muda o jogo é conferir se o domínio que assinou é o mesmo que aparece no remetente, e isso quem exige é o DMARC.
Preciso de um DKIM para cada sistema que envia?
Precisa que cada sistema assine, e o caminho mais limpo é dar a cada um o seu próprio seletor. Assim é possível trocar a chave de uma plataforma, ou desligá-la, sem afetar o resto, e fica fácil identificar a origem de uma mensagem só de ler o cabeçalho.
Por que a assinatura falha em listas de discussão?
Porque muitas listas alteram a mensagem antes de repassá-la, acrescentando um rodapé ou mudando o assunto. Como a assinatura foi calculada sobre o conteúdo original, qualquer alteração no trecho assinado faz a conferência falhar. É um caso conhecido e não indica ataque.

Termos relacionados

Continue explorando

Ver o índice completo →