Além da rotação de chaves DKIM: entendendo os ataques de replay de e-mail

O problema que a rotação de chaves não resolve

Imagine o seguinte cenário: você é o administrador de e-mail do domínio da sua organização e recebe um relatório agregado de Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio (DMARC) mostrando e-mails passando na verificação de Correio Identificado por Chaves de Domínio (DKIM) como se viessem do seu domínio — mas enviados de endereços IP que você não reconhece, para destinatários que você nunca contatou.

Para resolver, você faz a rotação da chave DKIM, confirma que o novo seletor está ativo e verifica que sua política DMARC já está configurada como p=reject. Dias depois, o mesmo tráfego desconhecido continua se autenticando como se fosse seu domínio.

O blog de segurança da AWS publicou um artigo detalhado explicando por que a rotação de chaves sozinha não consegue parar um ataque de replay DKIM, como confirmar que você está diante de um replay (e não de um relay legítimo ou spoofing comum), e qual etapa de limpeza no DNS a maioria dos guias de rotação deixa de fora. O artigo também mostra como o Amazon Simple Email Service (Amazon SES) pode ajudar a detectar e responder a essa atividade mais rapidamente.

Como funciona o replay DKIM

O DKIM verifica uma coisa: que partes específicas de uma mensagem não foram alteradas entre o assinante e o receptor. O assinante assina a mensagem com uma chave privada, e os receptores buscam a chave pública correspondente no DNS do domínio para verificar a assinatura. Uma assinatura válida continua sendo validada por onde quer que a mensagem trafegue depois — listas de distribuição, regras de encaminhamento e relays de terceiros preservam essa assinatura. Isso é o protocolo funcionando como projetado.

O ataque de replay explora justamente essa durabilidade. O fluxo funciona assim:

• Sua plataforma de e-commerce envia um e-mail legítimo de resposta a um cliente, assinado com sua chave DKIM.
• Um atacante obtém uma cópia dessa mensagem — pode ser assinando sua lista de e-mails, comprometendo uma caixa de entrada, recuperando de um arquivo de lista ou capturando via regra de encaminhamento.
• O atacante reenvia essa mensagem, sem alterações, dos seus próprios servidores para milhares de novos destinatários.
• Cada servidor receptor busca sua chave pública no DNS e verifica a assinatura. A assinatura passa porque o corpo não foi modificado.
• O Quadro de Política de Remetente (SPF) falha porque o IP de envio não é seu, mas o DMARC exige apenas que SPF ou DKIM passe com alinhamento. Como o DKIM passa, o DMARC passa, e a mensagem é entregue como e-mail autenticado do seu domínio.

É fundamental entender o que o atacante pode e não pode fazer. Ele não consegue modificar sua mensagem, adicionar conteúdo novo ou ler seus e-mails — a assinatura só é válida enquanto a mensagem permanece idêntica byte a byte. O que o atacante ganha é a reputação do seu domínio, que ele usa para entregar sua mensagem genuína a um público que você não pretendia alcançar. Um recibo ou fatura se torna uma isca, e e-mails que normalmente seriam filtrados são entregues porque os receptores confiam no seu domínio.

Isso é abuso de reputação e alcance, não falsificação de conteúdo — e essa distinção importa quando você explica o incidente para sua equipe de segurança.

Isso também explica por que uma política DMARC de p=reject não bloqueia esse ataque. O DMARC passa quando SPF ou DKIM passa com alinhamento. Durante um replay, o DKIM passa, então o DMARC passa, e o p=reject não se aplica. Essa política foi projetada para bloquear spoofing, onde o falsificador não tem assinatura válida e o DKIM falha. Ela não faz nada contra uma mensagem que você mesmo assinou.

É replay, spoofing ou relay legítimo?

E-mail vindo de um IP desconhecido que passa no DKIM tem três explicações comuns, e cada uma exige uma resposta diferente. É preciso confirmar qual é o caso antes de fazer qualquer alteração.

Os relatórios agregados DMARC (rua) fornecem o endereço IP de origem, volume de mensagens e resultados de SPF e DKIM. Isso é suficiente para identificar uma anomalia, mas não para provar um replay. Uma linha de relatório pode se parecer com isto:

