Rotação de chaves DKIM: runbook operacional (D-7 a D+30)

A rotação de chaves DKIM é uma operação recorrente, mas frequentemente subestimada. Os guias dos fornecedores (Microsoft, AWS, SendGrid) descrevem o botão "rotate" sem explicar a janela de sobreposição, o atraso de propagação DNS nem o procedimento de rollback. Este runbook colmata essa lacuna com um cronograma calendarizado D-7 a D+30, scripts openssl testados e as armadilhas reportadas no terreno.

Para a referência geral, consulte o guia completo DKIM. Aqui, o objetivo é operacional: gerar o par, publicar o seletor DKIM, comutar a assinatura, monitorizar o DMARC, retirar o seletor antigo. Público-alvo: administradores de sistemas, DevOps, SRE e equipas de infraestrutura em produção.

Porquê rodar as chaves DKIM?

Três razões operacionais justificam a rotação periódica.

Comprometimento da chave. Uma chave privada DKIM acaba sempre por escapar: backup não cifrado, acesso KMS legacy de um ex-colaborador, fuga de um fornecedor SaaS. A rotação limita a janela de exploração de uma fuga.

Limite criptográfico. A RFC 8301 declarou obsoletas as chaves RSA abaixo de 1024 bits já em 2018 e recomenda RSA 2048 como mínimo. Uma chave RSA 1024 publicada em 2018 é hoje rejeitada pela Google, Yahoo e Microsoft. Rodar regularmente força a substituição dos algoritmos herdados.

Higiene criptográfica. A NIST SP 800-57 Part 1 Rev. 5 recomenda criptoperíodos curtos para as chaves de assinatura: 1 a 2 anos no máximo, mais curtos para os ambientes sensíveis. Sem rotação regular, a primeira rotação forçada transforma-se num pesadelo.

DKIM2, em curso de normalização no IETF, acrescenta uma proteção contra o replay mas não elimina a necessidade de rotação. Ver DKIM2 e a proteção contra o replay.

Estratégia de rotação de chaves DKIM: seletores paralelos em vez de substituição direta

Princípio fundamental da rotação de chaves DKIM: nunca substituir uma chave DKIM por overwrite. Publicar sempre um novo seletor DKIM em paralelo, comutar a assinatura e depois retirar o seletor antigo após um período de tolerância.

Três fatores impõem a coexistência temporária:

• Cache do resolver DNS. O valor TXT de um seletor é colocado em cache durante o TTL (1 a 24 horas). Alguns resolvers ainda servem o valor antigo.
• Retry SMTP. Um MTA destinatário mantém uma mensagem em fila até 5 dias. Se o seletor for retirado demasiado cedo, a reverificação falha.
• Auditoria forense. As equipas de segurança têm de verificar a assinatura de uma mensagem recebida duas semanas antes. Um seletor retirado torna essa verificação impossível.

Convenção de nomenclatura: seletores datados trimestrais. Exemplo: s2026-q1 para janeiro a março de 2026, s2026-q2 para o seguinte. Esta convenção evita colisões com os seletores dos fornecedores (selector1 Microsoft 365, google Google Workspace, mte1 SendGrid). Os dois seletores coexistem durante a janela de sobreposição:

s2025-q4._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
s2026-q1._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

Duração mínima de sobreposição: 7 dias do lado da propagação, 30 dias do lado da retirada para cobrir os retries SMTP mais longos.

Calendário operacional da rotação de chaves DKIM

Gerar o par com openssl

Quatro comandos openssl cobrem a totalidade das necessidades. Todos foram testados com OpenSSL 3.x.

RSA 2048: geração da chave privada.

openssl genrsa -out dkim_private.pem 2048

RSA 2048: extração da chave pública em base64 para o DNS.

openssl rsa -in dkim_private.pem -pubout -outform der | openssl base64 -A

O resultado é o valor a colar na etiqueta p= do registo TXT.

