A rotação de chaves DKIM significa substituir o par de chaves que assina os seus e-mails, de acordo com um cronograma ou após uma preocupação de segurança, sem quebrar a autenticação. Parece arriscado porque um movimento errado faz e-mails legítimos falharem, mas o design do DKIM torna o processo simples: os seletores permitem publicar uma nova chave ao lado da antiga, trocar a assinatura e aposentar a chave antiga depois. Este guia explica como isso funciona e traz um passo a passo.
Como funcionam a assinatura DKIM e os seletores
Quando a sua plataforma envia uma mensagem, ela cria uma assinatura usando uma chave privada e a adiciona aos cabeçalhos. A assinatura indica o domínio de assinatura, escrito d=, e um seletor, escrito s=. Um receptor monta um nome DNS a partir deles, seletor._domainkey.dominio, busca a chave pública publicada ali e confere a assinatura. Se a chave corresponder e as partes assinadas da mensagem não tiverem sido alteradas, o DKIM passa.
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=2026a;
h=from:to:subject:date:message-id; bh=...; b=...Neste exemplo o seletor é 2026a, então o receptor consulta 2026a._domainkey.mail.example.com. Como o seletor é apenas um rótulo que você escolhe, você pode publicar vários ao mesmo tempo. Esse é todo o segredo da rotação: o seletor antigo continua verificando os e-mails antigos enquanto o novo seletor assina os e-mails novos.
Por que rotacionar
- Limite a exposição. Uma chave privada que existe há anos foi vista por mais sistemas e pessoas. A rotação limita o valor de qualquer vazamento passado.
- Responda a mudanças de equipe. Se um administrador que tinha acesso à chave sai, substituí-la elimina um risco residual.
- Migre para chaves mais fortes. Muitos domínios mais antigos ainda publicam chaves de 1024 bits. A rotação é o momento natural para fazer o upgrade.
- Atenda a políticas. Revisões de segurança e alguns questionários de clientes perguntam com que frequência as chaves mudam.
- Mantenha o processo treinado. Uma equipe que rotaciona duas vezes por ano lida com uma rotação de emergência com tranquilidade.
A rotação não é uma ferramenta de entregabilidade. Trocar chaves não melhora a caixa de entrada por si só. Seu objetivo é segurança e higiene. Faça-a com cuidado para não prejudicar a entrega e não espere um ganho de reputação.
Como escolher o tamanho da chave
O padrão DKIM define 1024 bits como o mínimo para assinantes e recomenda 2048 bits. Os verificadores não são obrigados a aceitar nada menor que 1024 bits. Para a maioria dos remetentes, a escolha sensata hoje é RSA de 2048 bits, que oferece uma margem confortável sem grande custo de desempenho.
| Tamanho da chave | Posição | Observação prática |
|---|---|---|
| 512 bits | Inaceitável | Considerada quebrada e rejeitada pelos receptores modernos |
| 1024 bits | Mínimo permitido, ainda comum | Funciona, mas faça o upgrade na próxima rotação |
| 2048 bits | Recomendado | Exige um valor TXT dividido em várias strings ou um CNAME |
| 4096 bits | Permitido pelo padrão | Raramente necessário, e o registro pode exceder os limites práticos de tamanho do DNS |
O limite de 255 caracteres
Uma única string em um registro TXT pode conter no máximo 255 caracteres, e uma chave pública de 2048 bits é mais longa que isso. Por isso o registro contém várias strings entre aspas, que o receptor une. A maioria dos provedores de DNS cuida disso quando você cola um valor longo. Se o seu não faz isso, divida manualmente ou peça à sua plataforma de envio uma opção de CNAME.
2026a._domainkey.mail.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...rest of the public key..." )Antes de começar: dois modelos de gerenciamento de chaves
| Modelo | Como funciona | O que você faz para rotacionar |
|---|---|---|
| Gerenciado pela plataforma (CNAME) | Você publica um CNAME do seu seletor para um nome controlado pela plataforma, e a plataforma troca a chave por trás dele | Pouco ou nada; confirme o cronograma e que o CNAME continua no lugar |
| Gerenciado pelo cliente (TXT) | Você publica a chave pública por conta própria, e a plataforma assina com a chave privada que você forneceu ou que ela gerou | Siga o plano completo abaixo |
| Assinatura própria (self-hosted) | Seu próprio servidor de e-mail assina, e você mantém a chave privada | Gere as chaves, atualize a configuração do servidor e o DNS |
Um plano seguro de rotação
- Faça o inventário dos seletores. Liste todos os seletores publicados em _domainkey para o domínio e identifique qual sistema usa cada um. Seletores desconhecidos já são uma descoberta por si só; não os apague até saber o que assina com eles.
- Escolha um esquema de nomes. Use seletores que incluam uma data ou sequência, como 2026a e 2027a, para distinguir as chaves rapidamente.
- Gere a nova chave. Crie um par de chaves de 2048 bits ou peça à sua plataforma que emita um. Guarde a chave privada apenas onde o sistema de assinatura precisar dela.
- Publique a nova chave pública. Adicione o registro do novo seletor. Não mexa no antigo. Confirme que ele resolve a partir de fora da sua rede.
- Teste antes de trocar. Assine uma mensagem de teste com o novo seletor e confirme que o DKIM passa nos cabeçalhos recebidos.
- Troque a assinatura. Altere a configuração de assinatura para usar o novo seletor em todas as novas mensagens. A partir desse momento, a chave antiga não assina mais nada novo.
- Monitore. Acompanhe os relatórios agregados do DMARC e os dados de bounce em busca de um aumento nas falhas de DKIM nos dias seguintes.
- Aguarde as mensagens retardatárias. Mantenha o registro antigo publicado por pelo menos vários dias. Mensagens em fila, retentadas ou encaminhadas são verificadas quando processadas, não quando enviadas.
- Aposente a chave antiga. Remova o registro do seletor antigo e apague a chave privada antiga de todos os sistemas que a possuíam.
- Registre a rotação. Anote a data, o novo seletor e a data da próxima rotação no seu runbook.
Por quanto tempo manter a chave antiga
A chave pública antiga deve permanecer no DNS até que nenhuma mensagem assinada com ela possa ainda estar em trânsito ou aguardando verificação. Para e-mails transacionais e de marketing comuns, alguns dias bastam. Se você envia por listas de discussão ou serviços de encaminhamento que seguram mensagens, ou se o seu cronograma de novas tentativas é longo, espere mais. Manter uma chave antiga publicada por um pouco mais de tempo não custa nada. Removê-la cedo demais causa falhas difíceis de diagnosticar.
O que pode dar errado e como perceber
| Problema | Sinal | Correção |
|---|---|---|
| Seletor incorreto | O DKIM falha com chave não encontrada | Compare o valor s= da assinatura com o nome DNS |
| Chave pública truncada | O DKIM falha com chave inválida ou incompatibilidade de assinatura | Cole a chave novamente e verifique se todas as partes da string estão presentes |
| Chave antiga removida cedo demais | Falhas apenas em mensagens atrasadas | Restaure o registro antigo e espere mais da próxima vez |
| Assinatura não trocada | O novo seletor nunca aparece nos cabeçalhos | Verifique a configuração de assinatura e eventuais configurações em cache |
| Dois sistemas compartilham um seletor | Falhas intermitentes depois que um sistema rotaciona | Dê a cada sistema o seu próprio seletor |
| CNAME removido durante a limpeza | O DKIM de repente falha em tudo para uma chave gerenciada pela plataforma | Restaure o CNAME exatamente como fornecido |
Use os relatórios para confirmar o sucesso
Os relatórios agregados do DMARC mostram, por fonte de envio, quantas mensagens passaram ou falharam no DKIM e no SPF. Consulte-os nos dias seguintes à rotação. Uma rotação limpa mostra o novo seletor aparecendo e o número de falhas permanecendo estável. Se as falhas aumentarem em uma fonte, ela provavelmente ainda assina com uma chave que não está mais publicada. Nosso guia sobre relatórios agregados do DMARC explica como lê-los.
Rotação de emergência
Se você suspeitar que uma chave privada foi exposta, rotacione imediatamente e encurte a sobreposição. Publique e troque para uma nova chave o mais rápido que puder com segurança, depois remova a chave comprometida mesmo que algumas mensagens atrasadas possam falhar. Um atacante com a chave privada antiga poderia assinar e-mails forjados que passam no DKIM para o seu domínio enquanto a chave pública continuar publicada, então a janela de exposição importa mais do que a perda de algumas mensagens atrasadas. Um DMARC aplicado e uma política de reject limitam o que essas falsificações podem fazer, mas a chave ainda deve ser aposentada rapidamente.
Faça da rotação uma rotina
- Coloque a data da rotação em um calendário compartilhado, com um responsável nomeado.
- Mantenha uma tabela de seletores, dos sistemas que os usam e de suas datas de criação.
- Use um seletor dedicado para cada sistema de envio.
- Crie alertas para as taxas de falha de DKIM, para que uma rotação malfeita seja percebida em horas.
- Pratique primeiro em um subdomínio de baixo risco se o processo for novo para a sua equipe.
Precisa de ajuda para planejar uma rotação? Conte-nos quais domínios e sistemas de envio você usa, e sugeriremos uma ordem segura.
Leitura complementar e fontes
Perguntas frequentes
O que é um seletor DKIM?
Um seletor é um rótulo que informa aos receptores qual chave pública buscar. A assinatura indica um seletor e um domínio, e o receptor consulta um registro DNS em seletor._domainkey.dominio. Como o seletor faz parte do nome, um mesmo domínio pode publicar várias chaves ao mesmo tempo, e é isso que torna a rotação segura.
Com que frequência devo rotacionar as chaves DKIM?
Não existe um intervalo único exigido. Muitas organizações rotacionam uma ou duas vezes por ano, ou sempre que alguém com acesso à chave privada deixa a empresa ou há suspeita de comprometimento. Escolha um cronograma que você realmente vá seguir e rotacione antes se suspeitar que uma chave foi exposta.
Qual tamanho de chave DKIM devo usar?
Use RSA de 2048 bits quando o seu provedor de DNS e o sistema de envio oferecerem suporte. O padrão DKIM exige que os assinantes usem pelo menos 1024 bits e recomenda 2048, e os verificadores não devem aceitar chaves menores que 1024. Chaves mais longas dão mais margem à medida que o poder de computação cresce.
Por que meu provedor de DNS rejeita a chave de 2048 bits?
Uma chave pública de 2048 bits tem mais de 255 caracteres, que é o limite para uma única string em um registro TXT. Ela precisa ser dividida em várias strings entre aspas, que o receptor une. Muitos provedores fazem essa divisão automaticamente; se o seu não faz, divida manualmente ou use um CNAME para o registro hospedado pela plataforma.
Posso apagar a chave antiga logo após a troca?
Não com segurança. As mensagens podem ficar atrasadas em filas ou ser retentadas por dias, e os receptores verificam a assinatura quando processam a mensagem. Mantenha o registro antigo publicado por pelo menos vários dias, e por mais tempo se você enviar por caminhos de encaminhamento lentos.
O que acontece se eu remover uma chave que ainda está em uso?
As mensagens assinadas com esse seletor falham na verificação DKIM. Se o SPF estiver alinhado, o DMARC ainda pode passar, mas se o SPF não estiver alinhado a mensagem pode ser colocada em quarentena ou rejeitada sob uma política DMARC aplicada. Por isso a assinatura é trocada primeiro e a chave antiga é removida depois.
Minha plataforma de envio rotaciona as chaves para mim?
Algumas plataformas gerenciam as chaves DKIM e as publicam por meio de um CNAME que você aponta uma única vez, de modo que a rotação acontece do lado delas. Outras fornecem um registro estático que você precisa substituir. Verifique qual modelo a sua plataforma usa antes de planejar uma rotação.
Fluxos de e-mail diferentes devem usar seletores diferentes?
Sim, é uma boa prática. Seletores separados para sistemas transacionais, de marketing e internos facilitam rotacionar ou revogar um sem afetar os outros, e tornam a análise de cabeçalhos mais clara.
Posso testar uma chave antes de passar a usá-la?
Sim. Publique primeiro o novo registro, confirme que ele resolve, depois envie mensagens de teste assinadas com o novo seletor para uma caixa de entrada que você controla e verifique nos cabeçalhos se o DKIM passa antes de trocar todo o tráfego.