guia · configuração de dkim

Como uma equipe de produto deve configurar o DKIM com segurança?

Configure o DKIM escolhendo um domínio de assinatura que pertença à organização e um seletor único para cada provedor ou sistema de assinatura, gerando o par de chaves em um serviço protegido, publicando apenas a chave pública em selector._domainkey.example.com e configurando o caminho de saída real para assinar todas as mensagens pretendidas. Verifique a assinatura com os bytes originais da mensagem em uma caixa postal externa, confirme que o domínio d= está alinhado com o domínio From visível quando o DMARC depender dele e, depois, faça a implantação gradualmente. Documente a propriedade dos seletores, a rotação, a revogação e o rollback antes de mover o tráfego de produção.

Mapeie todos os caminhos de saída reais antes de gerar uma chave

Comece com um inventário, não com um registro DNS. Liste cada sistema que pode emitir e-mails usando os domínios From visíveis da organização: workers da aplicação, provedores transacionais, plataformas de marketing, ferramentas de suporte, sistemas de identidade, softwares de tickets, relays e caminhos de emergência. Para cada um, registre o responsável, as classes de mensagem, o remetente do envelope, o domínio From visível, o domínio DKIM d= atual, o seletor, o componente de assinatura e se outro relay modifica a mensagem depois. Uma chave DKIM publicada para um provedor não faz nada por um caminho diferente que nunca usa sua chave privada. Da mesma forma, um painel genérico de provedor que mostra um domínio verificado não prova que cada tenant, região, fluxo, template ou fallback esteja assinado. Use amostras controladas de cada caminho e preserve seus cabeçalhos originais. Decida quais caminhos são autorizados antes de ativar a assinatura; o DKIM autentica a responsabilidade de um domínio por uma assinatura, não o consentimento do destinatário nem a veracidade do conteúdo da mensagem.

Escolha um domínio de assinatura que permita o alinhamento DMARC

A tag d= do DKIM identifica o domínio de assinatura. Escolha um domínio que a organização controle e possa administrar durante toda a vida do fluxo de e-mail. Quando o DMARC depender do DKIM, o domínio d= deve estar alinhado com o domínio do campo From visível da RFC 5322, segundo a regra de alinhamento aplicável, relaxed ou strict. Um domínio de assinatura do provedor pode produzir um resultado DKIM válido e ainda assim ficar desalinhado com o domínio From da organização. Decida se o domínio raiz ou um subdomínio com finalidade específica deve assinar cada fluxo, considerando a propriedade, a separação de reputação, o DNS delegado e o isolamento de incidentes. Não invente domínios extras apenas para contornar um problema de reputação ou de política. Registre a relação com o domínio organizacional e o modo DMARC pretendido. Teste o alinhamento a partir dos cabeçalhos finais recebidos; nunca o deduza apenas de uma consulta ao seletor, porque a mensagem pode usar outro valor de d=.

Trate os seletores como identidades operacionais

Um seletor permite que um domínio publique várias chaves e as altere sem substituir um registro global. Crie uma política determinística de seletores que identifique um provedor ou signatário e uma geração de rotação sem expor segredos. Por exemplo, product-a-2026q3 pode ser mais claro que default, mas mantenha os nomes dentro das convenções de DNS e dos limites das suas ferramentas. Nunca reutilize uma chave privada entre provedores, ambientes ou tenants não relacionados apenas para reduzir registros DNS. Mantenha um registro com seletor, domínio d=, finalidade, serviço de assinatura, responsável, data de criação, algoritmo, impressão digital da chave pública, estado de implantação, prazo de rotação e evidências de retirada. Verifique o nome exato do seletor antes da publicação: a consulta é `selector._domainkey.signing-domain`. Um registro acidental no domínio From visível, no domínio return-path ou na zona DNS errada não verificará a assinatura pretendida. Evite excluir um seletor antigo até que e-mails atrasados e novas tentativas assinados com ele tenham expirado.