source IP: 203.0.113.45 | count: 4,200 | SPF: fail | DKIM: pass (d=yourdomain.com)

É necessário avaliar essa linha contra três possibilidades:

• Relay legítimo não inventariado: uma lista de distribuição, um encaminhador ou um gateway de segurança de e-mail (como um CASB inline) pelo qual você roteia. A assinatura sobrevive validamente ao relay — isso é fluxo normal. No relatório, o IP de origem geralmente resolve para um provedor conhecido e o volume acompanha seu envio real.
• Abuso de replay: um atacante redistribui uma mensagem que você assinou legitimamente. O volume passando no DKIM vem de um IP sem relação comercial com você, frequentemente muito acima do número usual de destinatários, e muitas vezes para domínios com os quais você nunca trabalhou.
• Spoofing comum: uma falsificação sem assinatura válida. Nesse caso, a linha mostra DKIM: fail. DKIM passando de um IP desconhecido, portanto, geralmente não é spoofing comum.

Contagens agregadas sozinhas não provam um replay. Para confirmar, é necessária evidência em nível de mensagem: uma mensagem específica que você enviou correspondendo a uma que chegou a destinatários que você não endereçou. Se não for possível fazer essa correspondência, trate a atividade como anomalia não confirmada e comece pelas etapas de enforcement e monitoramento.

Configure uma política DMARC de enforcement primeiro

Antes de qualquer outra ação, confirme que você está aplicando o DMARC. Muitos domínios que encontram esse problema ainda estão em p=none, que é apenas monitoramento. Toda implantação DMARC começa em p=none, e muitas organizações não avançam além disso porque nada parece estar quebrado.

O primeiro passo, portanto, não é remoção de chave — é completar o inventário de remetentes e chegar ao enforcement:

• Inventarie cada remetente e relay legítimo do seu domínio, incluindo provedores de serviço de e-mail, listas de distribuição e gateways de segurança que enviam em seu nome.
• Alinhe cada remetente em SPF e DKIM para que o e-mail legítimo se autentique corretamente.
• Avance a política um estágio por vez: de p=none para p=quarantine para p=reject.
• Revise seus relatórios rua em cada estágio antes de avançar, tipicamente por uma ou duas semanas por estágio.
• A tag pct permite aumentar gradualmente — por exemplo, colocando em quarentena 25% dos e-mails falhando antes de aumentar o percentual.

Após o enforcement, receptores que honram o DMARC descartam spoofing não autenticado em nome do seu domínio. Somente depois dessa linha de base estar em vigor, e somente após confirmar um replay de e-mail genuinamente assinado, é que o próximo passo se aplica.

Remova a chave antiga do DNS: higiene de rotina pós-rotação

A maioria dos guias de rotação omite essa etapa. Rotacionar uma chave e remover a chave antiga são duas ações separadas. Rotação significa que seu provedor começa a assinar novos e-mails com uma nova chave e seletor. Remoção significa deletar a chave pública antiga do DNS, para que mensagens assinadas anteriormente — incluindo cópias capturadas por um atacante — não possam mais ser verificadas.

Se você rotaciona mas deixa a chave pública antiga publicada, cada mensagem já assinada com aquela chave permanece replayável enquanto o registro existir. Remover a chave antiga é o que fecha essa janela — e é o passo comumente esquecido.

A remoção afeta apenas mensagens ainda em trânsito assinadas com a chave antiga. Após a entrega, o receptor não precisa mais da sua chave. A recomendação é deixar a chave antiga publicada tempo suficiente para e-mails em trânsito chegarem e então removê-la.

Métodos DKIM no Amazon SES

Como você gerencia as chaves depende do método DKIM utilizado com o Amazon SES:

• BYODKIM (Traga Sua Própria Chave DKIM): você gera o par de chaves e publica a chave pública como registro TXT que você controla. É possível rotacionar e remover chaves quando quiser, incluindo remoção sob demanda durante um incidente. Como a documentação do BYODKIM afirma, “você pode rotacionar as chaves DKIM dos seus domínios com a frequência que desejar”.
• Easy DKIM: o Amazon SES gera e gerencia as chaves. Você publica registros CNAME que apontam para chaves hospedadas na AWS. Como o DNS aponta para chaves hospedadas pela AWS através desses CNAMEs, o Amazon SES gerencia o material de chave subjacente, então você não publica ou remove chaves individuais diretamente. Diferente do BYODKIM, o Easy DKIM não oferece opção sob demanda para deletar uma chave específica imediatamente.

