O que é DKIM? O padrão de autenticação de email explicado

DKIM (DomainKeys Identified Mail) é um protocolo criptográfico de autenticação de email. O que é DKIM em termos práticos: ele associa uma assinatura RSA a cada mensagem enviada pelo seu servidor de email. O MTA receptor recupera a chave pública no DNS, verifica essa assinatura e reporta o resultado como dkim=pass ou dkim=fail. Esse resultado alimenta o modelo de reputação do domínio e determina se o alinhamento DMARC se sustenta. Sem uma assinatura válida, o MTA receptor não tem confirmação criptográfica de que a mensagem veio da sua infraestrutura.

DKIM é um protocolo de assinatura, não um filtro

O nome gera um equívoco comum. DKIM não bloqueia emails. Ele não coloca mensagens em quarentena nem aplica políticas por conta própria. O que ele faz é inserir em cada mensagem enviada uma declaração verificável: esta mensagem foi assinada pelo domínio indicado no campo d=, usando a chave privada correspondente ao seletor s=.

O MTA receptor pega essa declaração, constrói uma consulta DNS para <seletor>._domainkey.<domínio>, recupera o registro TXT com a chave pública e executa a verificação criptográfica. Se a verificação passa, o cabeçalho de resultados de autenticação mostra dkim=pass. Em caso de falha, aparece dkim=fail ou dkim=temperror.

Nenhum dos dois resultados causa rejeição imediata. O sinal alimenta o modelo de reputação do servidor receptor e, de forma determinante, a avaliação DMARC. A função do DKIM é produzir um resultado verificável, não agir sobre ele.

O que é assinado e o que a assinatura cobre no DKIM

DKIM assina dois elementos: cabeçalhos selecionados da mensagem e o corpo. O algoritmo de assinatura cria um hash de ambos e armazena o resultado no campo de cabeçalho DKIM-Signature.

A lista de cabeçalhos é controlada pela tag h= na assinatura. Uma configuração típica em produção inclui from:subject:date:message-id:content-type. O cabeçalho from é o relevante para o alinhamento DMARC. O hash do corpo cobre o corpo completo da mensagem, canonizado via simple ou relaxed.

A canonização relaxed é a usada pela maioria dos stacks em produção. Ela normaliza espaços antes do hash, o que permite à assinatura sobreviver a pequenas reformatações por MTAs intermediários. A canonização simple é mais rígida: uma única mudança de espaço no final quebra a assinatura. No campo DKIM-Signature de praticamente todo ESP bem configurado você encontrará c=relaxed/relaxed.

O que o DKIM não assina: o remetente do envelope SMTP, cabeçalhos de roteamento como Received e qualquer cabeçalho fora da lista h=. Isso é intencional. Assinar o envelope quebraria cenários de encaminhamento, que é exatamente a vantagem do DKIM sobre o SPF.

O seletor DKIM: mecanismo de controle de acesso tratado como rótulo

O seletor é a parte do DKIM que a maioria das equipes subestima até precisar rotacionar chaves sob pressão.

O campo s= no seu DKIM-Signature aponta para uma chave pública específica no DNS. O formato de busca é <seletor>._domainkey.<seudomínio.com>. Se o seletor é mail2026 e o domínio é example.com, o resolver procura um registro TXT em mail2026._domainkey.example.com.

Um único domínio pode ter múltiplos seletores ativos simultaneamente. Cada serviço de envio, cada ESP, cada MTA interno deve usar seu próprio seletor. Isso oferece três capacidades operacionais concretas:

• Rotação independente de chaves por serviço sem afetar outros remetentes.

• Atribuição rastreável nos logs de autenticação: o seletor indica qual chave de assinatura foi usada em determinada mensagem.

• Desligamento limpo: exclua o registro DNS do seletor e aquele ESP não poderá mais assinar como o seu domínio, independentemente do que ele faça no lado dele.

O que se observa nas traces: equipes que configuram um seletor compartilhado entre todos os serviços de envio não conseguem revogar o acesso de um único remetente sem interromper todos os outros. O seletor não é cosmético. É um mecanismo de controle de acesso.

DKIM e alinhamento DMARC: como funciona a camada de aplicação

A aprovação do DKIM é um pré-requisito para um tipo específico de aprovação DMARC chamado alinhamento DKIM.

O DMARC requer pelo menos uma das duas condições de alinhamento: alinhamento SPF ou alinhamento DKIM. O alinhamento DKIM significa que o domínio no cabeçalho From: corresponde ao valor d= na assinatura DKIM, e a assinatura é verificada. Quando ambas as condições são satisfeitas, o DMARC considera a mensagem autenticada.

É por isso que o DKIM é o sinal de autenticação mais durável. O alinhamento SPF falha no encaminhamento: quando uma mensagem é encaminhada, o remetente do envelope SMTP muda, e a avaliação SPF falha contra o novo IP de envio. O alinhamento DKIM sobrevive ao encaminhamento porque a assinatura e o cabeçalho From: viajam com o corpo da mensagem e não são reescritos por MTAs intermediários, desde que o corpo não seja modificado em trânsito.

Para domínios com política DMARC p=reject, uma mensagem que falha tanto no alinhamento SPF quanto no DKIM é rejeitada pelo MTA receptor. Esse é o mecanismo que impede emails falsificados do seu domínio de chegar às caixas de entrada em escala. O DKIM não é a última linha de defesa. Mas é a linha que se sustenta quando o encaminhamento está no caminho.