Gere e proteja a chave privada

Gere o par de chaves dentro de um serviço gerenciado de chaves ou de um sistema de assinatura rigidamente controlado, quando o provedor permitir. A chave privada nunca deve ir para o DNS público, o controle de versão, código no navegador, saídas de CI, analytics, logs comuns, tickets, documentos, prompts ou chats compartilhados. Conceda acesso de assinatura apenas ao componente de e-mail que precisa da chave, separe a produção dos ambientes inferiores e registre o acesso administrativo. A RFC 8301 atualiza os requisitos criptográficos do DKIM e diz que os signatários devem usar chaves RSA de pelo menos 1024 bits e deveriam usar pelo menos 2048 bits; ela também aponta restrições operacionais de DNS com chaves maiores. Use os recursos e as recomendações atuais do signatário escolhido e dos destinatários que você atende, em vez de copiar um exemplo obsoleto. Se o Ed25519 for considerado, a RFC 8463 define o uso dele no DKIM, mas a interoperabilidade precisa ser testada e uma estratégia de assinatura compatível deve ser mantida onde for necessário. A rotação deve ser possível sem exportar a chave privada.

Publique a chave pública com precisão

Publique um registro TXT no nome de proprietário exato `selector._domainkey.signing-domain`. O registro de chave DKIM contém tags como v=DKIM1, um tipo de chave quando necessário e p= com o material da chave pública sem delimitadores de chave privada. Siga o formato exato de registro do signatário e o comportamento de aspas do seu provedor DNS. Antes de salvar, verifique se a interface DNS acrescenta a zona automaticamente, divide strings longas ou escapa caracteres. Consulte diretamente os servidores de nomes autoritativos após a publicação, depois consulte resolvedores recursivos independentes e reconstrua o valor TXT completo. Várias strings de caracteres em um registro TXT são concatenadas por clientes DNS, enquanto vários registros de recursos concorrentes podem criar ambiguidade. Preserve a resposta anterior e o TTL para reversão. Não reduza a segurança publicando uma chave mais ampla nem deixando uma flag de teste em produção apenas para silenciar um verificador. Um registro visível prova a publicação no DNS, não que o remetente use a chave privada correspondente.

Configure o signatário final e os campos assinados

Configure o componente que entrega a mensagem final ao transporte de saída, ou garanta que nenhum componente posterior altere o conteúdo assinado. Uma assinatura DKIM cobre um hash do corpo e os campos de cabeçalho listados em h=. A RFC 6376 exige que o campo de cabeçalho From seja assinado para que a assinatura seja válida. Inclua os cabeçalhos críticos de identidade adequados ao produto, entenda como os cabeçalhos repetidos são selecionados e evite assinar campos que um sistema posterior necessário precise reescrever, a menos que essa transformação seja controlada. Escolha a canonicalização de forma deliberada. A canonicalização relaxed tolera alterações definidas de espaços em branco e de formatação de cabeçalhos, mas não permite edições arbitrárias no corpo. A canonicalização simple é mais frágil. Inserção de rodapés, reescrita de links, mudanças nos delimitadores MIME, conversão de transfer-encoding, tags no assunto e normalização de quebras de linha após a assinatura podem quebrar a verificação. Assine a mensagem totalmente renderizada, depois das transformações aprovadas, e impeça que usuários não confiáveis escolham d=, s=, listas de cabeçalhos ou chaves.

Verifique de ponta a ponta as mensagens originais recebidas

Envie mensagens controladas por cada caminho real com formato de produção para caixas postais de teste externas operadas pela equipe. Preserve a mensagem original bruta, e não um corpo copiado ou um anexo de ticket reserializado. Inspecione os valores d= e s= do DKIM-Signature, a lista de cabeçalhos assinados, o hash do corpo, o algoritmo, a canonicalização, o timestamp e qualquer expiração. Consulte a chave pública a partir de uma rede independente e execute um verificador que siga os padrões sobre os bytes originais. Compare o cabeçalho Authentication-Results do destinatário confiável com o seu verificador, respeitando as fronteiras de confiança da RFC 8601. Teste texto simples, multipart alternative, os anexos esperados, assuntos em Unicode, cabeçalhos longos, templates, transformações de rastreamento, novas tentativas e caminhos por relay. Os testes negativos devem incluir um cabeçalho assinado alterado de propósito em uma fixture, um seletor ausente, um seletor expirado ou desativado e um caminho que contorna a assinatura. Nunca adultere e-mails reais de clientes para criar um teste.

Avalie DKIM, DMARC e entrega como resultados separados

Uma aprovação de DKIM significa que o verificador encontrou uma assinatura válida para o domínio de assinatura identificado sobre os campos e o corpo assinados. Ela não autentica todos os cabeçalhos não assinados, não confirma um autor humano, não prova o consentimento do destinatário, não estabelece conformidade legal nem garante aceitação e chegada à caixa de entrada. O DMARC avalia separadamente se um domínio DKIM ou SPF aprovado está alinhado ao domínio From visível e aplica a política do proprietário do domínio. Registre, no mínimo, o resultado e o motivo do DKIM, o domínio d=, o seletor, o domínio From visível, o resultado de alinhamento, o resultado de SPF, o resultado de DMARC, o destinatário e o timestamp em testes controlados. Mantenha endereços completos de destinatários e conteúdo fora das métricas rotineiras. A aceitação pelo provedor SMTP, a aceitação pelo servidor do destinatário, o bounce posterior, a colocação na pasta da caixa postal e o engajamento são estados posteriores. Se o DKIM for aprovado, mas o e-mail for rejeitado ou filtrado, investigue o alinhamento DMARC, SPF, reputação de IP e domínio, taxa de reclamação, política de mensagem, taxa e orientação do destinatário em vez de alternar chaves repetidamente.

Faça a rotação sem criar uma lacuna na verificação

Use seletores sobrepostos. Primeiro, gere uma nova chave protegida e publique o registro público dela em um novo seletor. Verifique o DNS autoritativo e o recursivo, configure o signatário para usar o novo seletor e envie testes controlados por todos os caminhos. Monitore a proporção de assinaturas que usam o seletor antigo e o novo e os resultados de verificação de cada um. Mantenha a chave pública antiga disponível durante a idade máxima das mensagens em fila, a janela de novas tentativas e o período de cache do DNS, mais uma margem de segurança explícita. Depois, pare toda assinatura com o seletor antigo, confirme que nenhuma configuração ativa o referencia e desative o registro dele conforme a política. A revogação de emergência após a exposição da chave privada pode exigir remoção mais rápida, pausa no tráfego, rotação das credenciais do provedor e comunicação do incidente; documente esse trade-off com antecedência. Não sobrescreva um seletor no lugar durante a rotação de rotina, porque chaves públicas antigas em cache podem fazer falhar a verificação de mensagens assinadas com a nova chave privada.

Diagnostique falhas partindo da assinatura

Para uma assinatura ausente, identifique se a mensagem usou um fluxo sem assinatura, um domínio From não autorizado, um relay de fallback ou um caminho de template. Para key-not-found, verifique a consulta exata de s= e d=, a delegação da zona, a resposta autoritativa, erros de DNSSEC ou do resolvedor e a propagação. Para divergência no hash do corpo, compare o MIME bruto antes da assinatura com o recebido para encontrar transformações posteriores à assinatura. Para divergência na assinatura, verifique se a chave pública publicada corresponde à chave privada ativa e inspecione a canonicalização e os cabeçalhos assinados. Para um pass do DKIM com fail do DMARC, avalie o alinhamento com o domínio From visível. Classifique os erros temporários de consulta DNS separadamente das falhas persistentes de configuração e use novas tentativas limitadas no transporte somente quando a resposta SMTP for transitória. Pause o fluxo afetado em caso de assinatura entre domínios, chaves desconhecidas, falhas de verificação generalizadas ou suspeita de exposição da chave. Preserve evidências com o mínimo de dados pessoais e mude uma variável por novo teste controlado.

Use a documentação DKIM do seu sistema de envio

Configure DKIM nos sistemas de envio reais e na autoridade DNS, valide mensagens recebidas originais e baseie-se nos padrões IETF atuais e na documentação específica do provedor.

Perguntas frequentes

Onde a chave pública DKIM é publicada?

Publique-a como um registro TXT em selector._domainkey.signing-domain, usando exatamente o seletor e o domínio d= que a assinatura de saída vai conter.

A chave privada DKIM deve ser colocada no DNS?

Não. O DNS contém apenas o material da chave pública. Mantenha a chave privada dentro de um signatário gerenciado ou de uma fronteira de segredos, com acesso de escopo restrito e controles de rotação.

Um mesmo seletor DKIM pode ser reutilizado para todos os provedores de e-mail?

Evite esse desenho. Separe seletores e chaves privadas por provedor, signatário, ambiente ou fronteira de risco, para que a rotação e um comprometimento não afetem caminhos não relacionados.

Se o DKIM passa, o DMARC também passa?

Não necessariamente. O DMARC exige que o domínio d= do DKIM aprovado esteja alinhado com o domínio From visível, a menos que um pass de SPF alinhado satisfaça o DMARC.

Por que o DKIM falha depois de um rodapé ou de uma reescrita de rastreamento?

O DKIM cobre cabeçalhos selecionados e um hash do corpo. Uma modificação posterior fora das regras de canonicalização escolhidas pode invalidar a assinatura depois de ela ter sido criada.

Como as chaves DKIM devem ser rotacionadas?

Publique e verifique primeiro um novo seletor, mude a assinatura controlada para ele, monitore os resultados, mantenha a chave pública antiga durante as janelas de novas tentativas e de cache e, então, desative-a.

O DKIM determina a chegada à caixa de entrada?

Não. O DKIM fornece evidência de assinatura de domínio com escopo definido. Os destinatários ainda avaliam de forma independente DMARC, SPF, reputação, reclamações, conteúdo, taxas de envio e a política da caixa postal antes de decidir o resultado da entrega.

Um registro DNS público comprova que a assinatura DKIM está ativa?

Não. Valide mensagens recebidas originais em relação à chave publicada e confirme os valores d= e s= no cabeçalho DKIM-Signature.

Fontes

Continue aprendendo

Como verificar o DKIM do e-mail da sua aplicaçãoVerifique o DKIM inspecionando uma assinatura real, consultando o seletor e o domínio, verificando a mensagem, lendo os resultados do destinatário e testando o alinhamento.Como fazer uma verificação de DMARC no e-mail da sua aplicaçãoVerifique a descoberta e a sintaxe do registro DMARC, o alinhamento de SPF e DKIM, a política, os relatórios e mensagens reais da aplicação, sem confundir uma consulta DNS com a entrega.Como verificar um registro SPF para o e-mail da sua aplicaçãoVerifique o domínio SPF correto, a sintaxe, os mecanismos, o orçamento de consultas DNS aninhadas, a autorização do IP de origem, o resultado e o alinhamento DMARC do e-mail da sua aplicação.Como avaliar um serviço de entregabilidade de e-mailAvalie serviços de entregabilidade de e-mail por escopo, evidências, autenticação, feedback loops, supressões, privacidade, portabilidade e adequação operacional.Protocolo de e-mail SMTP: como o e-mail da aplicação trafegaSaiba como a submissão, o relay, os envelopes, os códigos de resposta, o TLS, as novas tentativas e o conteúdo das mensagens moldam o fluxo de e-mail de uma aplicação.