Como configurar DKIM: selector, chave e os dois erros comuns

O DKIM assina cada mensagem enviada com uma chave criptográfica privada, que fica no servidor de envio. Quem recebe busca a chave pública correspondente no DNS do seu domínio e confere a assinatura. Se bater, é prova de duas coisas: a mensagem saiu mesmo de quem diz ter saído, e o conteúdo não foi alterado no caminho.

É a peça mais robusta das três — e a única que sobrevive ao encaminhamento, onde o SPF quebra por natureza.

Como funciona, em uma passada

1. O servidor gera um par de chaves: uma privada e uma pública.
2. A privada fica guardada no servidor de envio e nunca sai de lá.
3. A pública é publicada no DNS, em um nome com o formato selector._domainkey.seudominio.com.br.
4. A cada envio, o servidor calcula uma assinatura dos cabeçalhos e do corpo e a coloca no cabeçalho DKIM-Signature.
5. Quem recebe lê o s= desse cabeçalho para saber qual selector usar, busca a chave pública no seu DNS e confere.

O que é o selector

O selector é apenas um nome que identifica qual chave usar. Ele existe para permitir mais de uma chave no mesmo domínio — uma para cada serviço que envia em seu nome, e uma nova quando você quiser trocar a antiga sem interromper nada.

Cada provedor escolhe o próprio padrão: o Microsoft 365 usa selector1 e selector2; o Google Workspace usa uma data, como 20230601; muitos servidores próprios usam default ou mail.

Não existe forma de listar os selectors de um domínio pelo DNS. Isso surpreende quem está começando: você só descobre o selector olhando o cabeçalho de uma mensagem já enviada. É por isso que a busca automática do validador de DKIM testa nomes conhecidos e avisa que não encontrar não prova ausência.

Como descobrir o seu selector

1. Envie uma mensagem do seu domínio para uma conta do Gmail.
2. Abra a mensagem, clique nos três pontos e escolha Mostrar original.
3. Procure a linha que começa com DKIM-Signature.
4. Dentro dela existe um trecho s=algumacoisa — esse é o selector.

Publicando a chave

Você não gera a chave à mão: o servidor ou o provedor faz isso e entrega a parte pública para você publicar. O registro é um TXT, e fica mais ou menos assim:

Nome:  selector1._domainkey
Tipo:  TXT
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Etiqueta	Significado
v=DKIM1	Versão. Quando presente, precisa vir primeiro.
k=rsa	Tipo da chave. RSA é o padrão; Ed25519 existe mas é raro.
p=…	A chave pública em base64. É a parte longa.
t=y	Modo de teste — trate como se não estivesse assinada.
h=sha256	Algoritmo de hash aceito.

Os dois problemas que mais aparecem

A chave quebrada na publicação

Uma chave RSA de 2048 bits gera um valor com mais de 380 caracteres. Um registro TXT no DNS comporta no máximo 255 caracteres por string, então o valor precisa ser dividido em pedaços — e é aí que muita coisa dá errado.

Painéis de DNS antigos cortam o valor, inserem espaços ou quebras de linha no meio da chave, ou simplesmente truncam. O resultado é um registro que existe, parece certo à primeira vista, e não valida nada.

O validador de DKIM deste site não estima o tamanho pelo comprimento do texto: ele decodifica a chave de verdade com o OpenSSL e informa o número real de bits. Chave quebrada aparece como inválida — que é exatamente o que você precisa saber.

O p= vazio

Um p= sem nada depois não é erro de digitação: é a forma prevista na RFC de revogar um selector. Nenhuma mensagem assinada com ele será validada. Se você não fez isso de propósito, a chave pública precisa ser republicada.

Tamanho da chave

Use 2048 bits. Chaves de 1024 ainda são aceitas pela maioria dos provedores, mas já são consideradas fracas e a tendência é serem recusadas. Abaixo de 1024, a chave é rejeitada.

Se o seu painel de DNS não aceitar o valor de uma chave de 2048 bits, o caminho é pedir ao provedor que ele publique o registro dividido corretamente — não gerar uma chave menor.

Trocando a chave sem interromper o envio

É aqui que o selector mostra o valor dele. A troca segura tem quatro passos:

1. Gere um novo par de chaves com um selector diferente (por exemplo, s2).
2. Publique a nova chave pública, mantendo a antiga no ar.
3. Configure o servidor para assinar com o novo selector.
4. Espere alguns dias — o tempo de as mensagens antigas terminarem de circular — e só então remova a chave antiga.

Conferindo

Depois de publicar, aguarde o TTL antigo expirar e teste no validador de DKIM, informando o domínio e o selector. Confira três coisas: o registro é encontrado, a chave é lida como válida e tem 2048 bits.

Com SPF e DKIM publicados, o passo seguinte é o DMARC, que amarra os dois e diz ao destinatário o que fazer quando falham.