# Analisador de cabeçalho de e-mail

Cole os cabeçalhos brutos de um e-mail para ver quem o enviou, se SPF, DKIM e DMARC passaram e quanto tempo cada servidor segurou a mensagem no caminho. Os cabeçalhos são analisados no seu navegador e nunca são enviados.

## Resposta curta

Cada servidor de e-mail que processa uma mensagem acrescenta uma linha Received no topo dos cabeçalhos (RFC 5321, seção 4.4), então a cadeia é lida de baixo para cima: a linha mais baixa é o primeiro salto. O servidor que recebe a mensagem registra as verificações de SPF, DKIM e DMARC em Authentication-Results (RFC 8601), e o DMARC passa quando o SPF ou o DKIM passa para um domínio alinhado com o endereço From (RFC 9989, que substituiu a RFC 7489 em maio de 2026).

### Como é obtido

O texto colado é desdobrado (as linhas de continuação são juntadas) e lido como campos de cabeçalho até a primeira linha em branco. As linhas Received são postas da mais antiga para a mais recente, e o horário depois de cada ponto e vírgula é interpretado para calcular o atraso entre os saltos. Authentication-Results e Received-SPF são lidos para obter os resultados de spf, dkim e dmarc; todos os resultados são mantidos, então duas assinaturas DKIM, uma que passa e outra que falha, aparecem como "pass, fail". O alinhamento é verificado entre o domínio do From e os domínios do `d=` do DKIM e do Return-Path. Nada sai do seu navegador.

### Exemplo prático

O exemplo embutido tem duas linhas Received com os horários 14:02:09 e 14:02:11 (+0000), então mostra 2 saltos e um total de 2,0 s. A linha Authentication-Results dele registra dkim=pass para shop.example, spf=pass e dmarc=pass, e o domínio do DKIM, shop.example, é o mesmo do From, então está alinhado.

### Limites

- Os resultados são lidos como o servidor que recebeu a mensagem os escreveu; a página não consulta o DNS nem verifica de novo as assinaturas DKIM.
- Qualquer servidor, inclusive o do remetente, pode acrescentar uma linha Received falsa; só as linhas adicionadas pelo seu próprio provedor são confiáveis.
- O alinhamento relaxado entre subdomínios irmãos exige a Public Suffix List, que a página não carrega, por isso esses pares aparecem como "pode estar alinhado".

### Fontes