Se você usa Easy DKIM durante um replay confirmado, suas defesas são: detecção precoce, o throttling de mensagens duplicadas que os receptores já aplicam, e a longo prazo, a iniciativa DKIM2 — um esforço do IETF para atualizar a especificação DKIM com resistência nativa a replay.

Como o Amazon SES ajuda na detecção e resposta

A primeira resposta é detecção, não mudanças no DNS. O objetivo é identificar volume anômalo passando no DKIM cedo, enquanto se constrói a evidência em nível de mensagem que distingue replay de relay legítimo.

Habilitando o monitoramento

Crie um conjunto de configuração do Amazon SES com destino de eventos (veja Monitorar envio de e-mail usando publicação de eventos do Amazon SES) que transmita eventos por mensagem (Send, Delivery, Bounce e Complaint) para o Amazon Data Firehose ou Amazon EventBridge (veja Adicionar um destino de evento), tagueados com o domínio do From.

Separadamente, confirme que você está recebendo relatórios rua para seu domínio. Esses relatórios são habilitados adicionando um endereço rua= ao registro TXT DMARC do domínio, por exemplo rua=mailto:dmarc-reports@yourdomain.com. Para a sintaxe do registro e um rollout gradual de p=none para p=quarantine para p=reject, consulte Conformidade com o protocolo de autenticação DMARC no Amazon SES. Os relatórios chegam como resumos XML diários, e a maioria das equipes os processa com um analisador DMARC.

Correlação de dados

Com ambas as fontes ativas, é possível correlacioná-las: compare os e-mails que sua conta emitiu (com base nos eventos de entrega do Amazon SES) contra o que os relatórios DMARC mostram que os receptores aceitaram como seu domínio. Quando o DMARC mostra volume passando no DKIM de IPs fora do seu registro SPF que excede os eventos de entrega que o Amazon SES registrou para aquele domínio From no mesmo período, essa diferença é o seu sinal.

Controles adicionais recomendados

• Autorização de envio do Amazon SES: restringe quais principals da AWS podem enviar usando sua identidade verificada. Não impede um replay externo, mas endereça o vetor de insider e terceiros que SPF, DKIM e DMARC não cobrem sozinhos. Use políticas em nível de identidade para limitar o envio a principals específicos do AWS Identity and Access Management (IAM).
• TTLs curtos no DNS: use o Amazon Route 53 para definir valores baixos de Tempo de Vida (TTL) — por exemplo, 300 segundos — nos registros DKIM, para que mudanças se propaguem rapidamente. Habilite o log de consultas DNS com um filtro de métricas do Amazon CloudWatch Logs que monitore consultas a um seletor do qual você já migrou. Um pico de lookups para um seletor antigo é um indicador precoce útil de tentativa de replay.
• Automação de remoção: para domínios BYODKIM durante replay confirmado, o Route 53 é onde você remove o registro TXT do seletor antigo. É possível automatizar essa remoção usando um alarme do CloudWatch que aciona uma função AWS Lambda para chamar a API do Route 53 e aposentar o registro do seletor antigo. Escope a role IAM da função apenas para a hosted zone e registro específicos que ela precisa alterar, seguindo o princípio de menor privilégio. Como uma mudança incorreta no DNS pode ter efeito amplo, condicione qualquer automação a critérios de replay confirmado e teste em domínio não-produtivo primeiro. Para a maioria das equipes, alarme-para-humano é mais seguro do que alarme-para-remoção-automática.

Quando seu domínio é o abusado

A maioria dos guias assume que você é o provedor prevenindo abuso ou o receptor detectando. Em um replay, seu domínio é o que tem a reputação consumida, e você não está na lista de destinatários. Consequentemente, você não tem a mensagem que todos pedem quando você reporta o problema.

Quando você registra uma denúncia de abuso com o provedor que hospeda o IP de origem, eles pedem cabeçalhos completos da mensagem. O e-mail foi para pessoas que você não contatou, então você não tem esses cabeçalhos. Você fornece relatórios DMARC agregados mostrando o IP de origem e volume, e o provedor pede cabeçalhos novamente. Nesse ponto, você fica travado.

