Ferramentas populares

Tema

Analisador de Cabeçalhos de E-mail

Use este analisador de cabeçalho: cole os cabeçalhos de um e-mail para ver o caminho que ele percorreu, quanto tempo cada salto levou e o que as verificações de SPF, DKIM e DMARC do seu provedor disseram. Não sabe como pegar o cabeçalho do email? O passo a passo está logo abaixo.

Lido no seu navegador · só os IPs públicos dos servidores são consultados, e o domínio do remetente se você pedir · nada é armazenado

Seus cabeçalhos nunca saem do seu dispositivo. Só os endereços IP e os domínios listados abaixo do resultado são consultados.

O que você vai ver

  • Quem realmente enviou, julgado só pelas verificações do próprio provedor
  • Cada servidor no caminho, o atraso em cada um e se usou TLS
  • SPF, DKIM, DMARC e ARC, e se coincidem com o endereço do From
  • Domínios parecidos, resultados forjados e outros sinais, cada um com a sua evidência
  • Cabeçalhos de spam do Microsoft 365, do Gmail e do SpamAssassin, decodificados
  • Regras do Gmail e do Yahoo para remetentes em massa, incluindo o cancelamento com um clique

O que é um cabeçalho de e-mail?

O cabeçalho de e-mail é o bloco de linhas acima do texto da mensagem: quem enviou e para quem, quando, e um registro de cada servidor que a processou. Os apps de e-mail escondem quase tudo isso; “Show original” ou “View source” mostra tudo.

Cada linha tem um nome, dois-pontos e um valor; um valor longo continua em linhas que começam com um espaço (RFC 5322). Os cabeçalhos terminam na primeira linha em branco. Tudo o que vem depois é o corpo, que esta ferramenta nunca lê.

Três tipos de autores os escrevem: o app do remetente (From, To, Subject, Date), cada servidor no caminho (uma linha Received por servidor) e o seu provedor (Authentication-Results, vereditos de spam). Só os últimos são verificados por alguém em quem você confia.

O exemplo da newsletter30 campos · 4,6 KB

Adicionado pelo seu provedor (Google)11 campos

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

Adicionado por servidores no caminho (SendGrid e example.org)5 campos

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

Escrito pelo app do remetente14 campos

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

linha em branco: o corpo começa aqui, e esta ferramenta nunca o lê

Resumido: uma linha por campo, numerada como nos cabeçalhos. Cores como no resultado: seu provedor, servidores no caminho, o remetente.
Analisador de cabeçalhos de e-mail: resultado de mensagem que imita o PayPal, com veredito, achados e 41 minutos de atrasoAnalisador de cabeçalhos de e-mail: resultado de mensagem que imita o PayPal, com veredito, achados e 41 minutos de atrasoO vereditoQuem enviou, julgado só pelo Authentication-Results que o seu provedor escreveu, com o servidor que fez a verificação.O que chama atençãoCada achado com a gravidade, o motivo e a linha exata do cabeçalho de onde ele vem.O caminho de entregaCada servidor, do cabeçalho Date até a caixa de entrada, com as lacunas em escala e o limite de confiança atravessando o caminho.Os fatosQuanto tempo a entrega levou, quantos saltos, se todo salto externo usou TLS e qual pasta a Microsoft escolheu.
O exemplo suspeito: as verificações do próprio Microsoft 365 não confirmam o remetente, os achados apontam as evidências e o caminho mostra onde a mensagem esperou. Selecione um número para ver o que cada parte mostra.

Como ler cabeçalhos de e-mail, de baixo para cima

Para analisar cabeçalhos de e-mail, leia as linhas Received de baixo para cima. Cada servidor adiciona a sua linha no topo das que já estão lá, então a mais baixa é o primeiro salto e a do topo é o seu provedor entregando a mensagem à caixa de entrada (RFC 5321 §4.4).

Uma linha diz quem recebeu (by), de qual servidor e endereço (from, o endereço visto na conexão), como (with: ESMTPS significa STARTTLS, ESMTPSA significa STARTTLS mais login) e quando. Os servidores carimbam a própria hora local, então converta cada uma para UTC antes de subtrair: 07:02:47 -0700 é 14:02:47 UTC.