- [RFC 5321, section 4.4: Trace Information](https://www.rfc-editor.org/rfc/rfc5321#section-4.4): como as linhas Received são adicionadas.
- [RFC 8601: Authentication-Results Header Field](https://www.rfc-editor.org/rfc/rfc8601): como as verificações são registradas.
- [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208): os resultados do SPF.
- [RFC 6376: DomainKeys Identified Mail (DKIM)](https://www.rfc-editor.org/rfc/rfc6376): as assinaturas DKIM e o d=.
- [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989): o alinhamento e o resultado do DMARC; torna obsoleta a RFC 7489.

## O que a ferramenta faz

Cada servidor de e-mail que processa uma mensagem acrescenta linhas no topo dos cabeçalhos, e o servidor que finalmente a aceita registra se o remetente passou nas verificações. O resultado é um bloco de texto longo, quebrado em várias linhas, difícil de ler a olho. Este analisador interpreta os cabeçalhos brutos de um e-mail e os organiza em cinco partes:

- **Resumo**: From, To, Subject, Date, Message-ID, Return-Path e Reply-To.
- **Autenticação**: os vereditos de SPF, DKIM e DMARC (pass, fail, none etc.) dos cabeçalhos Authentication-Results e Received-SPF, além do domínio (`d=`) e do seletor (`s=`) de cada cabeçalho DKIM-Signature.
- **Alinhamento**: se o domínio do From coincide com o domínio `d=` do DKIM e com o domínio do Return-Path.
- **Cadeia Received**: cada salto numerado do mais antigo para o mais recente, com os hosts from e by, o protocolo (como ESMTPS), o horário e o atraso desde o salto anterior, além do tempo total de entrega.
- **Avisos**: um Reply-To diferente do From, saltos com horários fora de ordem ou diferença entre relógios, e resultados de autenticação ausentes.

A análise é feita por JavaScript no seu navegador. Nada é enviado para lugar nenhum, e, depois de carregada, a página continua funcionando com a rede desconectada. A ferramenta não verifica assinaturas DKIM criptograficamente nem consulta o DNS; ela mostra o que os servidores que receberam a mensagem escreveram nos cabeçalhos.

## Como usar

1. Abra o código-fonte bruto da mensagem. No Gmail, use o menu de três pontos ao lado de Responder e escolha Mostrar original. No Outlook clássico para Windows, abra a mensagem numa janela própria, escolha Arquivo e depois Propriedades, e copie o conteúdo da caixa Cabeçalhos de Internet. No Outlook na Web e no novo Outlook, use o menu de três pontos, depois Exibir e então Exibir detalhes da mensagem. No Apple Mail, escolha Visualizar, depois Mensagem e então Código-Fonte Bruto.
2. Copie o bloco de cabeçalhos: tudo até a primeira linha em branco. O corpo da mensagem, que vem abaixo, não é necessário.
3. Cole o bloco na caixa desta página.
4. Leia o resumo e os resultados de autenticação, depois os avisos e, por fim, a lista de saltos.

Encaminhar uma mensagem descarta os cabeçalhos originais, então trabalhe com a cópia que está na caixa de entrada de quem a recebeu, ou peça ao destinatário que a encaminhe *como anexo*.

## Casos de uso

- **Conferir uma mensagem suspeita.** Um pedido de pagamento de um fornecedor mostra `dmarc=fail`, um domínio `d=` do DKIM sem relação com o domínio do From e um Reply-To diferente. Isso basta para denunciar a mensagem em vez de responder.
- **Descobrir onde aconteceu um atraso.** Um e-mail de redefinição de senha chega com 40 minutos de atraso. A maioria dos saltos levou um ou dois segundos, mas um relay segurou a mensagem por 38 minutos, e isso mostra de quem é a fila que precisa ser investigada.
- **Testar o seu próprio domínio.** Depois de conectar um serviço de newsletter, envie um teste para você mesmo e confirme que SPF e DKIM passam e que o `d=` é o seu domínio, e não o domínio compartilhado do serviço.
- **Rastrear uma mensagem nos logs.** Passe ao administrador de e-mail o Message-ID e o horário em que o seu provedor aceitou a mensagem; os dois podem ser pesquisados nos logs de entrega.
- **Confirmar a criptografia no caminho.** ESMTPS num salto significa que aquele enlace usou TLS; ESMTP ou SMTP simples significa que não usou.

## Como ler a cadeia Received, e o que pode ser falsificado

Cada servidor coloca a sua linha Received acima das que já existem, então o salto mais recente fica no topo. Ler de baixo para cima acompanha a mensagem na ordem do tempo; a ferramenta inverte a ordem para você.

```
Received: from mx-out.shop.example (mx-out.shop.example [198.51.100.25])
        by mx1.recipient.example with ESMTPS id 4f2ac81e
        for <you@recipient.example>; Tue, 6 Oct 2026 14:02:11 +0000
Received: from app01.internal (app01.internal [10.0.4.7])
        by mx-out.shop.example with ESMTP id 91c0d3;
        Tue, 6 Oct 2026 14:02:09 +0000
```

A confiança depende de quem escreveu cada linha. Encontre o salto mais antigo adicionado pelo seu próprio provedor, aqui o registrado por `mx1.recipient.example`. Essa linha e tudo o que vem depois dela são confiáveis, e o endereço IP entre colchetes nela é a máquina que realmente entregou a mensagem. Tudo o que foi registrado antes, ou seja, abaixo dela no texto bruto, veio do lado do remetente e pode ser inventado, inclusive linhas Received falsas que sugerem outra origem. From, Reply-To, Subject, Date e Message-ID também são definidos pelo remetente.

Cada horário vem do relógio do próprio servidor. Um atraso alguns segundos abaixo de zero geralmente indica um relógio levemente errado. Intervalos longos indicam uma fila, uma nova tentativa depois de uma rejeição temporária ou uma mensagem retida para análise.

## O que SPF, DKIM e DMARC provam, cada um

**SPF** compara o endereço IP que se conecta com os servidores que um domínio lista no DNS. O domínio verificado é o remetente do envelope, que vira o Return-Path, e não o From visível. Um pass prova só que esse servidor pode enviar em nome do domínio do Return-Path. O encaminhamento costuma quebrar o SPF porque quem encaminha não está na lista.

**DKIM** é uma assinatura sobre o corpo e alguns cabeçalhos escolhidos. `d=` indica o domínio que assina, e `s=`, o seletor usado para encontrar a chave pública dele. Um pass significa que as partes assinadas não foram alteradas e que o domínio `d=` responde por elas. Não diz nada sobre o From, a menos que os domínios coincidam.

**DMARC** liga as duas verificações ao endereço que o leitor vê: passa quando o SPF ou o DKIM passa e o domínio aprovado está alinhado com o domínio do From. Uma mensagem pode passar no SPF e no DKIM com os domínios de um serviço de envio em massa enquanto a linha From mostra o nome de um banco, e mesmo assim o DMARC não vai passar.

```
Authentication-Results: mx1.recipient.example;
       dkim=pass header.d=shop.example header.s=s2026;
       spf=pass smtp.mailfrom=bounce.shop.example;
       dmarc=pass header.from=shop.example
```

No modo relaxado, que é o padrão do DMARC, `bounce.shop.example` está alinhado com `shop.example` porque os dois compartilham o mesmo domínio organizacional. Confira se o primeiro nome nesse cabeçalho é o servidor do seu provedor; um remetente pode inserir uma linha Authentication-Results falsa, e receptores cuidadosos removem essas linhas.

Por fim, olhe além do nome de exibição. Em `PayDesk Billing <billing@paydesk-help.example>`, a maioria dos apps de e-mail mostra só o nome amigável, mas as verificações acima tratam do endereço.

## Perguntas frequentes

**Os cabeçalhos que eu colo são enviados para o iseeu.cc?**

Não. Os cabeçalhos são analisados por JavaScript que roda no seu navegador e não são enviados para lugar nenhum. Para comprovar, desligue o Wi-Fi depois que esta página carregar e rode o analisador de novo: ele dá as mesmas respostas offline. Além disso, o iseeu.cc não guarda registros de endereços IP nem de consultas, não tem banco de dados de visitantes, não usa cookies e não mostra anúncios.

**Se aparece DKIM pass, a assinatura é válida?**

Significa que o servidor que recebeu a mensagem registrou pass quando ela chegou. Esta ferramenta não refaz a verificação criptográfica nem busca a chave pública no DNS; ela lê o veredito no cabeçalho Authentication-Results. Em geral é isso mesmo que você quer, porque os remetentes trocam as chaves, e uma assinatura verificada semanas depois pode falhar mesmo tendo sido válida na entrega.

**Por que o SPF falha num e-mail que eu sei que é legítimo?**

A causa mais comum é o encaminhamento. Quando uma mensagem é encaminhada ou passa por uma lista de e-mails, o servidor que a retransmite se conecta com o próprio endereço IP, que não está no registro SPF do remetente original. Um remetente que adiciona um novo serviço de e-mail sem atualizar o SPF tem o mesmo resultado. Se o DKIM ainda passar com um domínio alinhado ao From, o DMARC pode passar mesmo assim.

**Por que alguns saltos mostram atraso negativo?**

Cada servidor grava o horário do Received pelo próprio relógio, e esses relógios não estão perfeitamente sincronizados. Um salto que parece chegar um ou dois segundos antes do anterior geralmente indica que um dos relógios está um pouco errado. Saltos maiores para trás no lado do remetente da cadeia também podem significar que uma linha Received foi inventada. A ferramenta sinaliza horários fora de ordem e diferença entre relógios para você decidir qual é o caso.

**Como os cabeçalhos ajudam a identificar um e-mail de golpe (phishing)?**

Compare o nome de exibição com o endereço real do From e depois verifique se o DMARC passou e se o domínio do DKIM coincide com o domínio do From. Um Reply-To diferente do From é um sinal clássico, porque as respostas vão para o golpista mesmo quando a linha From parece correta. Veja também o primeiro salto adicionado pelo seu provedor: o IP de envio que aparece ali foi registrado pelo seu provedor, e não informado pelo remetente.

**Por que não aparece nenhum resultado de autenticação na minha mensagem?**

Nem todo sistema de recebimento grava um cabeçalho Authentication-Results. Alguns servidores de e-mail corporativos e configurações antigas não gravam, e mensagens trocadas entre usuários do mesmo servidor interno muitas vezes nem são verificadas. Cabeçalhos copiados de uma cópia encaminhada também perdem os resultados originais. Quando nada é encontrado, a ferramenta mostra um aviso, e o que sobra para analisar é a lista de saltos e os domínios dos cabeçalhos DKIM-Signature.

**O que significam ESMTP, ESMTPS e ESMTPSA num salto?**

Eles descrevem a conexão que um servidor recebeu. ESMTP é SMTP estendido sem criptografia. A RFC 3848 acrescentou as variantes: ESMTPS significa que o enlace usou TLS, ESMTPA que o cliente que enviou fez login, e ESMTPSA, as duas coisas. Cada rótulo vale só para aquele salto, então uma mensagem pode ir criptografada em alguns trechos e não em outros. LMTP aparece com frequência na última etapa de entrega interna.

A análise repete o que os servidores que receberam a mensagem escreveram nos cabeçalhos e aplica heurísticas simples. Ela não prova quem enviou uma mensagem; quando houver dinheiro ou credenciais em jogo, confirme por um canal em que você já confia.

## Ferramentas relacionadas

- [Consulta DNS](https://iseeu.cc/pt/consulta-dns/): Registros A, AAAA, MX, TXT, NS, CNAME, CAA e SOA via DNS sobre HTTPS.
- [Consulta Whois / RDAP](https://iseeu.cc/pt/whois/): Dados de registro de domínios, endereços IP e números de sistema autônomo.
- [Cabeçalhos de segurança](https://iseeu.cc/pt/cabecalhos-seguranca/): Busca os cabeçalhos de resposta de uma URL e avalia HSTS, CSP e os demais.
- [Conversor Punycode](https://iseeu.cc/pt/conversor-punycode/): Converte domínios com acentos ou outros alfabetos para a forma xn-- e de volta.
- [Qual é o meu IP?](https://iseeu.cc/pt/): Seu endereço IP, localização, rede, cabeçalhos, TLS e testes de vazamento em uma só página.

[Ver todas as ferramentas](https://iseeu.cc/pt/ferramentas/)

Última atualização: 2026-10-11

Página original: https://iseeu.cc/pt/analisador-cabecalho-email/