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

Todo e-mail traz um bloco de cabeçalhos acima do texto que você lê. Seu aplicativo de e-mail esconde esse bloco, mas é nele que fica registrado de qual servidor a mensagem veio, qual domínio respondeu por ela e para onde a sua resposta iria de fato. O phishing costuma se entregar ali, mesmo quando a mensagem em si parece perfeita.

Nós operamos um servidor de e-mail de entrada, então cabeçalhos brutos são o que lemos sempre que uma mensagem se comporta de um jeito estranho. Este guia percorre, linha por linha, um bloco de cabeçalhos de phishing realista e depois mostra o caso mais difícil, em que todas as verificações passam. Enquanto lê, você pode colar os cabeçalhos de qualquer mensagem no nosso analisador de cabeçalhos de e-mail. Ele roda no seu navegador e os cabeçalhos nunca são enviados aos nossos servidores.

Primeiro passo: tire os cabeçalhos do seu aplicativo de e-mail

Todo cliente de e-mail esconde os cabeçalhos por padrão. No Gmail, abra a mensagem, clique no menu de três pontos ao lado de Responder e escolha Mostrar original. No Outlook na web, abra o menu de três pontos e depois Exibir e Exibir origem da mensagem. No Apple Mail no Mac, escolha View, Message, All Headers. A página do analisador de cabeçalhos traz os caminhos de menu do Outlook para Windows, do Yahoo e de outros.

Copie tudo o que estiver antes da primeira linha em branco. Esse é o bloco de cabeçalhos. O corpo da mensagem vem depois e não é necessário. No iPhone e no iPad, o app Mail nativo não mostra os cabeçalhos, então encaminhe a mensagem para um computador ou confira pelo webmail.

Os cabeçalhos de um e-mail de phishing, linha por linha

Este é o bloco de cabeçalhos de um phishing típico de alerta de conta, reduzido às linhas que importam. Os domínios e endereços são fictícios, mas o padrão é o que vemos o tempo todo. Os cabeçalhos ficam empilhados do mais recente para o mais antigo, então o servidor que entregou a mensagem a você fica perto do topo e o ponto de partida fica mais abaixo.

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

O que cada linha diz

Return-Path

O endereço para onde vão os bounces, também chamado de remetente do envelope. Aqui ele está em mail.example.net, não no domínio do banco. Sozinho, isso prova pouco, porque newsletters enviadas por um provedor de e-mail marketing têm a mesma aparência. Guarde essa informação para as próximas linhas.

Authentication-Results

O veredito que o seu provedor registrou quando a mensagem chegou. O SPF passou, mas para mail.example.net, o servidor do atacante. Não há assinatura DKIM. O DMARC, a única verificação que olha o domínio From que você realmente vê, falhou para examplebank.com. Esta é a linha mais útil do bloco inteiro.

Received (topo)

Adicionada pelo servidor do seu próprio provedor, mx.example.com, quando ele aceitou a mensagem de 203.0.113.45. As linhas que o seu provedor escreve são confiáveis. Tudo o que está abaixo deste ponto foi escrito por máquinas sobre as quais você não sabe nada.

Received (base)

A etapa mais antiga, por isso a cadeia se lê de baixo para cima. A mensagem saiu de uma máquina que se chama desktop-4kq2 e foi entregue a mail.example.net com um envio autenticado (ESMTPA). O sistema de alertas de um banco não roda no computador de alguém. Uma caixa de correio roubada ou alugada, sim.

From

O nome de exibição diz Example Bank Security e o endereço afirma ser de examplebank.com. Qualquer pessoa pode digitar o que quiser neste campo. A falha de DMARC acima é a prova de que esta linha From é falsificada.

Reply-To

Se você clicar em Responder, sua resposta vai para example.org, um terceiro domínio. Um banco que quer que você ligue ou faça login não tem motivo para receber respostas no domínio de outra pessoa. Phishing que pede para você responder com seus dados quase sempre preenche este campo.

Subject e Date

Urgência mais um prazo. O Date é só o que a máquina de envio afirma, mas compare-o com os horários das linhas Received: uma diferença de horas ou dias entre o Date e a primeira etapa pode significar que a mensagem ficou parada numa fila de spam antes de chegar até você.

Message-ID

Um identificador único inventado pelo software de envio. Os sistemas de grandes empresas o marcam com o próprio domínio. Este termina em desktop-4kq2, a mesma máquina doméstica da linha Received da base. Uma divergência aqui é um indício, não uma prova, porque muitos softwares legítimos usam identificadores genéricos.

Juntando tudo, a história fica clara: uma mensagem que diz ser do banco saiu de um computador de mesa, passou pelo servidor de e-mail de um desconhecido, falhou na autenticação do próprio banco e quer a sua resposta num terceiro domínio. Quando você sabe onde olhar, chega a essa conclusão em menos de um minuto, e o analisador de cabeçalhos aponta a falha de DMARC e a divergência do Reply-To para você.

SPF, DKIM e DMARC explicados de forma simples

Essas três verificações são a parte dos cabeçalhos que o servidor de recebimento escreve depois de testar a mensagem, e não um texto digitado pelo remetente. Cada uma responde a uma pergunta diferente.

SPF

Este servidor tem permissão para enviar e-mails pelo domínio do remetente do envelope? O dono do domínio publica no DNS uma lista de servidores autorizados, e o destinatário a compara com o endereço IP que está se conectando. O SPF verifica o domínio do Return-Path, não o endereço From que você vê, e é por isso que um phishing pode passar no SPF com o próprio domínio. Veja SPF no nosso glossário.

DKIM

A mensagem foi assinada por um domínio e foi alterada desde então? O servidor de envio adiciona uma assinatura criptográfica, e o destinatário a confere com uma chave pública publicada no DNS de quem assinou. O valor header.d= indica o domínio que assinou. Uma assinatura válida de um domínio sem relação não diz nada sobre a marca que aparece na linha From.

DMARC

O domínio da linha From corresponde a um domínio que passou no SPF ou no DKIM? Essa etapa de alinhamento é o que liga as verificações ao nome que você realmente lê. O DMARC também permite que o dono do domínio diga aos destinatários o que fazer com as falhas: nada (p=none), quarentena ou rejeição. É por isso que uma mensagem falsificada ainda pode chegar à sua caixa de entrada quando a empresa verdadeira não ativou a aplicação da política.

O que cada resultado significa

O caso difícil: todas as verificações passam

Atacantes cuidadosos nem falsificam o domínio de um banco. Eles registram um parecido, configuram SPF, DKIM e DMARC direitinho e enviam a partir dele. Aí os cabeçalhos parecem impecáveis:

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

A autenticação prova que examplebank-secure.com enviou este e-mail. Ela não consegue dizer se esse domínio pertence ao seu banco. Essa parte é com você, e se resume a ler o próprio domínio bem devagar. Estes são os truques que mais vemos:

• Palavras extras. O nome verdadeiro mais -secure, -login, -support ou -verify.
• Caracteres trocados. rn no lugar de m, um zero no lugar da letra o, uma letra duplicada ou faltando.
• Uma terminação diferente. O nome certo em .co, .net ou num domínio de topo novo, em vez daquele que a empresa usa.
• O nome verdadeiro como subdomínio. Em examplebank.com.account-check.net, o domínio é account-check.net. Leia os domínios a partir da direita.
• Alfabetos parecidos. Um а cirílico é idêntico a um a latino. Nos cabeçalhos brutos, esses domínios costumam aparecer começando com xn--, que é como os nomes de domínio não latinos são codificados.
• Um nome de exibição fazendo todo o trabalho. "Example Bank" na frente de um endereço de um domínio de webmail gratuito. Muitos celulares mostram só o nome, então toque nele para ver o endereço.

Se não tiver certeza de que um domínio pertence à empresa, não use nada do e-mail para descobrir. Digite você mesmo o endereço da empresa no navegador e compare.

Sinais de alerta nos cabeçalhos, em ordem de peso

Alguns sinais são quase uma prova; outros só contam quando se acumulam. É mais ou menos assim que os avaliamos.

Uma rotina de cinco minutos para qualquer e-mail suspeito

1. 1

   Copie os cabeçalhos completos

   Use Mostrar original ou Exibir origem, como descrito acima, e copie o bloco inteiro, incluindo todas as linhas Received.

2. 2

   Cole-os num analisador de cabeçalhos

   Nosso analisador de cabeçalhos de e-mail mostra From, Reply-To e Return-Path lado a lado, exibe os resultados de SPF, DKIM e DMARC e lista a rota de entrega do mais antigo para o mais recente. A análise acontece no seu navegador.

3. 3

   Confira o DMARC em relação ao domínio do From

   Procure dmarc= e o domínio ao lado. Uma falha para uma marca que você conhece já basta para parar por aqui e apagar a mensagem.

4. 4

   Leia cada domínio devagar, a partir da direita

   From, Reply-To e o domínio que passou no DKIM devem todos pertencer à empresa. Fique atento aos truques de domínios parecidos descritos acima.

5. 5

   Leia a cadeia Received de baixo para cima

   A linha mais baixa é onde a mensagem começou. Confie apenas nas linhas adicionadas pelo seu próprio provedor, no topo. Um remetente pode inserir linhas Received falsas, e até uma linha Authentication-Results falsa, abaixo delas.

6. 6

   Verifique os links sem clicar

   Os cabeçalhos não mostram os links do corpo. No computador, passe o mouse sobre cada botão e leia o endereço que aparece no canto da janela. Qualquer coisa que não leve ao domínio verdadeiro da empresa é motivo para sair.

Se você acha que é phishing

• Não clique, não responda e não abra anexos. Responder confirma que o seu endereço é lido, e anexos são o caminho mais comum para a chegada de malware.
• Entre em contato com a empresa por outro meio. Digite o endereço dela no navegador ou use o número do seu cartão ou contrato, nunca o que está no e-mail.
• Denuncie no seu aplicativo de e-mail. No Gmail, use o menu de três pontos e Denunciar phishing. No Outlook, use Denunciar e depois Denunciar phishing. Isso treina o filtro para todos os usuários desse serviço.
• Encaminhe ao Anti-Phishing Working Group em [email protected], que compartilha as denúncias com empresas de segurança e navegadores.
• Nos EUA, denuncie à FTC em ReportFraud.ftc.gov, principalmente se houver dinheiro ou dados pessoais envolvidos.
• Se você já digitou uma senha, troque-a agora no site verdadeiro, ative a verificação em duas etapas e troque-a em qualquer outro lugar onde a tenha reutilizado. Nosso guia para verificar se o seu e-mail apareceu num vazamento de dados explica o que fazer na primeira hora depois de uma exposição.

Fontes

• IETF, RFC 7208: Sender Policy Framework (SPF), incluindo o significado de pass, fail, softfail e neutral.
• IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
• IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), publicada em 2026 em substituição à RFC 7489.
• IETF, RFC 8601: Message Header Field for Indicating Message Authentication Status, que define o cabeçalho Authentication-Results.
• Comissão Federal de Comércio dos EUA (FTC), How to Recognize and Avoid Phishing Scams, para os endereços de denúncia da FTC e do APWG.
• Anti-Phishing Working Group, Report Phishing.