Para quebrar esse ciclo: vá aos destinatários. Revise seus relatórios rua para os principais domínios destinatários — frequentemente domínios .gov e .edu — contate esses destinatários diretamente e solicite uma amostra da mensagem com cabeçalhos completos. Além de fornecer os cabeçalhos, essa amostra permite confirmar um replay em vez de relay legítimo.

Construa sua denúncia de abuso em torno do endereço IP e da evidência DMARC, não do conteúdo da mensagem. Se o IP de origem pertence à Amazon Web Services (AWS), reporte através do processo de abuso da AWS e inclua seus relatórios DMARC e registro SPF como evidência.

Resposta a incidentes: ações ordenadas

Se seus relatórios mostram e-mail suspeito passando no DKIM de IPs desconhecidos, siga este procedimento:

• Confirme que é um replay. Correlacione uma mensagem que você enviou com uma que chegou a destinatários que você não endereçou. Descarte relays e gateways legítimos. Dados agregados sozinhos não são prova.
• Chegue a uma política DMARC de enforcement. Inventarie seus remetentes legítimos, alinhe-os e avance de p=none para p=quarantine para p=reject. Isso bloqueia spoofing.
• Endureça o SPF para -all em vez de ~all, mas somente após o inventário de remetentes estar completo, já que -all faz hard-fail em qualquer fonte legítima não listada.
• Verifique o cabeçalho DKIM-Signature de uma mensagem recente para confirmar que seu provedor assina apenas com o seletor atual.
• Reporte o IP de origem ao provedor de hospedagem e inclua sua evidência DMARC.
• Investigue o ponto de captura: caixa de entrada comprometida, lista de distribuição, regra de encaminhamento ou assinatura de newsletter.
• Remova a chave pública DKIM antiga após e-mails em trânsito terem sido entregues. Para BYODKIM, delete o registro TXT do seletor antigo. Para Easy DKIM, confie na rotação gerenciada do Amazon SES junto com o monitoramento e defesas do lado receptor descritas anteriormente.

Resumo das ações e seus limites

• Confirmar replay (nível de mensagem): separa replay de relay legítimo ou spoofing — mas não pode ser feito apenas com dados agregados DMARC.
• Enforcement DMARC (p=reject): descarta spoofing não autenticado — mas não faz nada contra replay porque o DKIM ainda passa.
• Rotação de chave: assina novos e-mails com nova chave — mas não invalida mensagens já assinadas.
• Remoção da chave antiga (pós-rotação): invalida assinaturas da chave antiga, incluindo cópias capturadas — mas não protege e-mails em trânsito com chave antiga; remoção sob demanda disponível apenas com BYODKIM.
• Autorização de envio do Amazon SES: restringe quais principals enviam como sua identidade — mas não impede replay externo de mensagens capturadas.

Conclusão

O replay DKIM funciona porque uma assinatura válida continua validando, e uma política DMARC de enforcement não muda isso. Para responder de forma eficaz, é necessário: confirmar que a atividade é um replay com evidência em nível de mensagem, chegar a uma política DMARC de enforcement e então remover a chave antiga do DNS como higiene de rotina pós-rotação.

A defesa primária deve estar no monitoramento e enforcement DMARC, não em mudanças emergenciais no DNS. A correção durável para replay está do lado do receptor: contagem de mensagens duplicadas hoje, e sinais mais fortes em nível de protocolo através do DKIM2 no futuro.

Para começar, a recomendação é: revisar a política DMARC atual e confirmar o recebimento de relatórios rua, habilitar a publicação de eventos do Amazon SES, e documentar como você rotaciona e remove chaves DKIM para cada domínio.

Saiba mais

• Autenticação de e-mail com DKIM no Amazon SES
• Conformidade com o protocolo DMARC no Amazon SES
• Usando autorização de envio com o Amazon SES
• DKIM2: Uma Revisão do DKIM (Grupo de Trabalho IETF)
• Logging de consultas DNS públicas do Route 53 com Amazon CloudWatch Logs

Fonte

Beyond DKIM key rotation: understanding email replay attacks (https://aws.amazon.com/blogs/security/beyond-dkim-key-rotation-understanding-email-replay-attacks/)