Rotação de chaves DKIM não basta contra ataques de replay de e-mail, explica post da AWS

O post da AWS parte de um cenário comum: o relatório agregado de DMARC mostra e-mails passando no DKIM como se fossem do seu domínio, vindos de IPs desconhecidos. Mesmo depois de rotacionar a chave e manter o DMARC em p=reject, o tráfego segue autenticando. A razão é como o DKIM funciona. Ele só garante que partes da mensagem não mudaram entre quem assina e quem recebe. Listas de e-mail, regras de .forward e relays preservam a assinatura, então uma cópia legítima continua válida onde quer que seja reenviada.

No replay, o invasor obtém uma cópia de uma mensagem assinada (por assinatura de lista, caixa comprometida, arquivo de lista ou regra de encaminhamento) e a reenvia sem alterações. O SPF falha, mas o DMARC só exige SPF ou DKIM alinhado. Como o DKIM passa, o DMARC passa e o p=reject não se aplica. O invasor não altera nem lê e-mails: ele consome a reputação do domínio, e um recibo ou fatura vira isca. Os relatórios rua trazem IP, volume e resultados de SPF e DKIM, o bastante para ver a anomalia, mas não para provar o replay. Isso exige evidência no nível da mensagem.

O passo que a AWS diz faltar na maioria dos guias é remover a chave pública antiga do DNS. Rotacionar e remover são ações separadas: se a chave antiga continua publicada, toda mensagem assinada com ela segue reproduzível. Com BYODKIM, você remove a chave quando quiser. Com Easy DKIM, a AWS gerencia o material e não há remoção imediata sob demanda. Nesse caso, restam detecção precoce, o throttling de mensagens duplicadas que os receptores já aplicam e, a longo prazo, o DKIM2, iniciativa do IETF com resistência a replay.

Na detecção, a AWS sugere um configuration set no Amazon SES com eventos enviados ao Amazon Data Firehose ou Amazon EventBridge, e a correlação com o DMARC. Se o volume com DKIM aprovado vindo de IPs fora do SPF superar os eventos de entrega do SES para o mesmo domínio na mesma janela, essa diferença é o sinal. Também entram TTLs curtos no Route 53 (como 300 segundos) e logs de consulta DNS com filtro no CloudWatch para consultas a um seletor já aposentado. A automação da remoção via Lambda deve ter IAM com privilégio mínimo, e a AWS considera mais seguro alarme para humano do que remoção automática.

A cobertura anterior não mostra evolução deste mesmo caso, mas dá contexto. Em 8 de junho de 2026, o CEVIU noticiou "Segurança de E-mail: Por Que 74% das Organizações Travam no Meio do Caminho", com dados de que só 26% dos domínios aplicam DMARC com p=reject ou quarantine. O post da AWS lembra que muitos domínios ficam em p=none e que chegar ao enforcement é o primeiro passo, antes de qualquer remoção de chave. Já o replay mostra o limite do enforcement: ele barra spoofing, não mensagens que você mesmo assinou.

Para quem opera e-mail corporativo, a leitura é que p=reject é necessário, mas não encerra o problema. Um relatório com DKIM pass vindo de IP estranho pede investigação de replay, e não só rotação de chave. Para quem usa Easy DKIM, a falta de remoção sob demanda torna a detecção (SES, rua e logs de DNS) a defesa principal. Vale também planejar como obter amostras com cabeçalhos completos dos destinatários, já que você não está na lista de entrega.