Só as linhas que o seu provedor escreveu são certas. Tudo abaixo da primeira linha dele vem de servidores que você não pode verificar, e um remetente pode adicionar linhas próprias.

No cabeçalho · o topo é o mais recente

A viagem · salto 1 primeiro

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Google interno14:02:48 UTC+1 s
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33 s

Limite de confiança

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3filtro de SendGrid14:02:13 UTC+0,6 s
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2,9 s
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTCprimeiro

Leia para cima: cada servidor adiciona a sua linha no topo

As cinco linhas Received da newsletter. O salto 1 é o app da newsletter; os 33 s entre o SendGrid e o Google são a maior lacuna.

SPF, DKIM e DMARC nos cabeçalhos de e-mail

O SPF pergunta se o servidor de envio pode enviar pelo domínio do envelope (o Return-Path). O DKIM pergunta se um domínio assinou a mensagem e se a assinatura ainda confere. O DMARC pergunta se um domínio aprovado no SPF ou no DKIM coincide com o endereço do From que você vê.

Seu provedor escreve as respostas no Authentication-Results. Confie no bloco que o seu provedor escreveu ao lado da própria linha Received. Outras cópias, cópias ARC e qualquer uma que esteja entre as linhas do remetente podem ter sido adicionadas por qualquer pessoa (RFC 8601).

Uma aprovação prova o domínio, não as intenções dele: examp1e.com pode passar nas três para si mesmo.

Authentication-Results, dissecadonewsletter · depois o exemplo suspeito
Authentication-Results: mx.google.com;1

Quem verificouo authserv-id: o servidor do próprio provedor

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM: example.org assinoua chave dele fica em s1._domainkey.example.org

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

Uma segunda assinaturaa do próprio serviço de envio; não pode se alinhar a example.org

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF: autorizado a enviar por sendgrid.neto domínio do envelope (Return-Path), não o do From

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC: o domínio do From coincide com ②p=quarantine é o que example.org pede aos receptores que façam com as falhas

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001ContaMicrosoft 365 escreveu, acima da primeira linha Received que adicionou.

Limite de confiança

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100IgnoradoCita Microsoft, mas fica abaixo de toda linha Received: veio dentro da mensagem. Um receptor nunca escreve ali.
Abaixo da linha: os dois Authentication-Results do exemplo suspeito. A posição decide qual deles conta.

Este e-mail é verdadeiro ou falsificado?

Os cabeçalhos não dizem se uma oferta é honesta, mas mostram se o domínio do From realmente enviou a mensagem e se ele imita o de outra pessoa. Comece pelo veredito que o seu provedor escreveu e depois procure estes sinais.

Nenhum deles prova phishing por si só, e várias diferenças comuns são normais. A Microsoft observa que um domínio parecido pode passar em SPF, DKIM e DMARC se o dono o configurou (Microsoft).

  • Um domínio parecido no FromAlta

    paypa1-billing.examplevspaypal.com

    Um dígito ou uma letra semelhante trocados. Pode passar em SPF, DKIM e DMARC para si mesmo.

  • Letras de outro alfabetoAlta

    xn--pypal-4ve.exampleaparece comopаypal.example

    O а é cirílico. Os cabeçalhos guardam a forma xn-- (punycode), que entrega a diferença.

  • Seu provedor diz failAlta

    compauth=fail reason=001 · spf=softfail

    O receptor não conseguiu ligar o domínio do From ao servidor que enviou.

  • Um nome que traz outro endereçoMédia

    "accounts@example.com" <notice@mailer.example>

    Os apps mostram o nome, não o endereço. O remetente real está entre os colchetes.

  • O veredito do próprio filtroMédia

    CAT:PHSH · dest:J · SFTY:9.25

    A Microsoft classificou como phishing e enviou para Junk; 9.25 é a dica de primeiro contato.

  • Resultados pass abaixo da linhaMédia

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    Escritos abaixo de toda linha Received, então foi o remetente quem escreveu. Só valem os do seu provedor.

Normal, não são sinais de alerta por si sós

  • O Return-Path é diferente do From

    sendgrid.netvsexample.org

    Serviços de e-mail enviam por você; o DKIM garante a correspondência.

  • O Reply-To é diferente do From

    Reply-To: support@example.org

    As respostas vão para uma central de ajuda. Só vale uma olhada se esse domínio imitar outro.

  • Uma hora que anda para trás

    09:47:12 → 09:47:11 (−1 s)

    Cada servidor carimba o próprio relógio, e os relógios podem diferir por um segundo ou mais.

  • Um servidor em outro país

    CTRY:US · 209.85.208.54

    É onde o servidor está, não a pessoa. Os grandes provedores enviam de todo lugar.

Sinais do exemplo suspeito e de variações inventadas. Nenhum prova phishing por si só.

Por que meu e-mail atrasou?

Subtraia cada hora do Received da que está acima dele, em UTC. A maior lacuna mostra onde a mensagem esperou. Uma lacuna de 30 minutos ou mais é compatível com uma nova tentativa (a RFC 5321 sugere esperar pelo menos 30 minutos).

O cabeçalho Date vem do dispositivo do remetente, então o tempo do Date até o primeiro servidor inclui um relógio atrasado ou um rascunho escrito muito antes do envio. Os horários também podem recuar um segundo quando os relógios de dois servidores diferem.

Nenhum padrão diz quanto tempo é demais.

O exemplo suspeitohoras em UTC
Cabeçalho Date09:05:44 UTC
+7 s
mail.paypa1-billing.example09:05:51 · primeiro servidor
41 min 21 s≥ 30 min: nova tentativa

Microsoft 365

  • 09:47:12borda, primeira linha
  • 09:47:11interno · −1 s
  • 09:47:13servidor de caixa de entrada
  1. 09:05:44Cabeçalho Dateo relógio do remetente
  2. +7 s
  3. 09:05:51mail.paypa1-billing.exampleprimeiro servidor
  4. 41 min 21 s≥ 30 min: compatível com uma nova tentativa
  5. 09:47:12borda de Microsoft 365primeira linha que Microsoft escreveu
  6. −1 sos relógios diferem
  7. 09:47:11Microsoft interno
  8. +2 s
  9. 09:47:13servidor de caixa de entrada de Microsoft
a partir do cabeçalho Date
41 min 29 s
a partir do primeiro servidor
41 min 22 s
O exemplo da newsletter · 44 sonde o tempo foi parar
  • Date → primeiro servidor 6 s
  • até o SendGrid 2,9 s
  • Filtro do SendGrid 0,6 s
  • SendGrid → Google, a maior lacuna 33 s
  • dentro do Google 1 s

Cabeçalhos de spam do Microsoft 365 e do Gmail, decodificados

O Microsoft 365 escreve o veredito do filtro em X-Forefront-Antispam-Report: CAT é o veredito, SFV é como a filtragem de spam decidiu, e X-Microsoft-Antispam-Mailbox-Delivery diz para qual pasta a mensagem foi.

O SCL ainda é escrito, mas a Microsoft diz que ele não decide mais nada no Microsoft 365: leia o CAT. O BCL avalia o e-mail em massa pelas reclamações, de 0 a 9, e o limite da sua política (7 por padrão) decide (Microsoft).

O Gmail não escreve nenhum veredito de spam documentado. Servidores com SpamAssassin adicionam X-Spam-Status com a pontuação, o limite e as regras acionadas.

X-Forefront-Antispam-Reporto exemplo suspeito
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH o veredito: phishing (SPM spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM a filtragem de spam marcou como spam (NSPM: não é spam)
  3. 3SCL:5 uma entrada da filtragem, não a decisão no Microsoft 365
  4. 4SFTY:9.25 a dica de segurança de primeiro contato foi mostrada
  5. 5IPV:NLI o IP não está em nenhuma lista de reputação
  6. 6DIR:INB entrada; SFS e ARA são diagnósticos internos da Microsoft

Nível de reclamações de envio em massaBCL:0

01–3 poucas4–7 variadas8–9 muitas

Limites 5 strict, 6 standard, 7 padrão: igual ou acima, é envio em massa.

Para onde foidest:J

Junk EmailX-Microsoft-Antispam-Mailbox-Delivery

dest:I é a Inbox. ucf, jmr e ENG são internos.

Gmail e SpamAssassin

O Gmail não escreve nenhum veredito de spam documentado: X-Received, X-Google-Smtp-Source e X-Gm-* são internos.

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin: spam só na pontuação exigida ou acima dela.

Todos os valores do exemplo suspeito, lidos com as tabelas de cabeçalhos antispam da Microsoft.

Onde fica o cabeçalho do email e como pegá-lo no Gmail, Outlook, Apple Mail e outros

Para pegar o cabeçalho, copie os cabeçalhos completos, ou a mensagem original inteira, em um computador ou em um navegador. Depois cole-os acima, ou salve a mensagem como arquivo .eml e envie-o.

Cada app esconde o cabeçalho em um menu diferente. Escolha o seu: os passos seguem a página de ajuda de cada provedor.

  1. 1Abra a mensagem
  2. 2Mais ⋮
  3. 3Mostrar original
  4. 4Copiar para a área de transferência

Fonte: support.google.com/mail/answer/29436

No celular? Os apps do Gmail, do Outlook e do Apple Mail não mostram os cabeçalhos completos. Abra a mensagem em um navegador (Gmail, Outlook na web) ou em um app de computador, ou encaminhe-a como anexo e envie o .eml aqui.

Como rastrear um e-mail, e o que um IP revela e não revela

Para rastrear um e-mail, pegue o endereço from da primeira linha Received que o seu provedor escreveu: o servidor que entregou a mensagem. Descubra quem é o dono dele e você saberá de quem era aquele servidor, que pode ser um encaminhador e não o remetente original.

Os cabeçalhos mostram servidores de e-mail, e só às vezes a rede do próprio remetente, em X-Originating-IP.

Mesmo esse endereço aponta para uma rede e, mais ou menos, um país, nunca para uma pessoa ou uma rua.

O exemplo Gmail → Outlookconsultado a partir do seu navegador
Computador da Ananão está nos cabeçalhos
209.85.208.54mail-ed1-f54.google.com
Microsoft 365primeira linha Received que ele escreveu

O que 209.85.208.54 revela

Proprietário
Google LLC · 209.85.128.0/17 (ARIN)
País
Estados Unidos, onde o servidor está
Função
um servidor de envio do Gmail, o que o SPF verificou

O que ele não revela

Quem
A Ana, ou qualquer outra pessoa em example.net
Onde
a cidade ou a rua dela
Dispositivo
o computador ou o celular dela
O analisador consulta só os endereços públicos dos servidores, no registro deles, e mostra exatamente o que perguntou.

Cabeçalhos de e-mail: perguntas e respostas

Como pegar o cabeçalho do email e analisá-lo?

Copie os cabeçalhos completos no seu app de e-mail, cole-os acima e selecione Analisar cabeçalhos. A análise lê tudo de baixo para cima: o veredito que o seu provedor escreveu, o caminho servidor por servidor com o atraso em cada um, e os achados com as evidências.

É seguro colar cabeçalhos de e-mail aqui?

Os cabeçalhos são lidos no seu navegador e nunca são enviados para nós. Só os IPs públicos dos servidores são consultados: o proprietário nos registros (RDAP, consultado pelo seu navegador) e o país a partir de arquivos DB-IP baixados do nosso próprio site, então o nosso servidor vê qual faixa de endereços foi consultada. O domínio do remetente só é consultado no dns.google se você pedir. Os cabeçalhos contêm endereços e nomes de servidores, então compartilhe-os com cuidado.

Os cabeçalhos de e-mail podem ser falsificados?

Sim: tudo o que foi escrito antes de o seu provedor receber a mensagem. Cada servidor adiciona a sua linha por cima, então o remetente pode colocar linhas Received falsas abaixo e até um Authentication-Results falso que diz pass. As linhas do seu provedor no topo, e os resultados que ele escreveu ao lado delas, são a parte em que você pode confiar; o analisador mostra o resto como alegações.

Como saber se um e-mail é falso?

Comece pelo Authentication-Results do seu provedor: um DMARC fail, ou um compauth fail no Microsoft 365, significa que o domínio do From não foi confirmado. Depois leia o próprio domínio: um domínio parecido, como paypa1-billing.example, pode passar em todas as verificações para si mesmo. Por fim, veja para onde vão as respostas e qual servidor entregou a mensagem; o analisador lista cada achado com as evidências.

Onde fica o cabeçalho do email com o IP do remetente?

Dá para achar o servidor que entregou a mensagem ao seu provedor: o endereço from na primeira linha Received do seu provedor, o que o SPF verificou. Em geral é um servidor de e-mail, não o computador da pessoa. Alguns provedores também adicionam X-Originating-IP, em geral o dispositivo ou a rede do remetente, e até ele aponta para uma rede e um país aproximado, nunca para uma pessoa.

Por que o Gmail não mostra o endereço IP do remetente?

As mensagens enviadas pela web e pelos apps do Gmail em geral trazem só servidores do Google: a primeira linha Received não tem a parte from, então o endereço do próprio remetente não está nos cabeçalhos. O endereço que você consegue ver pertence ao servidor do Google que repassou a mensagem, o que o SPF verificou, então uma consulta mostra o Google como proprietário, não a rede do remetente.

O SPF passou, então por que o DMARC falhou?

O SPF verifica o domínio do envelope (Return-Path), que pode ser diferente do From que você vê. O DMARC exige que SPF ou DKIM passe para um domínio que coincida com o From, exatamente ou dentro da mesma organização; se o domínio aprovado for de outra pessoa, como o domínio de retorno de um serviço de e-mail, o DMARC falha. Uma assinatura DKIM do domínio do From passa no DMARC por si só.

O que significa um atraso negativo entre os saltos?

Um servidor posterior carimbou uma hora anterior à do servidor que veio antes dele. Cada servidor escreve a hora do próprio relógio, e esses relógios podem diferir, então o analisador mostra uma diferença de relógio, não um atraso. As horas das linhas abaixo das que o seu provedor escreveu também podem ser forjadas, então trate a ordem e os intervalos delas como alegações.

O que significam SCL e BCL?

Os dois são pontuações do Microsoft 365 nos seus cabeçalhos antispam. O BCL avalia o e-mail em massa pelo nível de reclamações, de 0 (não é de um remetente em massa) a 9. O SCL ainda é escrito, mas no Microsoft 365 é uma entrada da filtragem, não a decisão: o CAT traz o veredito, e o SFV diz como a filtragem de spam tratou a mensagem.

Os cabeçalhos de e-mail mostram os destinatários em BCC?

Não. Cópias ocultas nunca são escritas nos cabeçalhos: o servidor de envio as entrega a partir do envelope, e as linhas To e Cc mostram só os destinatários visíveis. Uma cláusula for em uma linha Received pode citar um destinatário, e por isso se pede aos servidores que a usem com cautela. O Delivered-To também pode mostrar a caixa de correio que a mensagem alcançou.

Este analisador de cabeçalho é o mesmo Message Header Analyzer da Microsoft?

Não. O Message Header Analyzer da Microsoft é um suplemento do Outlook e uma página web que decodifica os cabeçalhos de uma mensagem. Este lê os mesmos cabeçalhos da Microsoft e também os do Gmail, os do SpamAssassin e o rastro de cada salto, decide em quais resultados confiar pela posição em que estão e roda inteiramente no seu navegador.

Por que há vários cabeçalhos Authentication-Results?

Todo servidor que verifica uma mensagem pode adicionar um, e os remetentes podem adicionar falsos, então uma mensagem muitas vezes traz vários. Só vale o que o seu provedor escreveu: no topo, ao lado da própria linha Received, citando o próprio servidor. Os ARC-Authentication-Results são resultados que um encaminhador selou, para que o próximo servidor veja o que passou antes de o encaminhamento alterar a mensagem.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta

Mais ferramentas de e-mail