Resumo

  • Um resultado DKIM válido confirma uma assinatura sobre partes canônicas selecionadas da mensagem com a chave indicada por s= e pelo domínio d=. Ele não autoriza automaticamente o domínio visível no campo From.
  • A RFC 9989 acrescenta o alinhamento DMARC para a alegação do domínio autor. Mesmo um resultado alinhado não prova verdade, segurança, atualidade nem permissão para uma ação de negócio.

A assinatura certa recebeu o significado errado

O verificador consultou a chave pública no DNS do atacante, recalculou o hash do corpo e validou a assinatura. Não houve falsificação criptográfica. O erro apareceu quando a regra seguinte guardou apenas a palavra “passou” e descartou qual domínio havia passado.

DKIM permite que um domínio assuma responsabilidade por transmitir uma mensagem. O campo d= nomeia esse Signing Domain Identifier; s= escolhe o espaço da chave; h= enumera os cabeçalhos assinados; bh= leva o hash do corpo canonicalizado; e b= leva a assinatura sobre os cabeçalhos escolhidos e o próprio campo DKIM com seu valor de assinatura vazio.

O From precisa estar em h=. Isso protege o texto assinado contra alteração posterior, mas não prova que o domínio em d= controla o domínio escrito no From. Um atacante pode assinar de modo impecável uma alegação falsa sobre outra organização.

O corpo tem uma fronteira própria

A validação não deve ser reduzida a uma única luz verde. O receptor canonicaliza o corpo, compara o resultado a bh=, obtém a chave de s= sob d=, monta a entrada dos cabeçalhos e verifica b=. Se bh= divergir, a RFC 6376 exige que a assinatura inteira falhe, ainda que a verificação dos cabeçalhos parecesse correta.

Os modos simple e relaxed toleram transformações diferentes. Uma mudança de espaço invisível ao leitor pode quebrar uma assinatura, enquanto uma instrução maliciosa que permaneceu intacta pode passar. Canonicalização é regra de representação, não julgamento de sentido.

O l= opcional torna a fronteira mais delicada. Ele restringe a cobertura a um prefixo do corpo já canonicalizado. Texto anexado depois desse limite pode permanecer fora de bh=; com l=0, o corpo fica inteiramente sem assinatura. O recurso ajudou intermediários que acrescentam rodapés, mas também abre uma superfície para inserções não autorizadas. A interface não pode exibir um único selo sobre todo o texto quando apenas o começo foi coberto.

From precisa de alinhamento

A RFC 9989, publicada em maio de 2026, substitui a RFC 7489 como padrão DMARC atual. Ela compara o Author Domain do RFC5322.From com um identificador DKIM ou SPF autenticado. No modo estrito, os domínios precisam ser idênticos; no modo relaxado, devem pertencer ao mesmo Organizational Domain.

No exemplo inicial, DKIM passa para receipt-alert.example, mas o alinhamento com bank.example falha. Os dois fatos precisam sobreviver no mesmo registro. Dizer somente “DKIM passou” esconde a falha relevante para o autor mostrado ao leitor.

Mesmo DMARC pass continua limitado. A RFC 9989 diz que ele valida o uso autorizado do Author Domain, não faz uma afirmação de valor sobre a mensagem e não garante que a entrega seja segura ou desejável. Uma conta comprometida ou uma plataforma legitimamente autorizada ainda pode assinar conteúdo perigoso.

Identidades e testemunhos não se fundem

Envelope SMTP, identificador SPF, domínio d=, AUID i=, From e conta autenticada por SMTP são registros diferentes. Uma mensagem também pode carregar várias assinaturas DKIM, de domínios iguais ou distintos. Cada uma precisa de verificação e alinhamento próprios.

Authentication-Results transporta essas avaliações para filtros e clientes, mas sua autoridade depende do produtor. A borda de entrada deve remover ou isolar instâncias fornecidas externamente e aceitar apenas resultados de validadores autorizados pelo domínio administrativo receptor.

Listas e outros mediadores podem acrescentar rodapés, reescrever assuntos ou recodificar o corpo, quebrando DKIM e DMARC legítimos. ARC preserva uma cadeia de avaliações anteriores, mas não transforma todos os intermediários em testemunhas confiáveis. O destinatário ainda avalia o signatário ARC, a cadeia e a política local.

Prazo não impede repetição

t= pode registrar a criação e x= a expiração. A RFC 6376 declara expressamente que x= não é defesa contra replay. Uma mensagem válida capturada pode ser redistribuída ou processada de novo enquanto a assinatura permanece intacta.

Por isso, autenticação de e-mail e idempotência de negócio devem ter registros separados. Uma ordem de pagamento pode ter vindo de um domínio autorizado e ainda ser antiga, duplicada ou fora do mandato atual. Identificador de transação, estado de fluxo, controle da conta e confirmação humana decidem a ação.

Os testes precisam manter os substantivos. Assine um phishing com domínio próprio e From alheio: DKIM deve passar, alinhamento deve falhar. Depois envie conteúdo hostil com domínio alinhado: autenticação passa, política de risco decide. Acrescente texto após l=, altere campos assinados e não assinados, injete um Authentication-Results externo, alterne o seletor no DNS, atravesse uma lista e repita a mensagem intacta.