Entregabilidade e DNS

Chave DKIM: tamanho recomendado, publicação e rotação

Por Alexey Bulygin
Chave pública DKIM dividida em strings TXT e rotação por seletor

Sua chave DKIM é um elemento de autenticação publicado no DNS cujo estado pode afetar a entrega. Se estiver fraca, malformada ou desatualizada, os destinatários podem deixar de validar as assinaturas. Isso importa especialmente pelos requisitos do Gmail introduzidos em fevereiro de 2024 e pelo reforço anunciado a partir de novembro de 2025; confira as condições atuais. Se você ainda está revisando o DNS básico, comece por e-mail empresarial e depois volte aqui.

Em resumo: use uma chave DKIM RSA de 2048 bits quando houver suporte. Publique corretamente no DNS, o que costuma exigir dividir o TXT em várias strings entre aspas. Faça rotações programadas com seletores. Em uma rotação normal, mantenha o seletor anterior por alguns dias após a mudança para as mensagens em trânsito. É um processo prudente, não uma garantia de entrega.

Para um domínio novo, consulte também criar e-mail com seu domínio e os registros DNS necessários do TrekMail para preparar DKIM, SPF e DMARC juntos.

O que é uma chave DKIM?

Aqui, o termo se refere à parte pública da configuração de assinatura DKIM. O servidor assina mensagens de saída com a chave privada; o destinatário busca a pública no DNS para verificar os dados assinados e a responsabilidade do domínio signatário. Isso não comprova sozinho a identidade pessoal nem a confiabilidade do From visível.

DKIM significa DomainKeys Identified Mail. A chave privada fica no sistema de envio e a pública é publicada em um seletor, normalmente em um nome como s1._domainkey.example.com.

Ao receber a mensagem, o servidor examina a assinatura DKIM, busca a chave pública no DNS e a valida. Quando passa, obtém duas indicações:

  • O corpo e os cabeçalhos assinados mantêm sua integridade conforme as regras de canonicalização da assinatura.
  • A assinatura foi gerada com acesso à chave privada correspondente ao domínio e seletor.

Isso não garante chegada à caixa de entrada. Oferece um sinal criptográfico verificável que os filtros podem considerar.

Qual tamanho de chave DKIM usar?

Use RSA de 2048 bits como recomendação para DKIM em 2025 e 2026. O mínimo do padrão ainda permite RSA de 1024 bits, mas a recomendação prática é 2048 bits: maior resistência com menos dificuldades de tamanho DNS e compatibilidade que podem acompanhar chaves de 4096 bits.

O RFC 8301 exige pelo menos 1024 bits em chaves RSA e recomenda pelo menos 2048 bits. Essa recomendação técnica é importante para a operação.

Tamanho DKIMStatusImplicações em produção
512 bitsInválidaDestinatários não devem validá-la. Substitua.
1024 bitsMínimo legadoPermitida pelo padrão, mas não é a escolha recomendada em novas configurações.
2048 bitsEscolha recomendadaBom equilíbrio entre resistência e compatibilidade, sem garantia de entregabilidade.
4096 bitsMuitas vezes desnecessáriaMaior carga DNS e possíveis dificuldades, com benefício operacional a avaliar.

Se você herdou uma infraestrutura antiga, não presuma que a chave esteja adequada. Muitos painéis e sistemas geravam chaves de 1024 bits por padrão. Embora fosse comum antes, essa decisão merece revisão.

A documentação do Google mostra a importância operacional. Gmail exige DKIM para remetentes em massa e sua FAQ descreve possíveis limitações quando a autenticação falha. Veja as perguntas frequentes sobre as diretrizes do Google para remetentes.

Por que uma chave DKIM de 2048 bits pode falhar no DNS

Uma chave DKIM de 2048 bits pode causar problemas porque cada string TXT DNS tem um limite de 255 octetos por trecho entre aspas. A chave pública completa excede esse tamanho. Se o painel espera um único valor longo, pode rejeitar, truncar ou armazenar incorretamente.

É uma armadilha comum: o problema geralmente está na interface DNS, não na criptografia.

O valor público de p= em uma chave RSA DKIM de 2048 bits pode precisar de várias strings entre aspas dentro de um único TXT. O verificador DKIM ou a aplicação que usa o registro concatena as strings; não presuma que o resolvedor DNS faça isso automaticamente. Dados publicados incorretamente podem causar falha na validação.

Falhas comuns:

  • O painel corta o registro em 255 caracteres de um byte.
  • Acrescenta espaços ou quebras de linha na chave.
  • Você publica vários TXTs separados, em vez de um TXT com várias strings entre aspas.
  • Remove parte do prefixo v=DKIM1; k=rsa; p= ao tentar encurtar.

Você não obtém uma chave mais fraca, mas uma chave que pode não ser verificável.

Como publicar corretamente uma chave DKIM de 2048 bits

Publique um TXT por seletor e divida o valor apenas em strings dentro desse registro. O verificador destinatário concatena as strings. Mantenha a sintaxe válida e depois confira a resposta DNS exata pela linha de comando.

Sintaxe de arquivo de zona:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Muitas interfaces web pedem o mesmo registro em uma linha:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Depois verifique externamente. Não confie apenas na prévia do painel.

dig txt s1._domainkey.example.com +short

Procure uma resposta TXT completa. Duas strings entre aspas são normais se pertencem ao mesmo registro. Trechos ausentes, escapes inesperados ou saída parcial exigem investigar tanto o registro publicado quanto a ferramenta de consulta.

No TrekMail, consulte SMTP gerenciado do TrekMail e o assistente DNS. Conforme o plano atual, você pode usar SMTP gerenciado e obter no painel o valor do registro DKIM do domínio. A oferta descrita apresenta Starter por $3.50 ao mês e teste gratuito de 14 dias com cartão nos planos pagos. Nano é apresentado como gratuito e usa SMTP externo; suas chaves e seletores vêm do provedor signatário. Confira as condições atuais.

Exemplo conceitual: você gera uma chave DKIM de 2048 bits, cola em um registrador que trunca TXT longo silenciosamente e as mensagens continuam saindo do servidor. O problema pode ficar invisível até Gmail identificar autenticação inválida. Por isso é importante verificar externamente.

Como rotacionar uma chave DKIM reduzindo interrupções

Em uma rotação normal, adicione um seletor, publique a nova chave, mude a assinatura e mantenha o antigo temporariamente. Evite sobrescrever a chave ativa. Seletores diferentes reduzem falhas em mensagens atrasadas ou reenviadas pela fila. Se houver possível vazamento, revogar imediatamente pode ser mais importante que a transição.

Procedimento prudente para rotação programada:

  1. Gere um novo par DKIM de 2048 bits.
  2. Atribua um seletor novo, como s2.
  3. Publique s2._domainkey.example.com no DNS.
  4. Mude a configuração de assinatura para s2.
  5. Mantenha s1 publicado por vários dias, conforme suas filas e políticas.
  6. Remova s1 quando as mensagens antigas assinadas não estiverem mais em trânsito.

Um exemplo de margem é 7 dias. Pode cobrir atrasos, novas tentativas e caches comuns, mas não é um prazo universal: ajuste ao ambiente e ao motivo da rotação.

Não substitua a chave no mesmo seletor sem controlar todos os casos de assinatura e entrega, ou sem uma exigência do provedor. A maioria das equipes não tem controle completo. Use os seletores para distinguir chaves.

Com vários sistemas de envio, documente a qual sistema pertence cada seletor. Isso importa ao investigar falhas em CRM, suporte, aplicativo web e provedor de caixas usando o mesmo domínio.

Quando rotacionar uma chave DKIM?

Siga uma política fixa e faça rotação também depois de exposição da chave privada, troca de fornecedor ou migração de envio. Uma frequência semestral pode ser um ponto de partida para algumas equipes. Ambientes de alto risco podem exigir outro ritmo; uma política previsível geralmente é melhor que mudanças improvisadas.

Regra operacional: se a chave privada pode ter vazado, substitua e considere revogar imediatamente. Sem incidentes, aplique a política de rotação mesmo assim.

Motivos para antecipar a rotação:

  • Você mudou o provedor de envio.
  • Desativou um fornecedor com acesso de assinatura.
  • Exportou chaves em um processo inseguro.
  • Encontrou uma conta administrativa compartilhada antiga cujo uso ninguém explica.

