Guias · E-mail e domínios

Como ler os cabeçalhos de um e-mail e identificar phishing

Escrito por Aldo · threat hunter em um blue team
Última atualização: 9 de novembro de 2026 · 5 min de leitura

Um e-mail diz vir do seu banco, da sua chefe ou de um fornecedor. A linha From que você vê é só texto que o remetente digitou. Os cabeçalhos por baixo registram o que os servidores de e-mail realmente viram, e são muito mais difíceis de falsificar.

Abra os cabeçalhos completos

Todo programa de e-mail esconde os cabeçalhos por padrão. Veja onde estão (os nomes dos menus mudam entre versões, mas estes estão estáveis há um bom tempo):

• Gmail (web): abra o e-mail, clique nos três pontos ao lado de Responder e depois em Mostrar original.
• Outlook na web e o novo Outlook: abra o e-mail, selecione os três pontos e depois Exibir → Exibir detalhes da mensagem.
• Outlook clássico para Windows: abra o e-mail numa janela própria e depois Arquivo → Propriedades; os cabeçalhos ficam em Cabeçalhos de Internet.
• Apple Mail no Mac: Visualizar → Mensagem → Todos os Cabeçalhos.
• Thunderbird: Exibir → Código-fonte da mensagem (Ctrl+U).
• Os apps de e-mail do iPhone e do Android geralmente não mostram os cabeçalhos completos. Abra a mesma caixa de entrada num computador.

Copie tudo, do topo até a primeira linha em branco. Esse bloco é o cabeçalho.

Um exemplo real: a fatura vencida

Este é o exemplo do analisador de cabeçalhos do iplover. Os domínios são de documentação (example.com, .org, .net) e o endereço de envio é um nó de saída do Tor público, então nenhuma empresa ou pessoa real está envolvida, mas cada linha é do tipo que você vai encontrar num phishing de verdade:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.org header.s=s1 header.b=Xy12;
       spf=pass (google.com: domain of bounce@mailer.example.org designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@mailer.example.org;
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.com
Return-Path: <bounce@mailer.example.org>
Received: from relay.mailer.example.org (relay.mailer.example.org. [198.51.100.25])
        by mx.google.com with ESMTPS id 5a1b2c3d4e
        for <you@example.net>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Nov 2026 10:14:04 -0800 (PST)
Received: from webmail.example.org (unknown [185.220.101.7])
        by relay.mailer.example.org (Postfix) with ESMTPSA id 7C1A2B3;
        Tue,  3 Nov 2026 16:11:58 +0000 (UTC)
Received: from [10.0.0.12] (localhost [127.0.0.1])
        by webmail.example.org with ESMTP;
        Tue,  3 Nov 2026 16:11:55 +0000 (UTC)
From: "Example Billing" <billing@example.com>
Reply-To: payments-desk@example.net
Subject: Invoice 4471 is overdue
Message-ID: <20261103161152.4471@mailer.example.org>
X-Originating-IP: [185.220.101.7]

(Encurtado; o exemplo completo também tem cabeçalhos ARC, que registram as verificações feitas pelos servidores no caminho.) O veredito do analisador:

Como ler, linha por linha

1. Authentication-Results: o veredito do servidor que recebeu

O servidor que recebeu a mensagem (aqui, o do Google) a verificou e anotou os resultados. Leia a linha Authentication-Results mais de cima: é a que o seu próprio provedor de e-mail acrescentou. Qualquer linha mais abaixo pode ter sido escrita por qualquer um, inclusive pelo remetente.

O truque deste exemplo é que SPF e DKIM passaram, mas não para o domínio certo. O SPF passou para mailer.example.org e o DKIM para example.org, mas o endereço From diz example.com. O DMARC é a verificação que amarra o resultado ao domínio do From, e ele falhou. O dono de example.com tinha até publicado uma política pedindo a recusa desses e-mails. Esse padrão, tudo passando menos o DMARC, é a cara típica do e-mail falsificado.

2. From, Reply-To e Return-Path: quem diz ser, e para onde vão as respostas

A linha From mostra “Example Billing” em example.com. Já o Reply-To manda a sua resposta para example.net. Centrais de atendimento e listas de e-mail fazem isso de forma legítima, mas numa fatura inesperada isso quer dizer: quem escreveu quer a sua resposta num lugar que a empresa verdadeira não controla. O Return-Path é para onde vão as devoluções; ver ali o domínio de um serviço de envio é normal.

3. Received: o caminho da entrega, lido de baixo para cima

Cada servidor que lida com uma mensagem acrescenta uma linha Received no topo, então a mais antiga fica embaixo. Leia de baixo para cima: um aparelho numa rede privada (10.0.0.12) entregou o e-mail ao webmail, que o recebeu de 185.220.101.7, um nó de saída do Tor, antes de passá-lo ao relay e depois ao Google. Esse primeiro endereço público é o mais perto do remetente que você vai chegar, e aqui ele é anônimo de propósito. O X-Originating-IP, que alguns serviços de webmail acrescentam, diz o mesmo.

Os horários também contam algo: duas horas entre o relay e o Google. Atrasos acontecem por motivos inocentes, mas valem a atenção.

Se você vir isto, faça isto

O que os cabeçalhos não conseguem dizer

Os cabeçalhos provam de onde veio uma mensagem, não o que ela quer. Uma mensagem de uma conta verdadeira mas invadida passa em todas as verificações. Um domínio imitador passa no DMARC para si mesmo. E os cabeçalhos não dizem nada sobre o link ou o anexo, que é onde o estrago costuma estar. Então eles são uma evidência entre várias: um pedido inesperado de dinheiro, de senhas ou de decisões rápidas merece desconfiança, digam o que disserem os cabeçalhos.

O analisador do iplover lê os resultados que o seu provedor registrou; ele não verifica de novo as assinaturas DKIM nem baixa os registros SPF de cada etapa. Ele diz isso no fim de cada relatório, e vale a pena lembrar disso com qualquer ferramenta.