Formatador de Registro TXT DKIM

Formata registros DKIM com aspas apropriadas

DKIM Record Value

Enter a DKIM record to format and validate

O DKIM TXT Record Formatter converte chaves públicas DKIM em registros DNS TXT propriamente formatados que cumprem o limite de string de 255 caracteres. Cole uma chave pública codificada em base64 como uma chave RSA de 2048 bits e obtenha um registro propriamente dividido e pronto para arquivo de zona para um seletor como google._domainkey.example.com.

Entendendo Registros DKIM

DKIM é o mecanismo de autenticação de email que prova que uma mensagem não foi adulterada em trânsito. Quando seu servidor de correio envia um email, ele gera uma assinatura criptográfica sobre os cabeçalhos e corpo da mensagem usando uma chave privada. A chave pública correspondente é publicada em DNS para que servidores receptores possam pesquisá-la e verificar a assinatura. Se a assinatura passar na verificação o receptor sabe que a mensagem foi genuinamente enviada por seu domínio e não foi modificada ao longo do caminho.

O desafio com DKIM não é a criptografia -- seu servidor de correio lida com isso automaticamente. O desafio é colocar a chave pública em DNS corretamente. Uma chave RSA de 2048 bits produz uma string codificada em base64 de aproximadamente 392 caracteres, mas um único string de registro DNS TXT pode manter apenas 255 caracteres. Se você colar a chave diretamente na maioria das interfaces do provedor DNS ela é silenciosamente truncada (quebrando a verificação DKIM) ou o provedor a rejeita com uma mensagem de erro confusa. A chave precisa ser dividida em múltiplos strings entre aspas dentro de um único registro TXT e a divisão deve ser feita corretamente para que resolvedores DNS a remontem.

Este formatador lida com a divisão para você. Você cola sua chave pública, especifica o nome do seletor e tags DKIM opcionais e produz o registro DNS completo no formato correto -- pronto para colar em um arquivo de zona BIND ou na interface web do seu provedor DNS. Isso evita os erros de formatação sutis que causam falhas de validação DKIM notoriamente difíceis de debugar porque os sintomas (emails marcados como spam ou rejeitados) não apontam obviamente para um problema de formatação DNS.

Como Formatar um Registro DKIM TXT

  1. Cole sua chave pública DKIM (normalmente uma chave RSA de 2048 bits em codificação base64)
  2. Digite seu nome de seletor (por exemplo, google, s1, default)
  3. Selecione o tipo de chave -- RSA é padrão Ed25519 é emergente
  4. Configure tags DKIM opcionais como modo de teste (t=y) ou tipo de serviço (s=email)
  5. O formatador divide a chave em strings quoted de 255 caracteres com sintaxe apropriada
  6. Copie o registro formatado para seu arquivo de zona DNS ou interface do provedor

Exemplos de Formato de Registro DKIM

Chave Curta (1024-bit RSA) -- String Única

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK49aE..."

Chave Longa (2048-bit RSA) -- Multi-String Necessário

selector._domainkey.example.com. IN TXT (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2UMfREvlgajdSp3jv1oI"
    "k5LDXFMxqsmSZMTpNEm0MKhDlMlSGbNyERxMnpPQKHlkNPPsFKdXJQsaJFcFP1ab"
    "jCNRQaSwrztEOLGhSV1YlfS0MkIm8v5LqlkFRm0+3kOpE+RSI0E/9IMERJ3v5ggJ"
    "QIDAQAB"
)

Formato de Arquivo de Zona BIND

google._domainkey IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...base64data..."
    "QIDAQAB" )

Referência de Tags de Registro DKIM

TagObrigatórioExemploDescrição
vRecomendadov=DKIM1Identificador de versão
kOpcionalk=rsaTipo de chave (padrão: rsa)
pObrigatóriop=MIIBIj...Chave pública codificada em base64
tOpcionalt=yModo de teste -- verificadores não devem agir em falhas
sOpcionals=emailTipo de serviço (padrão: * para todos)
hOpcionalh=sha256Algoritmos de hash aceitáveis

Quando Usar o Formatador DKIM

  • Configuração de assinatura DKIM para um novo domínio e necessidade de publicar a chave pública em DNS
  • Rotação de chaves DKIM de RSA de 1024-bit para 2048-bit para segurança melhorada
  • Adição de novos seletores para diferentes fluxos de email (marketing, transacional, corporativo)
  • Migração de provedores DNS e necessidade de re-digitar registros DKIM em um formato de interface diferente
  • Solução de problemas de falhas DKIM causadas por formatação imprópria de registro TXT ou truncamento
  • Implantação de múltiplas chaves de assinatura quando diferentes serviços (Google, SendGrid, Postmark) cada um requer seu próprio seletor

Como Registros DNS DKIM Funcionam

Estrutura de Seletor e Domínio

As chaves públicas DKIM são publicadas em um local DNS específico seguindo o padrão:

<selector>._domainkey.<domain>

Por exemplo, se seu seletor é google e seu domínio é example.com o registro fica em google._domainkey.example.com. O seletor permite múltiplas chaves DKIM por domínio -- uma para cada fonte de assinatura.

O Limite de String de 255 Caracteres

