Ler os cabeçalhos de e-mail para detetar falsificações

Todos os e-mails levam nos cabeçalhos um rasto completo: os servidores por onde passaram, os resultados de autenticação e o verdadeiro remetente do envelope. Lê-los com desenvoltura é a forma mais rápida de confirmar ou desmentir uma suspeita de falsificação, e é uma competência central na triagem de phishing reportado.

Onde encontrar os cabeçalhos em bruto

A mensagem apresentada esconde tudo o que é útil. Obtenha a origem em bruto:

• Gmail — Mostrar original.
• Outlook — Ficheiro → Propriedades → Cabeçalhos da Internet (ou Ver origem da mensagem).
• Apple Mail — Ver → Mensagem → Origem em bruto.
• Linha de comandos — inspecione o .eml diretamente.

Para o percurso de entrega, os cabeçalhos leem-se de baixo para cima: o salto mais antigo está em baixo e o Received: do servidor recetor no topo.

As identidades que importam

Há dois valores «de», e o phishing explora precisamente a distância entre eles:

• Remetente do envelope (Return-Path / MAIL FROM) — usado no encaminhamento e nas devoluções; verificado pelo SPF.
• From de cabeçalho (From:) — o que o utilizador vê no seu programa.

Uma falsificação mostra tipicamente um From: de confiança enquanto o Return-Path aponta para outro lado.

Return-Path: <[email protected]>
From: "IT Helpdesk" <[email protected]>

O nome apresentado (IT Helpdesk) é totalmente controlado pelo atacante e não prova nada.

Ler o Authentication-Results

O cabeçalho de longe mais importante é o Authentication-Results, acrescentado pelo seu servidor recetor (confie apenas no do seu próprio domínio, no topo):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) [email protected];
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Interprete com cuidado:

• spf=pass aqui é uma armadilha — passou para sketchy-host.ru, não para o visível yourbank.example. O SPF verifica o envelope, não o From:.
• dkim=fail — não há assinatura válida alinhada com o domínio do From:.
• dmarc=fail (p=reject) — este é o veredicto que conta: a autenticação do domínio visível não alinha. Uma mensagem que chega à caixa apesar de dmarc=fail merece exame.

Compare sempre o domínio que cada mecanismo autenticou de facto (smtp.mailfrom, header.d) com o domínio do From:. Autenticação sem alinhamento não significa nada.

Seguir o percurso com o Received

Cada salto acrescenta uma linha Received: no topo. Leia de baixo para cima:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Sinais de alerta:

• O IP do salto de origem geolocaliza-se longe de onde o remetente diz estar.
• Um HELO forjado (localhost, ou um nome de anfitrião que não bate certo com o DNS inverso).
• Lacunas suspeitas ou saltos de fuso horário nas marcas temporais.
• O primeiro salto de confiança é o seu próprio MX — tudo o que está abaixo é fornecido pelo atacante e falsificável, pese-o em conformidade.

Outros indícios nos cabeçalhos

• Divergência de Reply-To — o From: parece um colega, mas o Reply-To desvia as respostas para um endereço externo. Clássico no BEC e na fraude do CEO.
• Domínio do Message-ID que não corresponde ao domínio de envio.
• Cabeçalhos X-Mailer / X-PHP-Script que revelam uma ferramenta de envio em massa ou um script PHP num servidor comprometido.
• Unicode/punycode no domínio do From: (xn--) — um ataque homógrafo.

Uma lista rápida de triagem

1. Domínio do From: == domínio do Return-Path?          (divergência = suspeito)
2. Authentication-Results: dmarc=pass e alinhado?        (fail = suspeito)
3. Que domínio autenticaram de facto SPF/DKIM?           (tem de bater com From:)
4. O Reply-To difere do From:?                           (sim = suspeito)
5. De onde parte o salto Received mais em baixo?         (geo inesperada = suspeito)
6. Punycode ou homóglifos no domínio do From:?           (sim = suspeito)

Um único cabeçalho raramente prova por si só uma falsificação. O veredicto vem do alinhamento: o domínio que se autenticou corresponde ao que a pessoa vê? O DMARC existe precisamente para automatizar essa comparação — mas no correio que chega de outros domínios continua a ser preciso lê-lo à mão.

Como ajuda a GottaPhish

Ler cabeçalhos é uma competência reativa e de especialistas, e a maioria dos utilizadores nunca os vê. A GottaPhish e a sua equipa de especialistas fazem essa ponte: phishing simulado realista — falhas de alinhamento, Reply-To trocado, domínios parecidos — além de painéis que indicam exatamente quem reportou, clicou ou submeteu credenciais. Os nossos especialistas apoiam a implementação, desenham cenários que exercitam os truques de cabeçalho que os atacantes usam mesmo e ajudam a interpretar os resultados — afinando os manuais de triagem das equipas técnicas enquanto a formação ensina a todos os outros os sinais visíveis por detrás desses cabeçalhos.