Registro DKIM: seletores, rotação de chaves e diagnóstico

Se as aberturas caem, não revise apenas os assuntos: confira também o DNS e o registro DKIM. O rastreamento de aberturas é incompleto, e sua queda não comprova uma falha de autenticação.

SPF verifica a autorização do IP para uma identidade SMTP; DKIM, DomainKeys Identified Mail, permite validar uma assinatura sobre dados específicos da mensagem. Não comprova que todo o conteúdo seja idêntico nem garante a identidade humana visível. Desde 2024, Google e Yahoo exigem DKIM para os envios em massa abrangidos por suas regras. Falhas podem contribuir para rejeição ou spam, sem determinar sozinhas o destino.

Para um fundador, configurar DKIM pode parecer uma tarefa de dez minutos, mas o prazo varia. Para um prestador com 500 domínios, envolve manter seletores, rotações e sintaxe DNS, inclusive quando um problema aparece às 9 da noite de uma sexta-feira.

Este guia operacional explica como o registro DKIM funciona no DNS, como lidar com o limite de 255 octetos por cadeia TXT e como investigar falhas quando o painel de verificação não corresponde a um envio real.

O que é um registro DKIM

Um registro DKIM publica uma chave pública em TXT DNS, diretamente ou por uma delegação aceita pelo provedor. O receptor verifica uma assinatura associada ao domínio signatário e a integridade dos dados cobertos conforme a canonicalização. Isso não comprova por si só a autorização do autor visível nem a ausência de conteúdo malicioso.

A consulta usa selector._domainkey.yourdomain.com, em que selector identifica a chave. Este exemplo está abreviado e não pode ser publicado como chave válida:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1 declara a versão; k=rsa, o tipo de chave; e p= contém a chave pública em base64. A privada permanece na infraestrutura signatária e não deve entrar no DNS. O guia de criação de registros DKIM explica os campos e o processo completo.

O que DKIM assina e por que importa

DKIM não é apenas uma opção de configuração. Vincula uma assinatura ao domínio signatário e permite verificar os dados cobertos, mas não garante a identidade humana do remetente nem protege todas as partes da mensagem.

O servidor deve assinar From e pode selecionar outros cabeçalhos, normalmente Subject, Date, To e Message-ID, além do corpo coberto. Aplica canonicalização e um resumo criptográfico, normalmente SHA-256, e assina com a chave privada. A assinatura acompanha a mensagem no cabeçalho DKIM-Signature.

Quando Gmail, Outlook ou outro servidor recebe a mensagem:

1. Lê DKIM-Signature para obter seletor e domínio signatário.
2. Consulta a chave pública em selector._domainkey.yourdomain.com com os valores da assinatura.
3. Verifica criptograficamente a assinatura com a chave pública, sem descriptografar o conteúdo da mensagem.
4. Recalcula os resumos dos dados recebidos conforme os parâmetros da assinatura.
5. Verifica a correspondência e as demais condições, obtendo DKIM pass ou um resultado de falha.

Duas propriedades da validação são a autenticidade da assinatura em relação à chave do domínio signatário e a integridade dos dados cobertos dentro da canonicalização. Nem todo byte da mensagem inteira precisa permanecer idêntico. A chave pública correta permite a verificação. A especificação está no RFC 6376, útil para analisar conformidade e limites do mecanismo.

Encaminhamento: quando DKIM pode sobreviver

Imagine que o diretor de um cliente envia uma fatura a alguém que a encaminha por alias para o Gmail. Se o remetente original do envelope for mantido e o novo IP não estiver autorizado, SPF pode falhar. DMARC só falha sem outra via válida e alinhada, como DKIM. O tratamento depende da política do receptor, não de uma rejeição inevitável.

DKIM pode sobreviver ao encaminhamento se os dados cobertos permanecerem compatíveis e a chave e demais condições continuarem válidas. O receptor final consulta o DNS do signatário original. Modificações de listas ou gateways podem, porém, invalidar a assinatura.

Combine DKIM com uma configuração SPF adequada; o guia de SPF para e-mail explica o essencial. DMARC exige SPF aprovado e alinhado ou alguma assinatura DKIM válida e alinhada, não obrigatoriamente os dois.