Registros DNS TXT armazenam dados em strings individuais de até 255 caracteres. Uma chave pública RSA de 2048 bits em codificação base64 é aproximadamente 392 caracteres para os dados de chave sozinhos mais as tags DKIM. O registro total facilmente excede 255 caracteres requerendo o valor ser dividido em múltiplos strings quoted.

Resolvedores DNS automaticamente concatenam múltiplos strings em um registro TXT em um valor único. Os pontos de divisão podem ocorrer em qualquer lugar nos dados -- até no meio de uma palavra -- porque a concatenação é em nível byte não semântico.

Considerações de Tamanho de Chave

Tamanho de ChaveComprimento de Chave Base64Precisa Multi-String?
1024-bit RSA~216 caracteresGeralmente não
2048-bit RSA~392 caracteresSim
4096-bit RSA~736 caracteresSim, múltiplas divisões
Ed25519~44 caracteresNão

2048-bit RSA é o padrão da indústria atual. Chaves mais curtas que 1024 bits são consideradas inseguras e podem ser rejeitadas por receptores. Chaves Ed25519 são muito mais curtas mas ainda não universalmente suportadas.

Gerenciamento de Chave DKIM na Prática

O erro mais comum de implantação DKIM é publicar a chave incorretamente e não verificá-la. Depois de adicionar o registro TXT ao DNS sempre confirme consultando o registro com uma ferramenta como dig ou nslookup e comparando o valor retornado contra a chave pública original. A propagação DNS pode levar minutos a horas dependendo de suas configurações TTL então espere apropriadamente antes de testar. Uma forma rápida de verificar é dig TXT selector._domainkey.example.com e verificar que a chave base64 completa aparece na resposta sem truncamento.

A rotação de chave é outra área onde administradores frequentemente tropeçam. A melhor prática é gerar um novo par de chaves com um novo seletor publicar a nova chave pública em DNS esperar por propagação mudar seu servidor de correio para assinar com a nova chave privada e apenas então remover a chave pública antiga de DNS. Se você remover a chave antiga antes que todas as mensagens em trânsito tenham sido entregues e verificadas essas mensagens falharão nas verificações DKIM. Uma boa abordagem é manter a chave antiga publicada por pelo menos uma semana após mudar seletores dando tempo às mensagens em cache serem entregues.

Ao configurar DKIM pela primeira vez use o sinalizador de teste t=y inicialmente. Isso informa aos servidores receptores que seu domínio está em modo de teste DKIM e que não devem agir em falhas de verificação. Uma vez que você tenha confirmado que a assinatura está funcionando corretamente verificando relatórios agregados DMARC remova o sinalizador t=y para ativar imposição completa. Deixar t=y permanentemente em coloca prejudica o valor de segurança de DKIM já que receptores ignorarão falhas.

Perguntas Frequentes

Por que meu registro DKIM falha na validação após colar em DNS?

A causa mais comum é divisão de string imprópria. Se seu provedor DNS não suporta registros TXT multi-string ou trunca valores longos os dados de chave pública estão incompletos e a verificação DKIM falhará. Use este formatador para garantir divisão correta então verifique o registro publicado correspondendo ao valor esperado usando dig TXT selector._domainkey.yourdomain.com.

Posso ter múltiplos registros DKIM para um domínio?

Sim. Diferentemente de SPF DKIM suporta múltiplas chaves através de diferentes seletores. Cada sistema de email (Google Workspace, SendGrid, Mailchimp) usa seu próprio seletor então suas chaves não conflitam. Por exemplo google._domainkey.example.com e sendgrid._domainkey.example.com coexistem sem problemas.

O que t=y (modo de teste) faz?

Quando t=y é definido servidores de correio receptores devem tratar falhas de verificação DKIM como se o domínio não estivesse assinado. Isso permite publicar uma chave DKIM e começar a assinar emails sem risco de falhas de entrega enquanto você verifica a configuração está correta. Remova t=y uma vez que o teste esteja completo para ativar imposição DKIM completa.

Devo usar chaves RSA de 2048-bit ou 4096-bit?

RSA de 2048 bits é o padrão atual e é aceito por todos os principais provedores de email. Enquanto chaves de 4096 bits fornecessem segurança mais forte elas produzem registros TXT muito longos que alguns provedores DNS têm dificuldade em lidar e aumentam o tamanho dos cabeçalhos de assinatura DKIM em cada email. A melhoria de segurança sobre 2048 bits é marginal para propósitos de autenticação de email. Use 2048 bits a menos que sua política de segurança especificamente requeira chaves mais longas.

O que é Ed25519 e devo usá-lo?

Ed25519 é um algoritmo de curva elíptica que produz chaves e assinaturas muito mais curtas (~44 caracteres) que RSA tornando registros DNS e cabeçalhos de email menores. Porém o suporte DKIM de Ed25519 ainda não é universal entre servidores de correio receptores. Se você adotar Ed25519 publique tanto uma chave Ed25519 quanto uma chave RSA de 2048 bits sob diferentes seletores e assine com ambos. Receptores que suportam Ed25519 a usarão; outros voltarão ao RSA.

Ferramentas Relacionadas

IPparse•Ferramentas Gratuitas de Rede e Calculadora de Sub-redes

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected