Cabeçalho de e-mail: como ler um e o que ele prova

Q: Um cabeçalho de e-mail pode ser falsificado?

A maior parte, sim. From:, Reply-To:, Date:, o assunto e qualquer quantidade de linhas Received: inventadas são todos digitados pelo remetente. O que não pode ser falsificado é o que o seu próprio provedor escreveu quando a mensagem chegou: a linha Received do topo e o Authentication-Results. Leia essas duas e trate o resto como testemunho.

Q: Qual é a diferença entre From: e Return-Path:?

From: é o que o remetente quer que seja mostrado, e nada verifica isso. Return-Path: é o remetente do envelope que os servidores realmente usaram, escrito no cabeçalho pela máquina que aceitou a mensagem, e é para onde vão os bounces. O SPF é verificado contra Return-Path:, nunca contra From:, o que explica por que spf=pass sozinho diz menos do que parece dizer. Alinhar os dois é o trabalho inteiro do DMARC.

O que o bloco de cabeçalho realmente é

Toda mensagem é composta de duas partes separadas por uma linha em branco: um bloco de linhas Nome: valor, e o texto que você lê. A RFC 5322 chama a primeira parte de cabeçalho e cada linha nela de campo, e não impõe limite a quantas pode haver. Seu aplicativo de e-mail mostra quatro ou cinco. Uma mensagem que passou por três servidores costuma carregar entre trinta e sessenta.

fonte da mensagem, cortada

Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
        spf=pass smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com;
        dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"

Lida de cima para baixo, parece ruído de máquina, e a maior parte é mesmo. Quatro campos carregam quase toda a informação, e são os quatro campos deste guia: Received, From, Return-Path e Authentication-Results.

Onde o cabeçalho completo está escondido

Nada do que vem a seguir precisa de uma ferramenta, uma extensão ou uma conta. Todo cliente de e-mail guarda a mensagem bruta atrás de um item de menu, e a palavra a procurar é sempre alguma forma de origem, original ou bruto.

Onde você lê seu e-mail	O que abrir	O que você recebe
O Gmail, no navegador	O menu de três pontos em uma mensagem aberta → Mostrar original	O bloco inteiro, acima de um painel de resumo que já avaliou o SPF, o DKIM e o DMARC para você
O Outlook.com, no navegador	O menu de três pontos → Exibir → Exibir origem da mensagem	A mensagem inteira como ela chegou, em texto simples
O aplicativo do Outlook para desktop	Abra a mensagem em sua própria janela → Arquivo → Propriedades	Só o bloco de cabeçalho, na caixa na parte de baixo da caixa de diálogo
O Apple Mail, em um Mac	Visualizar → Mensagem → Raw Source	Cabeçalho e corpo juntos, em uma janela só deles
O Thunderbird, em qualquer sistema	Exibir → Código-fonte da mensagem	A mensagem inteira, com o bloco de cabeçalho no topo
O Proton Mail, no navegador	O menu de três pontos em uma mensagem → View headers	Só o bloco de cabeçalho, sem o corpo
O Yahoo Mail, no navegador	Mais → View raw message	A mensagem inteira, exatamente como foi entregue
Um arquivo que alguém te enviou, ou um que você exportou	Abra o `.eml` em qualquer editor de texto	Tudo, porque um bloco de cabeçalho e um corpo são tudo o que um `.eml` é

Esses caminhos de menu eram assim em 5 de setembro de 2026 e mudam de lugar cerca de uma vez por ano, por isso a frase acima importa mais do que a tabela: seja qual for o nome do item nesta temporada, ele vai trazer origem, original ou bruto no nome.

A cadeia Received, lida de baixo para cima

Todo servidor que aceita a mensagem escreve uma linha Received: e a coloca no topo do bloco, acima de tudo que já estava lá. Esse único hábito produz o fato mais útil que existe sobre cabeçalhos: o último salto é a primeira linha que você vê, e a jornada da mensagem é escrita de trás para frente.

Três saltos, três linhas, em ordens opostas. A linha que o seu próprio provedor escreveu fica no topo e é a única em que você pode confiar; a linha de baixo é o que a máquina remetente decidiu dizer sobre si mesma.

a cadeia Received da mesma mensagem

Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
        by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)

Cada linha é construída com o mesmo punhado de palavras, e assim que você consegue nomeá-las, a cadeia deixa de ser papel de parede.

from: Como a máquina que se conectou se identificou, seguido entre colchetes pelo que ela realmente era — o nome de DNS reverso e o endereço IP que o servidor receptor viu na conexão. O nome antes dos colchetes é uma afirmação. O endereço dentro deles foi observado.
by: O servidor que escreveu essa linha. É a única parte da linha que você pode responsabilizar por qualquer coisa nela.
with: Como o salto foi feito: ESMTP, ESMTPS quando a conexão foi criptografada, LMTP para a entrega final a uma caixa de entrada. Um salto que diz ESMTP sem o S transportou a mensagem sem criptografia.
for: O destinatário do envelope naquele salto — para qual dos seus endereços a mensagem foi realmente enviada, antes que qualquer regra de encaminhamento reescrevesse alguma coisa. Em um domínio catch-all ou com uma tag, este é o campo que nomeia o endereço que vazou.
o timestamp no final: Quando aquele servidor terminou de aceitar a mensagem. Subtraia o horário de uma linha do horário da linha acima dela e você tem o atraso naquele salto — assim você descobre onde uma mensagem lenta realmente ficou parada, em vez de adivinhar.

No exemplo acima, a mensagem saiu do aplicativo às 09:11:58 e chegou ao servidor de envio do provedor remetente dois minutos e vinte e três segundos depois; os dois saltos seguintes levaram um segundo entre eles. Uma mensagem que chega uma hora atrasada quase sempre tem uma linha com uma hora inteira dentro dela, e raramente é a última.

Quatro campos que alegam ser o remetente

“Quem enviou isto” tem quatro respostas em um cabeçalho, e elas têm permissão para discordar entre si. Na maior parte das vezes discordam por motivos banais — uma lista de discussão, uma plataforma de marketing, uma regra de encaminhamento que você mesmo configurou. Uma discordância não é prova de nada. Saber qual dos quatro você está vendo — isso sim importa.

From:: O endereço que o remetente quer mostrar, mais um nome de exibição que é texto livre. Nada verifica nenhum dos dois. Este é o campo que o seu aplicativo de e-mail coloca na lista de mensagens, e no celular o endereço costuma ficar completamente escondido atrás do nome.
Return-Path:: O remetente do envelope, escrito no cabeçalho pelo servidor que aceitou a mensagem, a partir do que foi realmente dito durante a conversa SMTP. É para onde vai um bounce, e é o endereço contra o qual o SPF é verificado — o que explica exatamente por que uma mensagem pode passar no SPF enquanto carrega um From: que não tem nada a ver com ela.
Reply-To:: Para onde a sua resposta vai ser endereçada, o que não precisa ser de onde a mensagem veio. Remetentes comuns o usam para centrais de suporte e endereços sem resposta. É também o truque mais antigo do ramo, porque um leitor cuidadoso confere o remetente, decide que está tudo bem, e então aperta Responder.
Delivered-To: e X-Original-To:: Qual dos seus endereços foi usado. Em um domínio catch-all ou com uma tag, este é o campo que nomeia o endereço que você realmente distribuiu — o que identifica quem deixou vazar.

um nome de exibição que diz uma coisa e um endereço que diz outra

From: "Example Support <support@example.com>" <billing@example.net>
         ^-- the display name, which is free text and is all a phone shows
                                              ^-- the address, which is not

O nome de exibição é texto arbitrário, então pode conter um endereço completo pertencente a outra pessoa. Todo cliente de e-mail do mundo vai mostrar a parte entre aspas e esconder a parte entre colchetes angulares, e esse é o ataque inteiro: não custa nada escrever e funciona exatamente no único campo que um leitor com certeza vai olhar.

SPF, DKIM e DMARC, em uma linha só

Um campo é diferente de todos os outros no bloco. Authentication-Results: é escrito pelo servidor que aceitou a mensagem — o seu — e qualquer coisa que chegue com o mesmo nome é removida ou renomeada antes de você ver. É a única linha em um cabeçalho que um impostor não consegue escrever.

o veredito que o seu próprio provedor registrou

Authentication-Results: mx.example.org;
        spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Três verificações moram nessa linha, e respondem a três perguntas diferentes. A quarta coluna é a que vale a pena ler duas vezes.

Verificação	O que uma aprovação significa	O que uma reprovação geralmente significa	O que nenhuma das duas prova
`spf=`	A máquina que entregou a mensagem está na lista que o domínio do remetente do envelope publica no DNS.	Ou um impostor, ou um encaminhamento comum: o SPF quebra sempre que um terceiro faz o relay de uma mensagem, o que não é uma falha e acontece o tempo todo.	Qualquer coisa sobre o endereço em `From:`. O SPF nunca olha para ele.
`dkim=`	Uma assinatura criptográfica sobre a mensagem confere com uma chave pública publicada pelo domínio que assinou.	Ou a mensagem foi alterada em trânsito — uma lista de discussão acrescentando um rodapé já basta — ou ela não foi assinada pelo domínio que alega.	Que o domínio que assinou é o domínio em `From:`. Qualquer um consegue assinar o próprio e-mail perfeitamente.
`dmarc=`	O SPF ou o DKIM passou e o domínio para o qual passou se alinha com o domínio em `From:`.	O domínio em `From:` não autorizou esta mensagem — o mais perto que um cabeçalho chega de dizer que o remetente não é quem diz ser.	Que a mensagem é segura, honesta ou desejada. Um domínio registrado hoje de manhã pode publicar um DMARC impecável até a hora do almoço.

Essa última coluna é o ponto principal, e é onde a maioria das leituras de cabeçalho erra. dmarc=pass prova que o domínio impresso em From: autorizou a mensagem. Não diz absolutamente nada sobre se esse domínio merece alguma coisa de você — e publicar os registros você mesmo leva cerca de dez minutos, para qualquer um.

Cinco coisas que um cabeçalho não consegue te contar

Onde o remetente está. O endereço da máquina em que alguém escreveu a mensagem geralmente nem está no bloco. Os grandes provedores de webmail pararam de publicar isso há anos, e o que sobra é o próprio servidor de envio deles, que vive em um centro de dados e só te conta o nome de uma empresa de hospedagem.
Quem é o remetente. Um domínio não é uma pessoa. dmarc=pass para um domínio comprado quarenta minutos atrás é uma aprovação completamente genuína.
Se alguma coisa daquilo é verdade. Autenticação é sobre o envelope, e nunca sobre a afirmação lá dentro. Uma fatura pode estar corretamente assinada, corretamente alinhada e inteiramente inventada.
Se alguém leu. Nada em um cabeçalho registra isso. O que tenta fazer isso é um pixel de rastreamento no corpo, que é um mecanismo diferente com defesas diferentes.
Quando foi escrita. Date: vem da própria máquina do remetente e do próprio relógio do remetente. Uma mensagem carimbada três horas no futuro é um computador mal configurado com muito mais frequência do que qualquer coisa interessante; os timestamps em que você pode confiar são os das linhas Received que o seu provedor escreveu.

E uma família inteira de campos não prova nada, por construção. Qualquer coisa que comece com X- é uma extensão privada inventada por quem a escreveu, e um remetente pode escrever o que bem entender: X-Spam-Status: No em uma mensagem significa que a mensagem diz que não é spam.

Quando a mensagem chega a um endereço descartável

É bom deixar claro o que este serviço devolve e o que não devolve. Uma mensagem lida aqui chega processada, não bruta: o remetente, o assunto, a data, o texto, o HTML e a lista de anexos — os campos que um script veio buscar — e não o bloco de cabeçalho. A leitura descrita acima é algo que você faz na caixa de entrada que guarda o seu e-mail de verdade.

GET /api/v1/message/{id} — o que realmente volta

{
  "id":           "m_7Kq2fV3xTn",
  "from":         "support@example.com",
  "from_name":    "Example Support",
  "to":           "signup-2026@grabmail.io",
  "subject":      "Confirm your email address",
  "date":         "2026-09-05T09:14:22+00:00",
  "expires_at":   "2026-09-10T09:14:22+00:00",
  "text":         "Confirm your address: <https://example.com/confirm/9a31b0>",
  "text_derived": true,
  "html":         "<!doctype html><html>…",
  "attachments":  []
}

O que um endereço descartável te dá em troca é um sinal que nenhum campo de cabeçalho consegue igualar, e ele funciona antes mesmo de você ler uma linha sequer: você deu aquele endereço a exatamente uma parte. Uma mensagem que chega nele alegando vir de outra pessoa, ou foi encaminhada pela parte a quem você o deu, ou foi enviada por quem quer que ela tenha repassado o endereço. Não há uma terceira explicação, e não há nada para verificar.

Esse é o mesmo argumento que uma tag faz, menos a parte em que a tag pode ser cortada em uma linha de código — aqui o próprio endereço é diferente, então não há nada para remover. É também por isso que um catch-all em um domínio que você possui é a versão mais forte disso: um endereço por cadastro, mantido enquanto você mantiver o domínio, e o Delivered-To: na sua própria caixa de entrada nomeia o que vazou.

A verificação que ainda dá para fazer

Olhe para onde o link vai, não para o que ele diz. O campo text é ou a própria parte em texto simples do remetente, ou uma renderização do HTML — o text_derived diz qual dos dois — e a renderização mantém todo destino de link entre colchetes angulares. Então o endereço para onde um botão levaria está sentado bem ali na resposta, à vista de todos, sem carregar a página, as imagens ou o pixel.

o campo text de uma mensagem que chegou só em HTML

Confirm your address: <https://example.com/confirm/9a31b0>

Not you? Ignore this message. <https://example.com/help>

A versão de sessenta segundos

Abra a fonte. Mostrar original, Exibir origem da mensagem ou Raw Source, dependendo de qual cliente você está usando.
Encontre Authentication-Results primeiro. Uma linha, escrita pelo seu próprio provedor, e a única que mais ninguém poderia ter falsificado. dmarc=pass e o domínio em From: realmente autorizou a mensagem; dmarc=fail e não autorizou.
Compare From: com Return-Path: e Reply-To:. Eles discordam por motivos banais o dia inteiro. Também discordam pelo motivo interessante.
Leia as linhas Received de baixo para cima, e pare de acreditar nelas na primeira máquina que não for do seu provedor.
Depois olhe para onde os links apontam, que é a parte que decide o que realmente acontece com você.

Tudo acima responde a uma pergunta estreita: o domínio em From: autorizou esta mensagem? É uma pergunta menor do que “isto é seguro”, e vale a pena responder mesmo assim — é a única que um cabeçalho consegue responder, ponto final.

Perguntas

Como eu vejo o cabeçalho completo no Gmail?

Abra a mensagem, depois o menu de três pontos no canto superior direito dela, depois Mostrar original. O Gmail abre uma nova aba com a mensagem bruta e, acima dela, um pequeno painel que já avaliou o SPF, o DKIM e o DMARC — o veredito mais rápido disponível em qualquer lugar, e é de graça.

Um cabeçalho de e-mail pode ser falsificado?

A maior parte, sim. From:, Reply-To:, Date:, o assunto e qualquer quantidade de linhas Received: inventadas são todos digitados pelo remetente. O que não pode ser falsificado é o que o seu próprio provedor escreveu quando a mensagem chegou: a linha Received do topo e o Authentication-Results. Leia essas duas e trate o resto como testemunho.

Dá para encontrar o endereço IP do remetente em um cabeçalho?

Geralmente não o que você tem em mente. E-mail enviado por qualquer grande serviço de webmail carrega o endereço do servidor de envio desse serviço, não da máquina em que foi escrito; os provedores pararam de publicar isso último há anos, pelo motivo óbvio. E-mail enviado por uma aplicação ou um servidor pequeno muitas vezes ainda mostra isso, entre colchetes, na linha Received de baixo — e essa linha também é a mais fácil de falsificar no bloco inteiro.

Qual é a diferença entre <code>From:</code> e <code>Return-Path:</code>?

From: é o que o remetente quer que seja mostrado, e nada verifica isso. Return-Path: é o remetente do envelope que os servidores realmente usaram, escrito no cabeçalho pela máquina que aceitou a mensagem, e é para onde vão os bounces. O SPF é verificado contra Return-Path:, nunca contra From:, o que explica por que spf=pass sozinho diz menos do que parece dizer. Alinhar os dois é o trabalho inteiro do DMARC.

O cabeçalho diz <code>dmarc=fail</code>. A mensagem é falsa?

Não necessariamente. O encaminhamento quebra o SPF por design, e uma lista de discussão que acrescenta um rodapé quebra o DKIM também, então e-mail retransmitido por uma lista, uma universidade ou uma regra de “mande tudo para o meu outro endereço” reprova rotineiramente sem deixar de ser completamente genuíno. O que a reprovação realmente significa é que nada na mensagem prova que o domínio em From: está por trás dela, então qualquer coisa que a mensagem peça para você fazer merece uma segunda via de verificação.

Para que serve o <code>Message-ID</code>?

É o nome da mensagem — único, atribuído pelo servidor remetente, e a string que In-Reply-To e References apontam para montar uma conversa. A utilidade prática disso é que centrais de suporte e postmasters conseguem procurá-lo nos próprios registros: citar o Message-ID é a diferença entre “um e-mail não chegou ontem” e uma pergunta que alguém realmente consegue responder.

Dá para ler os cabeçalhos de e-mail enviado a um endereço temporário aqui?

Não — uma mensagem lida aqui volta processada, como remetente, assunto, data, texto, HTML e lista de anexos, e o bloco de cabeçalho bruto não está entre esses campos. A compensação é que um endereço de uso único é a própria evidência: ele foi para uma única parte, então e-mail chegando de qualquer outra pessoa nomeia quem deixou vazar, sem assinatura nenhuma para verificar. As mensagens são apagadas depois de 5 dias de qualquer forma.