Em 2016, hackers invadiram o sistema de e-mail de uma grande campanha política. Mas a parte mais danosa não foi a invasão em si—foi o que veio depois. Os atacantes modificaram alguns dos e-mails roubados antes de divulgá-los, acrescentando conteúdo fabricado a conversas reais. Sem assinaturas criptográficas, não havia como provar quais e-mails eram autênticos e quais haviam sido alterados.
Esse é o problema que o DKIM resolve. Não apenas provar que um e-mail veio de quem diz ter vindo, mas provar que ele não foi modificado desde que foi enviado.
DKIM—DomainKeys Identified Mail—adiciona uma assinatura criptográfica a cada e-mail que você envia. Essa assinatura é matematicamente vinculada ao conteúdo do e-mail. Altere um único caractere e a assinatura se torna inválida. É o equivalente digital a um lacre que revela qualquer violação.
A criptografia por trás do DKIM
O DKIM utiliza criptografia de chave pública, a mesma tecnologia que protege conexões HTTPS e carteiras de criptomoedas. Se você não conhece bem como isso funciona, aqui vai o conceito essencial.
Você gera duas chaves ligadas matematicamente: uma chave privada e uma chave pública. Qualquer coisa criptografada com a chave privada só pode ser descriptografada com a chave pública, e vice-versa. A chave privada permanece secreta; a chave pública é compartilhada com o mundo.
Quando você envia um e-mail, seu servidor de e-mail pega certas partes da mensagem—tipicamente o endereço From, Subject, Date e o corpo—e cria um hash (uma impressão digital de tamanho fixo) desse conteúdo. Em seguida, criptografa esse hash usando sua chave privada. O hash criptografado é sua assinatura DKIM.
A assinatura é adicionada ao e-mail como um cabeçalho. Quando o e-mail chega ao destino, o servidor de recebimento recupera sua chave pública no DNS, descriptografa a assinatura para obter o hash original e então cria seu próprio hash do conteúdo do e-mail. Se os dois hashes coincidirem, o e-mail é autêntico e não foi modificado. Se não coincidirem, algo mudou.
A beleza desse sistema é que somente alguém com sua chave privada pode criar uma assinatura válida. E como a assinatura está vinculada ao conteúdo do e-mail, qualquer modificação—mesmo a adição de um espaço—invalida a assinatura.
O que o DKIM realmente assina
Nem todas as partes de um e-mail são assinadas. O DKIM permite especificar quais cabeçalhos incluir na assinatura, e essa escolha importa mais do que você imagina.
O cabeçalho 'From' sempre é assinado—esse é o objetivo, provar quem enviou o e-mail. A maioria das implementações também assina 'To', 'Subject', 'Date' e 'Message-ID'. O corpo do e-mail é assinado separadamente (seu hash aparece no campo 'bh' da assinatura).
Cabeçalhos que podem mudar legitimamente durante o trânsito—como os cabeçalhos 'Received' que são adicionados por cada servidor pelo qual o e-mail passa—geralmente não são assinados. Se fossem, a assinatura quebraria toda vez que o e-mail fosse retransmitido.
Essa assinatura seletiva é ao mesmo tempo um recurso e uma limitação. Ela permite que os e-mails passem por vários servidores sem quebrar o DKIM, mas também significa que cabeçalhos não assinados podem ser modificados sem detecção. Um invasor sofisticado poderia potencialmente adicionar cabeçalhos enganosos a um e-mail legitimamente assinado.
Seletores e rotação de chaves
Quando você busca uma chave pública DKIM no DNS, você não consulta apenas o domínio—você consulta um 'seletor' específico dentro desse domínio. Esse detalhe aparentemente pequeno habilita algumas capacidades importantes.
Um seletor é apenas um nome que identifica qual chave usar. Sua assinatura DKIM inclui um campo 's=' especificando o seletor, e o servidor de recebimento faz uma consulta a [selector]._domainkey.[yourdomain] para encontrar a chave pública.
Por que isso importa? Porque permite ter várias chaves ativas simultaneamente. Você pode usar seletores diferentes para serviços de e-mail diferentes—um para sua plataforma de marketing, outro para seus e-mails transacionais. Cada serviço tem sua própria chave privada e, se uma for comprometida, você pode revogá-la sem afetar as demais.
Seletores também viabilizam a rotação de chaves. A boa prática de segurança recomenda gerar novas chaves periodicamente, mas você não pode simplesmente trocar as chaves instantaneamente—e-mails em trânsito assinados com a chave antiga falhariam na verificação. Com seletores, você pode publicar uma nova chave sob um novo seletor, começar a assinar novos e-mails com ela e manter a chave antiga ativa até que todos os e-mails em trânsito sejam entregues. Depois você remove a chave antiga.
A maioria dos serviços de e-mail lida com isso automaticamente, mas se você está gerenciando sua própria infraestrutura de e-mail, a rotação de chaves é algo que precisa ser planejado.
A relação do DKIM com o SPF e o DMARC
O DKIM não existe isoladamente. É uma peça de um sistema de autenticação de e-mail em três partes, e entender como as peças se encaixam é crucial.
SPF verifica se o servidor remetente está autorizado a enviar pelo domínio. DKIM verifica se o conteúdo do e-mail é autêntico e não foi modificado. Mas nenhum dos dois, sozinho, vincula a autenticação ao endereço 'From' que os destinatários realmente veem.
É aqui que entra o DMARC. DMARC exige que SPF ou DKIM (ou ambos) passem AND que o domínio autenticado esteja alinhado com o domínio visível em 'From'. Sem DMARC, um atacante poderia enviar um e-mail que passa no SPF para o próprio domínio dele enquanto exibe seu domínio no cabeçalho 'From'.
DKIM tem uma vantagem significativa sobre SPF: ele sobrevive ao encaminhamento. Quando alguém encaminha seu e-mail, o IP do servidor de encaminhamento não estará no seu registro SPF, então o SPF falha. Mas a assinatura DKIM viaja com o conteúdo do e-mail, permanecendo válida mesmo após o encaminhamento. É por isso que ter ambos SPF e DKIM é importante—eles cobrem as fraquezas de cada um.
Quando o DKIM falha
Falhas de DKIM acontecem, e nem sempre por causa de atacantes. Entender as causas comuns ajuda a solucionar problemas de entregabilidade.
A causa mais comum é a modificação de conteúdo por servidores intermediários. Alguns gateways de segurança de e-mail adicionam rodapés aos e-mails de saída ou modificam links para fins de rastreamento. Se essas modificações acontecerem após a assinatura DKIM, a assinatura se torna inválida. A correção é garantir que a assinatura DKIM ocorra por último, depois de todas as modificações de conteúdo.
Listas de e-mail são outro culpado frequente. Muitas listas modificam a linha de Subject (adicionando prefixos '[listname]') ou acrescentam rodapés. Como Subject normalmente é assinado, essas modificações quebram o DKIM. Alguns softwares modernos de listas de e-mail re-assinam os e-mails com a chave DKIM da própria lista, mas muitos não.
Incompatibilidades de chaves também causam falhas. Se você rotacionar sua chave DKIM mas não atualizar o DNS, ou se houver um erro de digitação no registro DNS, a verificação falhará. Sempre teste após fazer alterações.
Por fim, desvio de relógio pode causar problemas. Assinaturas DKIM incluem um carimbo de data e hora, e algumas implementações rejeitam assinaturas muito antigas ou “do futuro”. Se o relógio do seu servidor de e-mail estiver significativamente errado, as assinaturas podem falhar na verificação.
Configurando o DKIM corretamente
Se você usa um serviço de e-mail gerenciado como Google Workspace, Amazon SES ou uma API de e-mail dedicada, a configuração do DKIM geralmente é simples—eles geram as chaves e informam qual registro DNS adicionar. Mas ainda há decisões a tomar e armadilhas a evitar.
O tamanho da chave importa. O mínimo é 1024 bits, mas 2048 bits agora é a recomendação padrão. Alguns sistemas mais antigos não suportam chaves de 2048 bits no DNS (há soluções que envolvem dividir a chave em várias strings), mas isso é cada vez mais raro. Não use chaves de 1024 bits em novas configurações.
Teste exaustivamente antes de depender do DKIM. Envie e-mails de teste para Gmail, Outlook e Yahoo, depois verifique os cabeçalhos para confirmar que o DKIM está passando. Procure por 'dkim=pass' no cabeçalho Authentication-Results. Se você vir 'dkim=fail' ou nenhum resultado de DKIM, há algo errado.
Monitore seus relatórios de DMARC. Eles mostrarão as taxas de aprovação/falha de DKIM em todos os seus e-mails. Um aumento repentino nas falhas pode indicar um problema de configuração, uma chave comprometida ou alguém tentando fazer spoof do seu domínio.
Planeje a rotação de chaves desde o início. Mesmo que você não esteja rotacionando chaves hoje, configure sua infraestrutura para que você possa fazer isso. Use nomes de seletores significativos que incluam datas ou números de versão, deixando claro qual chave é a atual.
Frequently asked questions
O DKIM criptografa meus e-mails?
Não. O DKIM assina os e-mails; ele não os criptografa. A assinatura prova a autenticidade e a integridade, mas o conteúdo do e-mail ainda é legível por qualquer pessoa que o intercepte. Para criptografia, você precisa de S/MIME ou PGP, ou depender de TLS para criptografia em trânsito.
Posso usar a mesma chave DKIM para vários domínios?
Tecnicamente sim, mas não é recomendado. Se a chave for comprometida, todos os domínios serão afetados. Cada domínio deve ter seu próprio par de chaves. A maioria dos serviços de e-mail faz isso automaticamente.
Por que alguns dos meus e-mails passam no DKIM e outros falham?
Geralmente isso significa que algo está modificando alguns e-mails após a assinatura. Verifique se você tem ferramentas de segurança de e-mail, auto-respostas ou regras de encaminhamento que possam alterar o conteúdo. Também confirme que todas as suas fontes de envio estão configuradas corretamente para DKIM.
Com que frequência devo rotacionar chaves DKIM?
Não há um padrão universal, mas anualmente é uma base razoável. Rotação mais frequente (trimestral) é melhor se você puder automatizá-la. O importante é ter um processo de rotação estabelecido, não a frequência específica.