Ed25519: geração da chave privada.

openssl genpkey -algorithm ed25519 -out dkim_ed25519_private.pem

Ed25519: extração da chave pública em base64 (32 bytes).

openssl pkey -in dkim_ed25519_private.pem -pubout -outform der | tail -c 32 | openssl base64

O tail -c 32 é necessário: o openssl emite um cabeçalho ASN.1 de 12 bytes à frente dos 32 bytes efetivos da chave Ed25519, cabeçalho que a RFC 8463 exige retirar para p=.

Tabela comparativa das três opções realistas em 2026:

Recomendação 2026: RSA 2048 sozinho para a compatibilidade máxima, ou double-publish RSA 2048 mais Ed25519 para beneficiar da assinatura Ed25519 nos recetores compatíveis. Evitar RSA 4096: a chave pública ultrapassa os 255 caracteres e impõe uma divisão TXT em várias cadeias, frágil em cada edição DNS. Para o detalhe comparativo, ver RSA vs Ed25519 para DKIM.

Gestão da chave privada

A chave privada DKIM é um segredo criptográfico do mesmo nível que uma chave TLS. Existem três modelos de armazenamento aceitáveis em produção.

KMS gerido (AWS KMS asymmetric keys, GCP Cloud KMS, Azure Key Vault). A chave é gerada e permanece no HSM. O MTA invoca a API KMS para assinar cada mensagem. A chave privada nunca é exposta na memória da aplicação, a rotação é rastreada por IAM. Desvantagem: 5 a 20 ms de latência por chamada.

HashiCorp Vault Transit. Equivalente self-hosted do KMS gerido. A chave permanece no backend Transit, o MTA assina através da API. Caminho convencional: secret/dkim/captaindns/s2026-q1.

Ficheiro PEM cifrado em repouso. Mínimo aceitável para as pequenas infraestruturas. A chave é armazenada no servidor de envio num volume cifrado (LUKS, encrypted EBS), permissões 0600, propriedade opendkim:opendkim. Implementação através de Ansible Vault, Sealed Secrets do Kubernetes ou SOPS.

Anti-padrões a banir:

• Chave privada incluída no repositório Git, mesmo em branch privado. O Git conserva o histórico para sempre.
• Chave privada passada como variável de ambiente sem cifrar (DKIM_PRIVATE_KEY=...) num docker-compose ou ficheiro .env.
• Chave privada armazenada num secret manager partilhado com contas de serviço desnecessárias (princípio do mínimo privilégio violado).

No momento da rotação, não esquecer de rodar igualmente os acessos KMS. Um ex-colaborador que tenha tido acesso de leitura a secret/dkim/captaindns/s2025-q4 não deve conservar esse acesso mesmo que a chave já não esteja ativa: continua válida para assinar mensagens retroativas.

Automatizar a rotação de chaves DKIM por cron

Uma rotação manual é esquecida nas primeiras férias da equipa. A automatização é indispensável a partir dos 3 a 4 domínios ativos. Dividir o job em 3 etapas idempotentes:

1. Generate: produzir o par e armazenar a chave privada em KMS.
2. Publish-DNS: invocar a API do fornecedor DNS para acrescentar o TXT.
3. Switch-signing: reconfigurar o MTA após a janela D-7.

Esqueleto bash Generate + Publish-DNS no Cloudflare:

#!/bin/bash
set -euo pipefail

SELECTOR="s$(date +%Y-q%q)"
DOMAIN="captaindns.com"
ZONE_ID="${CLOUDFLARE_ZONE_ID}"

# Generate RSA 2048
openssl genrsa -out "dkim_${SELECTOR}.pem" 2048
PUB=$(openssl rsa -in "dkim_${SELECTOR}.pem" -pubout -outform der | openssl base64 -A)

# Store private key in Vault
vault kv put "secret/dkim/${DOMAIN}/${SELECTOR}" private_key=@"dkim_${SELECTOR}.pem"

