Analisador de Cabeçalhos de E-mail

O que faz

O Analisador de Cabeçalhos de E-mail faz o parsing dos cabeçalhos brutos de uma mensagem de e-mail (RFC 5322) e os transforma num relatório forense legível: um banner de veredito que condensa todos os achados numa avaliação de relance (indicadores de spoofing encontrados / sinais suspeitos / limpo), uma linha do tempo de entrega hop a hop de cada servidor Received por onde a mensagem passou, com o atraso entre hops, os vereditos de autenticação SPF / DKIM / DMARC e a lista completa de anomalias — sinais de spoofing como um endereço From que não corresponde ao Return-Path, um Reply-To apontando para algum lugar inesperado, strings de mailer suspeitas ou timestamps que andam para trás.

O layout é dividido: entrada de cabeçalhos brutos à esquerda, o relatório de análise ao vivo num painel fixo à direita que permanece visível enquanto você rola os achados. É a ferramenta que você busca quando uma mensagem parece phishing e você quer evidência em vez de palpite.

Como usar

1. Obtenha os cabeçalhos brutos: no Gmail, abra a mensagem → ⋮ → Show original, então copie tudo acima do corpo da mensagem. Outlook: File → Properties → Internet headers.
2. Cole-os em Raw email headers (ou pressione Sample para carregar uma mensagem de demonstração embutida).
3. Pressione Analyze headers. O relatório aparece à direita, sob o banner de veredito.
4. Leia primeiro o banner de veredito: vermelho (perigo) = pelo menos um indicador crítico de spoofing, âmbar = apenas avisos, verde = nenhuma anomalia. As contagens de severidade ficam à direita do banner (critical × 1, warnings × 2, notices × 1).
5. Percorra as seções: Delivery path (hop mais antigo primeiro, badges de atraso coloridos por código), Authentication (linhas SPF/DKIM/DMARC), Anomalies (cada achado com sua evidência) e All headers (a tabela completa de cabeçalhos desdobrados).
6. Pressione Copy share link para obter uma URL que carrega sua entrada exata — quem a abrir vê a mesma análise.

Lendo as linhas de autenticação. Cada linha mostra o nome do mecanismo, sua palavra de resultado e a cláusula de evidência de onde ele veio:

• SPF — o IP do servidor enviador recebeu autorização do domínio do envelope (smtp.mailfrom)? pass = autorizado; softfail = não autorizado, mas o domínio apenas pede que os receptores o tratem como suspeito; fail = explicitamente não autorizado, spoofing provável; neutral = o domínio não faz nenhuma afirmação; none = nenhuma política publicada; temperror = falha DNS transitória; permerror = registro quebrado/malformado. O texto extra da linha mostra o endereço de envelope que foi verificado.
• DKIM — a mensagem foi assinada criptograficamente, e a assinatura verifica? pass = assinatura válida (a linha mostra o selector assinante e, quando publicado, o domínio assinante de header.d); fail = assinatura presente mas quebrada — cabeçalhos ou corpo foram modificados em trânsito; none = não assinada; temperror/permerror = a chave pública não pôde ser recuperada. A linha de detalhe mostra a cláusula bruta, ex. dkim=pass header.s=sel2026 header.b=AbCdEf.
• DMARC — a política do domínio visível em From: aceitou esta mensagem? pass = alinhamento e as verificações subjacentes satisfeitas (a linha mostra o domínio header.from avaliado e a política p= do domínio: none, quarantine ou reject); fail = a mensagem alega uma identidade cuja própria política não a aceita; none = o domínio From não publica registro DMARC.

Uma ressalva crucial que o exemplo demonstra: os três podem passar e a mensagem ainda pode ser uma isca de phishing. SPF/DKIM/DMARC verificam que o domínio enviador realmente enviou esta mensagem — não que o remetente é confiável, nem que o Reply-To vai para onde você pensa. É por isso que a lista de anomalias importa mesmo num painel de autenticação totalmente “verde”.

Lendo a cadeia de Received. Servidores de e-mail prefixam cada cabeçalho Received, então a ferramenta os interpreta de baixo para cima: o hop 1 é o servidor de origem, o último hop é a sua caixa de entrada. Entre hops consecutivos ela mostra um badge de atraso — o tempo decorrido calculado a partir dos timestamps dos dois hops:

• verde, abaixo de 1 segundo (renderizado em milissegundos): retransmissão normal.
• âmbar, 1–60 s: alguma enfileiramento ou greylisting — normalmente tudo bem.
• laranja, acima de 60 s: retransmissão lenta, limitação do provedor de e-mail, ou uma mensagem que ficou parada numa fila.
• cinza “unknown delay”: o hop não tem timestamp interpretável, então esse trecho não pode ser medido (também levantado como anomalia informativa).

Timestamps que andam para trás (hop N datado antes do hop N−1) ganham seu próprio aviso: ou os relógios de dois servidores discordam, ou alguém forjou um cabeçalho Received.

Exemplos

Carregue o Sample embutido e pressione Analyze headers para ver todos os recursos de uma vez. Saída verificada do exemplo:

• Delivery path — 3 hops, o mais antigo primeiro: sender.evil.example → mail.relay.example (ESMTP), depois mail-sor-f41.google.com → mx.google.com (ESMTPS, +7.0 s), depois mx.google.com (SMTP, +3.0 s).
• Authentication — tudo pass: SPF pass para billing@legit-shop.com, DKIM pass com seletor sel2026, DMARC pass com política quarantine para legit-shop.com.
• Banner de veredito — vermelho: critical × 1, warnings × 2, porque as anomalias são:

From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2

→ Crítico: Return-Path (bounce@evil.example) não corresponde ao From (support@legit-shop.com) — o remetente do envelope difere do remetente exibido. Mais avisos para o Reply-To desviado e o X-Mailer de envio em massa. A autenticação passou porque legit-shop.com genuinamente enviou a mensagem — mas ela ainda foi construída para parecer o que não é.

Uma mensagem limpa (envelope corresponde ao From, assinada, autenticada):

Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>

→ Veredito verde, “No spoofing indicators found”, zero anomalias.

Um painel reprovado — os três mecanismos renderizam em vermelho:

Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example

→ SPF softfail para spoof@wrong.example, DKIM fail (seletor sel1), DMARC fail com política reject — uma mensagem que um receptor estrito deveria ter rejeitado.

Um hop forjado — timestamps que andam para trás:

Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700

→ Aviso: Hop 2 tem timestamp 10.0s ANTES do hop 1 — defasagem de relógio entre servidores ou cabeçalho Received forjado.

Bom saber

Todos os sinais que o analisador verifica (severidade entre parênteses):

1. Return-Path diferente do From (crítico) — o remetente do envelope (Return-Path, para onde os bounces vão) usa um endereço diferente do From exibido. Spoofing clássico; também comum em retransmissão legítima de listas de e-mail.
2. Reply-To difere do From (aviso) — respostas seriam desviadas para um terceiro endereço. Legítimo para mesas de suporte, condenável quando o From é o seu banco.
3. String de mailer suspeita (aviso) — X-Mailer ou User-Agent contém um token associado a ferramentas de envio em massa: bulk, mass mail, massmail, storm, flood, bomber, grabber, harvest, spambot, stealth, anonymous, dark, crack (casados sem distinção de maiúsculas, como substrings).
4. Hop sem timestamp interpretável (info) — o atraso desse trecho não pode ser calculado; exibido como um badge “unknown delay”.
5. Tempo andando para trás (aviso) — um hop com timestamp anterior ao do hop precedente: defasagem de relógio ou cabeçalho Received forjado.
6. Sem cabeçalho Authentication-Results (info) — o status SPF/DKIM/DMARC não pode ser verificado desta mensagem de forma alguma.

Detalhes do parser que valem saber:

• Privado: todo o parsing é 100% no cliente — seus cabeçalhos nunca saem do navegador.
• Cabeçalhos são desdobrados conforme a RFC 5322 (linhas de continuação começam com espaço em branco); o parsing para na primeira linha em branco (o separador do corpo); linhas de lixo que não são cabeçalho são ignoradas.
• Quando uma mensagem carrega vários cabeçalhos Authentication-Results, o primeiro veredito de cada mecanismo vence; o restante é ignorado.
• Timestamps de hop são lidos após o último ; de cada linha Received (com fallback para o primeiro token com cara de data), e comentários de zona ao final, como (PDT), são ignorados.
• Uma peça ausente é relatada, nunca adivinhada: atrasos desconhecidos, autenticação não verificável e lacunas na cadeia aparecem como achados explícitos em vez de espaços em branco silenciosos.
• Ferramentas relacionadas: PII Redactor, Defang / Refang,

  Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.

  .