SRS, conforme a configuração de encaminhamento do TrekMail, reescreve a identidade do envelope para permitir SPF no domínio do intermediário; não restaura o alinhamento SPF com o From original. Confirme também quais rotas de saída são assinadas pelo TrekMail ou pelo seu SMTP externo, sem presumir cobertura universal por padrão.

Seletores e gestão de várias chaves DKIM

O seletor DKIM indica qual chave pública o receptor deve consultar. Um valor incorreto pode causar falhas, mas este guia não apresenta uma proporção medida de todas as causas.

SPF admite uma política aplicável por nome, não apenas um TXT de qualquer tipo. DKIM permite vários seletores, como selector._domainkey.yourdomain.com, conforme a capacidade DNS e do serviço. Você pode manter dez seletores ativos se necessário, por exemplo um por provedor.

Por que usar vários seletores

Com Google Workspace e Mailchimp, chaves distintas por serviço costumam ser mais práticas e reduzem o alcance de uma exposição. Compartilhar a privada aumenta os riscos e não é aceito por todos os serviços. Cada provedor usa seu seletor:

• Google Workspace: Pode usar google em google._domainkey.yourdomain.com; confirme o valor atribuído.
• Mailchimp: Pode indicar k1 ou k2, por exemplo em k1._domainkey.yourdomain.com. Siga as instruções atuais.
• TrekMail: Pode fornecer tm1 em tm1._domainkey.yourdomain.com, com TXT ou CNAME conforme a configuração indicada.

Separar chaves permite revogar k1 em caso de exposição do serviço de marketing sem necessariamente revogar a chave corporativa. Ainda assim, revise mensagens em trânsito, dependências e efeitos: seletores não garantem continuidade nem isolamento absoluto de reputação. O guia de seletores explica a sintaxe e como identificar os valores atribuídos.

Um erro clássico de publicação

Alguns painéis adicionam o domínio automaticamente: você pretende criar google._domainkey.yourdomain.com, mas termina com google._domainkey.yourdomain.com.yourdomain.com. A consulta ao nome esperado pode retornar NXDOMAIN apesar do outro registro existir. Compare painel, DNS e assinaturas reais. A verificação do status DNS mostra como investigar com uma consulta dig.

Tamanho da chave e rotação

A chave influencia a segurança DKIM. Uma configuração de cinco anos atrás merece revisão, mas a idade não comprova sozinha fraqueza ou comprometimento. Verifique algoritmo, tamanho, proteção e requisitos atuais.

Chaves de 2048 bits

Chaves RSA de 1024 bits foram usadas por muitos anos. O Google mantém esse mínimo e recomenda 2048 bits quando possível; confira separadamente as exigências atuais do Yahoo. Se uma instalação antiga de cPanel ou Postfix usava 1024 bits antes de 2019, revise a política e planeje uma atualização, sem deduzir falha apenas pela data.

Uma chave de 512 bits é inadequada. Ao encontrar dkim=perm_fail com motivo de chave fraca ou política, confirme a causa real. Gere uma chave de 2048 bits quando apropriado, publique novo seletor antes de assinar e mantenha a chave pública anterior enquanto mensagens em trânsito precisarem ser verificadas. Consulte as diretrizes do Google para remetentes.

Frequência de rotação

Uma rotação anual é uma política operacional possível, não uma obrigação universal DKIM. Se a privada for exposta por invasão, gestão inadequada de segredos ou acesso excessivo, responda conforme o incidente: alguém poderá assinar enquanto a chave continuar aceita. Não espere a deterioração da reputação do domínio de e-mail.

Trate a privada como segredo sensível. Mantê-la por cinco anos exige política justificada e reavaliada, sem indicar automaticamente comprometimento. Proteção e resposta a incidentes importam tanto quanto calendário.

O limite DNS de 255 octetos e sua gestão

Ao usar chaves de 2048 bits, um valor público de 2048 bits em base64 pode ter cerca de 400 caracteres, conforme a codificação. Cada cadeia TXT admite 255 octetos. Painéis podem dividir, rejeitar ou tratar valores longos de outras formas; truncamento silencioso não é universal.

Uma chave longa pode ocupar várias cadeias entre aspas em um único TXT. O RFC 6376 prevê sua concatenação sem inserir espaços antes de interpretar a chave.

Exemplo abreviado de uma cadeia longa, não publicável como chave completa:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

Exemplo estrutural com duas cadeias concatenadas; substitua o conteúdo abreviado:

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

A entrada depende do provedor DNS. Alguns aceitam notação de arquivo de zona com parênteses; outros gerenciam cadeias no painel. Não crie TXT independentes. Consulte a configuração DNS nos provedores mais usados para Cloudflare, Route 53, GoDaddy e outros.

Uma delegação CNAME aceita pelo TrekMail pode evitar a gestão local do TXT longo: você publica o alias curto, abaixo de 255 caracteres neste exemplo, e o provedor administra o destino. Confira valores, chaves por domínio e estratégia de seletores. CNAME não pode coexistir com TXT no mesmo nome, e um alias estável não garante rotação transparente.

Verificação da configuração

Não dependa apenas de “Verificado”. O painel pode mostrar dados de horas ou dias atrás. Combine DNS autoritativo, resolvedores pertinentes e testes de assinatura; uma consulta isolada não confirma todo o processo.

Passo 1: verificar o nome DNS

No Linux ou macOS, use o terminal. No Windows, abra a linha de comando e use nslookup:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Substitua selector pelo seletor do envio e yourdomain.com pelo seu domínio.

v=DKIM1 pode indicar a versão, embora sua ausência não invalide automaticamente a chave quando se aplica o padrão. NXDOMAIN não é esperado: NXDOMAIN informa que o nome não existe naquela resposta. Confira nome, publicação e caches. Esperar 30 minutos é uma sugestão ilustrativa, não um prazo garantido de propagação.

Passo 2: validar o conteúdo da chave

Se o nome existir e as falhas persistirem, examine o valor:

dig txt selector._domainkey.yourdomain.com +short

Confira dois aspectos:

• Truncamento: Uma cadeia base64 abaixo de 200 caracteres para uma chave RSA esperada de 2048 bits pode estar incompleta. O tamanho é pista, não prova; concatene todas as cadeias e valide a chave.
• Caracteres alterados: Revise a cadeia base64, quebras, espaços e escapes conforme o formato TXT e a interpretação DKIM. Alguns espaços permitidos não mudam a chave; outros erros invalidam a codificação. Compare o valor interpretado com a pública fornecida.

Passo 3: enviar e ler os cabeçalhos

Envie para um Gmail que você controla, abra o menu de três pontos e “Mostrar original”. Procure Authentication-Results adicionado pelo servidor receptor confiável, não por um remetente arbitrário:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass confirma aquela verificação. Se esperava uma assinatura válida e vê fail, neutral, perm_fail ou temperror, investigue o motivo completo; nomes podem depender da implementação e neutral nem sempre indica erro. O guia DKIM descreve o processo, e a lista de primeira configuração complementa as etapas de autenticação.

Falhas DKIM: três cenários

A chave correta pode existir no DNS sem que a assinatura passe. Confira a assinatura concreta, dados recebidos e todo o percurso; “deveria funcionar” não basta.

O guia de diagnóstico DKIM detalha resultados e motivos. Estes três cenários são exemplos práticos, não uma classificação medida das causas mais frequentes.

Cenário 1: resumo do corpo não confere

Uma falha no resumo do corpo pode afetar a entregabilidade. O hash calculado não corresponde ao declarado, por mudanças incompatíveis nos dados cobertos ou outros problemas de processamento. Isso não comprova que a assinatura dos cabeçalhos seja criptograficamente válida.

Possíveis causas:

• Avisos de remetente externo: Um gateway adiciona “E-MAIL EXTERNO - ATENÇÃO” antes de verificar DKIM. Isso pode invalidar o corpo assinado. Revise a ordem de verificação e modificação, inclusive no Microsoft 365 com regras de fluxo.
• Avisos legais: Um gateway adiciona um rodapé de 15 linhas após a assinatura, o que pode alterar o resumo. Assine a versão final sob seu controle, depois de revisar a cobertura.
• Reescrita de URLs: Mimecast, Proofpoint ou Defender for Office 365 podem transformar google.com em protect.mimecast.com/s/.... Mudanças incompatíveis com canonicalização e cobertura podem invalidar o resumo; nem toda alteração de bytes faz isso.

Na saída, assine após suas últimas modificações. Na recepção, verifique antes de alterar e preserve resultados confiáveis. Assinar no final do gateway não impede mudanças posteriores em outros sistemas. Confirme as rotas e a ordem aplicáveis no TrekMail; consulte o diagnóstico de erros de envio.

Cenário 2: falta de alinhamento

Você pode encontrar este resultado nos cabeçalhos:

dkim=pass (signature was valid)

DKIM passa, mas DMARC pode falhar por falta de alinhamento DKIM, se nenhuma outra via válida e alinhada existir. O destino posterior depende do receptor.

DMARC compara o domínio d= de uma assinatura válida com Header From. O modo estrito exige correspondência exata; o relaxado permite o mesmo domínio organizacional. Qualquer assinatura DKIM válida e alinhada pode oferecer essa via.

Exemplo ilustrativo:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

A assinatura é válida para sendgrid.net. A política DMARC do domínio do autor é avaliada em relação a yourcompany.com: sendgrid.net != yourcompany.com. Essa assinatura não se alinha, mas SPF aprovado e alinhado ou outra assinatura DKIM alinhada ainda pode permitir DMARC.

O provedor pode oferecer autenticação de domínio ou assinatura personalizada. Configure uma chave DKIM para seu domínio conforme suas instruções, para que d= use yourcompany.com em vez de sendgrid.net quando apropriado. Suporte e publicação TXT ou CNAME variam. Entenda o alinhamento DMARC antes de alterar fluxos de produção.

Cenário 3: chaves fracas ou não aceitas

dkim=perm_fail por política ou chave fraca exige examinar a chave real. Chaves de 512 ou 768 bits são inadequadas aos requisitos atuais pertinentes, mas o motivo não comprova sozinho aquele tamanho. Uma falha permanente de autenticação também não significa que toda a mensagem seja irrecuperável ou que nenhuma outra assinatura seja válida.

Planeje um novo par de chaves de 2048 bits com seletor distinto: publique, verifique, altere a assinatura e mantenha a chave pública anterior enquanto necessário. Em caso de comprometimento, adapte a revogação ao incidente. Não apague primeiro a única chave ativa. Consulte as orientações de geração local e o guia de geradores DKIM.

Geradores de chaves e cuidados

DKIM precisa de um par de chaves. Se um gerador web mostra a privada, verifique onde ela é criada e quem pode acessá-la antes de usar em produção.

Exibir a chave no navegador não comprova comprometimento por definição: a geração pode ser local. Porém, serviço remoto ou código não confiável pode conhecê-la ou expô-la. Quem a obtém pode assinar enquanto ela continua aceita, não necessariamente para sempre. Prefira ambiente local controlado ou infraestrutura de provedor confiável.

Comparar métodos de geração

Ao administrar seu próprio servidor, você pode gerar localmente com OpenSSL após proteger acesso e permissões:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

A privada não deve ser transmitida sem necessidade autorizada e canal seguro. DNS recebe a pública no formato apropriado: cat apenas mostra o PEM, sem remover cabeçalhos nem converter automaticamente para o valor DNS. Recuse pedidos para enviar a privada por e-mail para “verificação”.

Fundadores e agências podem delegar a geração a um provedor confiável quando o serviço oferece essa gestão. Confirme proteção, rotação, revogação e alcance em vez de presumir controles iguais em todos.

Gestão manual e automatizada

A rotação evidencia o trabalho operacional DKIM. Revise periodicamente cada chave e suas dependências. Este exemplo anual compara processos, sem impor um calendário universal.

Exemplo de rotação manual anual por domínio

1. Gere um par RSA com novo seletor, por exemplo s2026.
2. Publique a chave pública em s2026._domainkey.yourdomain.com.
3. O exemplo reserva 48 horas; verifique publicação e caches, sem presumir prazo universal.
4. Somente após validar a nova chave, configure a saída com a nova chave privada.
5. O exemplo mantém ambas as chaves públicas por 7 dias; ajuste a sobreposição às filas e mensagens ainda verificáveis.
6. Retire o seletor antigo quando não for mais necessário, conforme a política de incidente.
7. Destrua de forma segura a chave privada retirada quando não deva mais ser guardada, incluindo cópias pertinentes.

São 7 etapas por domínio: com 50 domínios, 350 operações antes de testes adicionais. Omitir a etapa 5 pode afetar mensagens em trânsito; esquecer a 6 pode manter uma chave pública desnecessária. Publicar a chave pública não expõe por si só a chave privada. O processo pode ser automatizado com controles.

Para um único domínio, o trabalho manual pode ser viável. Com 50, automação e registro de mudanças ajudam a evitar esquecimentos, sem garantir ausência de diagnóstico em uma sexta-feira.

O papel do TrekMail na gestão DKIM

TrekMail atende à gestão de vários domínios, de um fundador com cinco projetos a um prestador com 800 domínios de clientes. Verifique se a implementação disponível cobre seus percursos e necessidades.

Delegação CNAME e rotação

O assistente pode indicar um CNAME ao adicionar o domínio. Este exemplo do texto não é um destino a reutilizar sem validação:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Uma delegação estável permite ao provedor gerenciar o TXT de destino. Substituir a chave sob o mesmo seletor pode invalidar assinaturas antigas ou em trânsito, além de envolver caches. Confirme a rotação coordenada com sobreposição e novos seletores quando necessária; não presuma ausência de interrupções. Uma carteira de 80 domínios ainda exige acompanhamento mesmo com menos edições DNS.

O exemplo de Pro a $8 por mês para 100 domínios estima 700 operações manuais evitadas por ano. É comparação ilustrativa, não preço atual verificado ou economia garantida; testes e controles continuam necessários.

Assistente DNS

O assistente TrekMail pode reunir recomendações MX, SPF, DKIM e DMARC e verificações disponíveis. Qualquer resolvedor pode ter cache: confirme resultados, inventário e envios reais antes de confiar no status. Consulte os registros DNS necessários.

Modelo sem preço por usuário

O modelo descrito cobra pela plataforma dentro de limites. O texto cita Starter a $3.50 por mês com 50 domínios e 100 usuários por domínio, Pro a $8 por mês com 100 domínios e 300 usuários por domínio e Agency com 1,000+ domínios. Confira preços, armazenamento compartilhado, assinatura DKIM e limites atuais; adicionar contas não garante custo indefinidamente igual.

A configuração DNS e DKIM depende dos percursos e recursos do plano. Confira disponibilidade e responsabilidades, sem presumir toda autenticação gerenciada por padrão em qualquer transporte.

Comparação de gestão DKIM

Conclusão

Um registro DKIM correto importa para a autenticação em 2025 e depois, especialmente nos envios sujeitos a requisitos dos provedores. Sua ausência nem sempre gera falha DMARC, pois SPF válido e alinhado pode oferecer outra via, mas reduz a verificação de assinaturas e pode afetar o tratamento.

Comece por uma chave RSA de 2048 bits quando apropriado, seletor correto, TXT concatenado adequadamente e alinhamento com From. Depois defina rotação, revogação e política DMARC com inventário e testes, complementados pelo Google Postmaster Tools quando houver dados.

A comparação SPF, DKIM e DMARC explica suas relações e a ordem de preparação. Ao investigar entregabilidade, o guia para evitar e-mails no spam ajuda a priorizar conforme as evidências.

Com vários domínios, documente e automatize quando útil: uma chave incompleta ou assinatura não alinhada pode afetar os fluxos pertinentes. A delegação CNAME do TrekMail pode reduzir tarefas, mas não elimina todas as causas de falha. Consulte os planos e confira a opção gratuita descrita para 10 domínios sem cartão de crédito e suas condições atuais.