# Publish DNS via Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"TXT\",\"name\":\"${SELECTOR}._domainkey\",\"content\":\"v=DKIM1; k=rsa; p=${PUB}\",\"ttl\":3600}"

# Verify publication
sleep 30
dig +short TXT "${SELECTOR}._domainkey.${DOMAIN}"

Cron: 0 3 1 */6 * (a cada 6 meses, no 1.º dia do mês às 3h UTC) desencadeia a fase Generate mais Publish-DNS, seguida 7 dias depois por um segundo cron que executa Switch-signing.

Integrações com fornecedores:

• AWS SES BYODKIM: comando aws sesv2 put-email-identity-dkim-signing-attributes com o par DomainSigningSelector e DomainSigningPrivateKey codificado em base64.
• Microsoft 365: Rotate-DkimSigningConfig -Identity captaindns.com -KeySize 2048 (Exchange Online PowerShell). A rotação gera um novo seletor do lado da Microsoft mas obriga a publicar o novo CNAME no DNS para ativar a nova chave.
• SendGrid: a rotação é gerida através da API POST /whitelabel/domains/{id}/validate após acrescentar o novo CNAME junto do fornecedor DNS.

Alerta recomendado: desencadear um alarme se a taxa dkim=fail nos relatórios DMARC aggregate ultrapassar 1 % durante a janela D+0 a D+7. A validação pós-rotação é executada de modo programático através da API DKIM Record Check.

Armadilhas frequentes a evitar

Cinco armadilhas recorrentes aparecem nos tickets de suporte e nos tópicos reddit r/sysadmin.

TTL demasiado longo no seletor antigo. Um TTL de 24 horas impede a propagação rápida de uma correção. Baixar o TTL para 300 segundos 48 horas antes de D+0, depois subi-lo novamente para 3600 segundos após D+7.

Seletor com hífenes mal colocados. Alguns analisadores DKIM estritos rejeitam um seletor que contenha um hífen na primeira ou última posição. Preferir s2026q1 a -s2026-q1-.

DMARC em alinhamento estrito (adkim=s). Uma assinatura d=mail.captaindns.com é rejeitada para um From: contact@captaindns.com. Verificar que o domínio d= da nova chave se mantém idêntico ao da antiga.

Chave pública oculta do lado SaaS. Mailchimp, ActiveCampaign e outros publicam um CNAME em vez de um TXT direto. A rotação é gerida pelo fornecedor: validar que o CNAME aponta para o novo alvo após a rotação declarada.

Etiqueta s= mal configurada. A etiqueta opcional s=email restringe a utilização da chave à assinatura de mensagens eletrónicas. Uma chave publicada com s=* ou sem etiqueta aceita todos os serviços. Para o detalhe, ver a etiqueta s= no registo DKIM.

Exemplo de TXT mal codificado (wrap base64 multilinha com quebra de linha em bruto, rejeitado por alguns resolvers):

s2026-q1._domainkey.captaindns.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
                                                "p=MIIBIjANBgkqhkiG\n"
                                                "9w0BAQEFAAOC..." )

Exemplo correto (cadeia única ou divisão limpa em blocos de 255 caracteres):

s2026-q1._domainkey.captaindns.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

FAQ

Valide a próxima rotação de chaves DKIM: utilize o DKIM Record Check para verificar que o novo seletor DKIM está publicado e que a assinatura DKIM está correta antes e depois da comutação. Renovar uma chave DKIM sem downtime exige disciplina de calendário D-7/D+30 e instrumentação DMARC séria: consulte o guia DMARCbis para equipar a monitorização aggregate (rua). Para antecipar as evoluções do protocolo, ver também DKIM2 e a proteção contra o replay.

Fontes

• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301 - Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463 - A New Cryptographic Signature Method for DKIM (Ed25519)
• NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management
• Microsoft Learn - Rotate-DkimSigningConfig