Desde 2024, Google, Yahoo e Microsoft exigem DKIM para remetentes que enviam 5.000 ou mais mensagens por dia para seus MX. Mensagens de domínios não assinados são direcionadas ao spam ou rejeitadas por padrão.

Não é uma funcionalidade de marketing. É uma restrição de infraestrutura.

Comprimento de chave e rotação: decisões práticas para 2026

A maioria das implementações DKIM usa RSA-SHA256. A questão central é o comprimento da chave.

Chaves RSA de 1024 bits ainda aparecem em configurações legadas. O NIST deprecou o RSA de 1024 bits para a maioria dos casos de uso em 2015. Uma chave de 2048 bits oferece margem de segurança significativamente maior e é suportada por todos os principais MTAs e provedores receptores. Se você está gerando uma nova chave hoje, use 2048 bits.

Algumas equipes migraram a chave de assinatura ativa para 2048 bits, mas deixaram seletores antigos de 1024 bits publicados no DNS porque ninguém auditou o inventário. Três sinais que mudam o comportamento do sistema: se você vir k=rsa com uma chave de 1024 bits em um seletor antigo, aquele seletor é uma vulnerabilidade mesmo que sua infraestrutura de assinatura atual já tenha migrado. Um seletor válido mas deprecado é explorável.

Cronograma de rotação de chaves: a maioria das equipes de infraestrutura rotaciona anualmente, algumas trimestralmente para domínios mais sensíveis. A sequência importa:

• Gere um novo par de chaves.

• Publique a nova chave pública sob um novo nome de seletor no DNS.

• Aguarde a propagação do TTL, tipicamente 24 a 48 horas para registros com TTL baixo.

• Atualize a configuração da chave de assinatura no seu MTA para o novo seletor.

• Verifique o DKIM pass em mensagens enviadas via uma ferramenta de teste de email ou inspecionando os cabeçalhos de resultados de autenticação em uma mensagem de teste.

• Após confirmar que a nova chave está ativa e assinando corretamente, exclua o registro DNS antigo.

A rotação não é disruptiva se você seguir a ordem: DNS primeiro, troca de assinatura depois, exclusão do registro antigo por último. Inverter os passos 4 e 6 causa uma janela de dkim=fail.

Sinais operacionais para monitorar após a configuração do DKIM

O DKIM não é uma tarefa de configuração única. Os seguintes sinais indicam que algo mudou ou quebrou.

dkim=temperror em cabeçalhos recebidos. Falhas temporárias geralmente indicam problemas de consulta DNS no lado receptor, ou uma inconsistência de TTL durante a rotação de chaves. Se você vir isso em mensagens enviadas logo após uma rotação de chaves, aguarde a propagação completa antes de concluir que a própria chave está mal configurada.

dkim=fail em mensagens enviadas. Modificação do corpo por um relay intermediário é a causa mais comum. Verifique se há um hop de encaminhamento, um processador de lista de email ou um relay que injeta rodapés no caminho de entrega. Se a falha for consistente em um único fluxo, mapeie a cadeia de relay hop a hop.

Cabeçalho DKIM-Signature completamente ausente. O daemon de assinatura no seu MTA não está em execução, o caminho da chave de assinatura está errado ou o mapeamento domínio-seletor está mal configurado na sua configuração do MTA. Isso é uma falha completa do DKIM para os fluxos de mensagens afetados.

Registro TXT do seletor ausente do DNS. A zona DNS foi editada ou migrada sem preservar o registro do seletor DKIM. Verifique com dig TXT <seletor>._domainkey.<domínio> a partir de um resolver externo.

Em uma configuração de envio multi-região, resultados DKIM inconsistentes entre nós são frequentemente causados por nós diferentes usando configurações de seletor diferentes. Confirme que a configuração da chave de assinatura está sincronizada em todos os nós de envio antes de implementar uma rotação.

O que o DKIM não protege

O DKIM não é um filtro de spam. Um remetente pode registrar um novo domínio, configurar DKIM válido e enviar spam completamente autenticado. A assinatura é verificada sem problemas. A autenticação confirma a origem, não a intenção ou a qualidade do conteúdo.

O DKIM também não aborda a falsificação do nome de exibição, onde o cabeçalho From: mostra um nome confiável como "Equipe de Folha de Pagamento" associado a um domínio controlado pelo atacante. A verificação criptográfica opera no domínio, não na apresentação visual no MUA. A maioria dos ataques de phishing no nível do MUA depende de engano de nome de exibição em vez de falsificação de domínio exato.

O que o DKIM protege: falsificação de domínio exato, onde um atacante tenta enviar como seu domínio sem ter sua chave privada. Combinado com uma política DMARC p=reject que aplica o alinhamento DKIM, isso impede aquela categoria de mensagens falsificadas de chegar às caixas de entrada nos provedores que aplicam DMARC.

Uma nota prática: o DKIM sozinho não é suficiente. O modelo de proteção requer a aplicação da política DMARC no MTA receptor. O DKIM é a camada de autenticação que torna o DMARC significativo. O SPF é a outra camada de autenticação, e lida com a verificação do remetente do envelope. Todos os três trabalham juntos. A ausência de qualquer um deles deixa uma lacuna na cadeia de aplicação.

Se você já configurou DKIM e SPF mas ainda não publicou um registro DMARC, as assinaturas existem mas nenhuma política de aplicação está ativa. O modo de monitoramento (p=none com relatórios rua) é um primeiro passo razoável: você obtém relatórios agregados mostrando taxas de aprovação de autenticação no seu domínio de envio antes de se comprometer com p=quarantine ou p=reject.