Uma configuração de DKIM correta é essencial para autenticar mensagens de um domínio personalizado e favorecer a entrega. Uma chave ausente, inválida ou truncada, ou uma assinatura com o domínio errado, pode prejudicar a chegada à caixa de entrada. Este guia apresenta o procedimento operacional: gerar a chave, publicar o registro DNS, verificar pela linha de comando e identificar erros de alinhamento que ainda podem fazer DMARC falhar depois de uma verificação favorável no painel.
Para uma configuração completa com MX, SPF, caixas postais e clientes de e-mail, comece por criar e-mail com seu domínio. Se você está escolhendo a plataforma primeiro, e-mail empresarial apresenta a decisão mais ampla.
O problema é simples. A maioria das falhas de DKIM não vem da criptografia, mas de erros ao copiar DNS, painéis que acrescentam o domínio duas vezes, chaves de 2048 bits danificadas ou um provedor de envio que assina com seu próprio domínio em vez do seu. Você pode perder horas procurando a causa errada. A solução é um procedimento repetível.
O que a configuração de DKIM realmente faz
Configurar DKIM publica uma chave pública no DNS e permite que o servidor assine cada mensagem com a chave privada correspondente. Os destinatários verificam a assinatura, confirmam a responsabilidade do domínio signatário e detectam alterações nos cabeçalhos assinados ou no corpo durante o trânsito.
DKIM usa criptografia assimétrica. O sistema de envio guarda a chave privada; o DNS publica a chave pública. Ao sair do servidor, a mensagem recebe um cabeçalho DKIM-Signature com um domínio signatário (d=) e um seletor (s=). O destinatário consulta o seletor no DNS e valida a assinatura em relação ao conteúdo. O mecanismo é definido no RFC 6376.
Desde fevereiro de 2024, o Google reforçou os requisitos para remetentes em massa. Informa que eles devem configurar SPF e DKIM, e que pelo menos um precisa estar alinhado ao domínio do cabeçalho From visível para passar no alinhamento DMARC. Consulte o texto atual nas perguntas frequentes sobre as diretrizes do Google para remetentes.
Isso importa porque uma assinatura tecnicamente válida nem sempre atende ao objetivo. Uma configuração DKIM inválida ou desalinhada pode deixar problemas de spam, falhas DMARC ou ambos.
Antes de alterar o DNS
Uma boa configuração começa identificando quem realmente assina o e-mail. Parece óbvio, mas é nesse ponto que migrações, mudanças de encaminhamento ou trocas de fornecedor podem interromper envios. O lugar certo para gerar ou obter registros DKIM depende inteiramente do caminho de envio.
Primeira pergunta: quem envia o e-mail de saída desse domínio?
- Se o Google Workspace envia, gere a chave DKIM no Google Admin.
- Se o Microsoft 365 envia, habilite DKIM nesse serviço.
- Se SendGrid, Mailgun ou Amazon SES envia, autentique o domínio nesse fornecedor.
- Se TrekMail Managed SMTP envia, use os valores DKIM exibidos no TrekMail.
- Se TrekMail cuida das caixas, mas você usa SMTP externo, siga as instruções de assinatura desse provedor e configure SMTP no TrekMail se necessário.
O TrekMail contempla os dois caminhos conforme o plano. O Nano usa BYO SMTP; os planos pagos podem usar SMTP gerenciado. A documentação de Bring Your Own SMTP apresenta exemplos de SES, SendGrid e Mailgun. A documentação de diagnóstico também informa que Managed SMTP assina com a chave DKIM do seu domínio, o que pode ajudar DMARC em encaminhamentos e relays se a assinatura permanecer válida e alinhada.
Exemplo: a caixa postal está no TrekMail, mas o envio passa pelo SendGrid. O SendGrid precisa assinar. O TrekMail pode hospedar a caixa, mas não configura automaticamente o DKIM do SendGrid por você.
Primeira regra: gere as chaves no sistema que assina a mensagem. Em outro lugar, o registro pode existir no DNS sem produzir efeito algum.
Tipos de registro DKIM: TXT ou CNAME
A configuração geralmente publica um TXT com a chave pública. Alguns fornecedores pedem um ou mais CNAMEs apontando para chaves hospedadas por eles. Os dois métodos funcionam. O importante é usar exatamente os valores fornecidos pelo sistema de envio.
A configuração clássica usa um TXT em:
selector._domainkey.example.comO valor tem este formato:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...Serviços gerenciados costumam usar CNAME para rotacionar chaves sem pedir outra alteração DNS. Com TXT, você tem controle direto, mas também precisa atualizar o registro quando a chave for rotacionada.
| Método | O que publicar | Mais indicado para | Principal risco |
|---|---|---|---|
| TXT | Chave pública completa no DNS | Google Workspace e muitas configurações autogerenciadas ou diretas | Chaves longas truncadas ou copiadas incorretamente |
| CNAME | Alias para um registro DKIM hospedado pelo fornecedor | Plataformas gerenciadas e rotação de chaves mais simples | Destino errado ou falta de um dos registros necessários |
A armadilha está no campo de host. Se o domínio é example.com e o seletor é k1, normalmente você informa:
k1._domainkeyNão isto:
k1._domainkey.example.comMuitos painéis DNS acrescentam o domínio raiz automaticamente. Se você digita o nome completo nesse tipo de painel, publica k1._domainkey.example.com.example.com. O registro não fica no endereço esperado pelos destinatários.
Para uma referência da camada DNS necessária no TrekMail, consulte registros DNS necessários. A documentação também explica que alguns fornecedores exigem dividir valores TXT DKIM em partes entre aspas.
Configuração de DKIM passo a passo no DNS
O procedimento é curto: obtenha o seletor, publique o registro, aguarde a atualização DNS, confira a resposta exata e habilite a assinatura se o fornecedor exigir uma ativação final. Sem verificar, você está apenas supondo que funciona.
Siga este procedimento.
- Abra o provedor de envio e gere ou exiba o registro DKIM.
- Copie o seletor exatamente. Não renomeie, a menos que o provedor permita.
- Crie o registro DNS em
selector._domainkey. - Cole o TXT completo ou o destino CNAME exatamente como fornecido.
- Defina o TTL como 3600, salvo se houver outro motivo.
- Aguarde a propagação.
- Verifique com
digounslookupantes de enviar mensagens de produção. - Habilite a assinatura no provedor se houver um botão final de ativação.
Exemplo com TXT:
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."Exemplo com CNAME:
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.A propagação DNS pode ser rápida, mas não é instantânea. O guia do TrekMail informa que muitas atualizações aparecem em cerca de 5 a 15 minutos, embora o prazo varie conforme TTL e caches. Se o status não mudar, confira formatação, duplicatas e nome do host, sem descartar um cache ainda válido.
DKIM e o problema das chaves de 2048 bits
Uma configuração moderna deve usar chaves RSA de 2048 bits quando o provedor e a hospedagem DNS as suportarem. Elas são mais resistentes, mas também maiores, o que pode causar problemas em painéis antigos. Uma chave truncada é enganosa: parece publicada, mas a verificação falha.
O Google recomenda chaves de 2048 bits quando houver suporte, com 1024 bits como alternativa para hosts que não aceitam registros maiores. Na prática, o problema muitas vezes está no painel administrativo, não no DNS em si.
Uma configuração DKIM de 2048 bits com problemas geralmente apresenta um destes casos:
- O painel corta o valor silenciosamente.
- Exige partes entre aspas sem explicar.
- Insere quebras de linha na chave base64.
- Escapa caracteres de uma forma que o provedor não espera.
Se o host DNS exige dividir as strings, publique assim:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"O destinatário concatena as partes entre aspas. Isso é normal. Inserir espaços dentro da chave não é: um caractere a mais pode invalidar a configuração.
Se você gerencia muitos domínios, o custo operacional aparece aqui. Um registrador lida bem com TXT longo; outro não; um terceiro reescreve os valores. Por isso, agências costumam reduzir o conjunto de registradores ou usar assinatura CNAME hospedada pelo provedor quando possível. Para ambientes com vários clientes, hospedagem de e-mail multidomínio apresenta o modelo operacional mais amplo.
Como verificar se DKIM realmente funciona
Um painel mostrando “ativo” não basta. A verificação real consulta o DNS público diretamente, confere o registro retornado e confirma nos cabeçalhos de mensagens reais o domínio signatário e o seletor esperados. Qualquer coisa abaixo disso é uma verificação parcial.
Comece pela linha de comando.
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.comVocê deve ver o registro v=DKIM1 completo ou as partes entre aspas que formam a chave inteira. Se a resposta estiver vazia, confira nesta ordem:
- O seletor está correto.
- O domínio não está duplicado no campo de host.
- O tipo de registro corresponde ao solicitado pelo provedor.
- O valor está completo e não truncado.
- O registro antigo não permanece em cache.
Depois envie um teste ao Gmail ou a outra caixa que permita inspecionar cabeçalhos. Procure os resultados de autenticação e a linha da assinatura DKIM.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...Se o DNS parece correto, mas as mensagens ainda caem no spam, verifique outros fatores. O guia do TrekMail sobre e-mails no spam destaca DNS, aquecimento do domínio, qualidade da lista e conteúdo. DKIM corrige parte da autenticação, mas não cria reputação sozinho.
Considere também o encaminhamento. SPF costuma falhar em mensagens encaminhadas. DKIM pode manter DMARC válido em muitos desses fluxos se a assinatura continuar intacta e alinhada. Se você usa encaminhamento, leia encaminhamento de e-mail para não confundir uma falha SPF causada por encaminhamento com uma falha completa de autenticação.
A armadilha do alinhamento DKIM
É no alinhamento que muitas configurações “funcionais” deixam de atender ao objetivo. A assinatura pode ser válida e não contribuir para DMARC passar se o domínio signatário não estiver alinhado ao From visível. Só em parte dos casos isso é um problema DNS; geralmente é uma configuração do fornecedor.
Falha comum:
From: ceo@example.com
Signatário DKIM:d=sendgrid.net
Resultado: DKIM pode passar, mas o alinhamento DMARC pode falhar porque o domínio signatário não está alinhado aexample.com.
O Google informa que, para remetentes em massa, o domínio From visível deve estar alinhado a SPF ou DKIM no nível do domínio organizacional. Se o provedor assina com seu próprio domínio, a assinatura pode ser válida sem fornecer o alinhamento DKIM necessário.
A correção pode se chamar autenticação de domínio, marca branca ou configuração de return-path personalizado, conforme o fornecedor. Para DKIM, é necessário alinhar o domínio da assinatura; mudar somente o return-path afeta SPF. A assinatura final deve ter este formato:
DKIM-Signature: ... d=example.com; s=s1; ...Essa configuração pode contribuir para DMARC e para a chegada à caixa de entrada. Uma assinatura desalinhada não conclui essa parte do trabalho.
Abordagem antiga e nova para DKIM
A abordagem antiga é manual e frágil: cada domínio, fornecedor, seletor e particularidade DNS é tratado separadamente. A nova é padronizar: escolher um modelo de envio repetível, centralizar verificações DNS e parar de reconstruir a mesma correção para cada domínio.
| Abordagem antiga | Nova abordagem |
|---|---|
| Gerar chaves em ferramentas diferentes e esperar que correspondam ao remetente | Gerar DKIM no sistema de envio real |
| Colar valores TXT um por um e esperar chamados | Usar assinatura gerenciada quando possível e verificar pela CLI |
| Tratar cada domínio como um caso único | Usar um procedimento comum nos domínios de clientes e equipes |
| Investigar spam depois que a campanha falha | Conferir DNS, alinhamento e cabeçalhos antes do primeiro envio de produção |
O TrekMail pode se encaixar nesse modelo. Conforme o plano atual, permite gerenciar vários domínios personalizados em um painel, usar armazenamento compartilhado sem cobrança por caixa postal, migrar caixas por IMAP e escolher BYO SMTP ou SMTP incluído. Os planos pagos descritos começam em $3.50/mês; confira os preços atuais. A plataforma é voltada a equipes, pequenas e médias empresas, agências e MSPs que querem reduzir a administração cotidiana da infraestrutura de e-mail.
Se o problema maior é o processo, não o DNS, leia gestão de e-mail de clientes. Em ambientes multidomínio, responsabilidades indefinidas podem estar por trás das falhas de entregabilidade, além dos registros.
Lista final de configuração DKIM
Uma configuração sólida usa o sistema signatário certo, o nome DNS correto, a chave completa, verificação do DNS público e assinatura alinhada para DMARC. Um erro em qualquer dessas partes enfraquece o conjunto.
- Confirme qual sistema assina o e-mail de saída.
- Publique exatamente o seletor e o tipo de registro do provedor.
- Use
selector._domainkeyno campo de host, salvo se o host DNS exigir o nome completo. - Mantenha intactas as chaves de 2048 bits. Divida strings entre aspas apenas se o painel exigir.
- Verifique com
digounslookup. - Envie um teste e procure
dkim=passe umheader.dalinhado nos cabeçalhos. - Confira os resultados DMARC após entrar em produção.
É isso. Uma boa configuração DKIM não é complicada, mas precisa. Para reduzir dependências, padronize os domínios e o caminho de envio no TrekMail quando fizer sentido para sua operação, mantenha uma visão centralizada do DNS e evite repetir tarefas manuais caras.