Argumentos que não justificam adiar:

  • “Faremos quando houver tempo.”
  • “A chave ainda passa, então está tudo bem.”
  • “Não lembramos onde fica a chave privada.”

Com muitos domínios de clientes, isso vira operação, não só criptografia. É onde hospedagem de e-mail multidomínio ganha importância. Um domínio pode ser manual; cinquenta exigem processo.

Vale usar Ed25519 para DKIM?

Ed25519 oferece chaves bem menores e reduz os problemas de comprimento TXT associados a RSA-2048. A contrapartida é a compatibilidade. O RFC 8463 padronizou seu uso em DKIM, mas RSA-2048 geralmente é a escolha conservadora para interoperabilidade ampla.

A principal vantagem é o tamanho. Uma chave pública Ed25519 é pequena comparada a RSA, o que costuma simplificar a publicação.

A desvantagem é a variação de suporte. Alguns destinatários e ferramentas lidam bem; outros podem não suportar. RSA-2048 também exige verificação, embora seja amplamente usado. Se a plataforma aceita assinatura dupla e você conhece o caminho, testar Ed25519 junto com RSA pode fazer sentido.

Para a maioria dos operadores:

  • Use RSA-2048 como padrão.
  • Considere Ed25519 quando conhecer a compatibilidade dos destinatários e puder testar.
  • Não mude para Ed25519 exclusivo só porque o DNS fica mais curto.

Abordagem antiga e nova: gerenciar DKIM em escala

A abordagem antiga edita TXT manualmente, cola chaves grandes em diferentes painéis e espera que ninguém esqueça a rotação. A nova usa gestão repetível e, quando adequado, delegada de DNS e assinatura: o ciclo de vida das chaves passa a fazer parte do processo de e-mail.

Abordagem antiga:

  • Cada domínio tem uma interface DNS diferente.
  • Cada rotação depende de um lembrete que pode ser ignorado.
  • Um erro em um registrador pode afetar um cliente sem ser percebido até surgirem problemas de entrega.

Nova abordagem:

  • Um processo comum para muitos domínios.
  • Assinatura gerenciada com configuração consistente.
  • Menos trabalho repetitivo com TXT longo e mudanças na autenticação.

O TrekMail pode se encaixar nesse modelo de hospedagem multidomínio com tarifa fixa em vez de cobrança por usuário. A oferta descrita inclui armazenamento compartilhado, caixas IMAP, migração IMAP integrada, catch-all, encaminhamento, BYO SMTP no Nano e SMTP gerenciado nos planos pagos; confira os recursos atuais. Se você gerencia encaminhamentos, examine também a autenticação desses caminhos: encaminhar e-mail de domínio para Gmail apresenta um caso relacionado.

Para equipes e agências, o benefício potencial não é DNS “mágico”, mas menos erros repetitivos com um processo centralizado. A oferta descrita do Starter começa em $3.50/mês; consulte os preços atuais.

Conclusão sobre a chave DKIM

Como regra geral, escolha RSA-2048, publique corretamente, verifique com consultas reais e programe rotação por seletor. Se ainda usa 1024 bits, planeje uma atualização compatível. Se o painel altera TXT longo, corrija o formato ou escolha um sistema que o gerencie adequadamente.

Não considere DKIM isoladamente. Uma chave verificável ajuda mais quando SPF, DMARC e a infraestrutura de envio também estão configurados e alinhados. Consulte registros DNS necessários do TrekMail e criar e-mail com seu domínio para revisar o conjunto.

Compartilhar este artigo

Usamos tecnologias necessárias para operar e proteger o TrekMail. Ao confirmar, você também permite análises limitadas e medição de publicidade descritas em nossa Política de Cookies.

Entrar no TrekMail

Acesse seu painel, caixas de correio e DNS.

ou

12 caracteres as senhas coincidem

ou

E-mail de redefinição enviado

Se existir uma conta com este e-mail, enviamos as instruções para redefinir a senha.

Ao continuar, você concorda com os Termos e a Política de Privacidade do TrekMail.