Como usar
- Abra a mensagem no seu programa de e-mail, encontre os cabeçalhos originais ou completos e copie-os da primeira linha até a linha em branco.
- Cole-os em Cabeçalhos brutos. A página os lê no seu navegador.
- Leia Saltos em ordem do primeiro salto até o último, e a coluna Atraso para o tempo de cada salto.
- Leia Resultado do SPF, Resultado do DKIM e Resultado do DMARC. Uma aprovação aparece em verde; qualquer outro resultado aparece em vermelho.
Como o e-mail registra o caminho
Cada servidor que trata uma mensagem acrescenta uma linha Received no topo dos cabeçalhos (RFC 5321, seção 4.4). A linha informa o host de onde ela veio (from), o host para o qual o e-mail foi passado (by), o protocolo (with) e uma data depois do ponto e vírgula (RFC 5322, seção 3.6.7). Lidas de baixo para cima, as linhas dão o caminho em ordem.
- O atraso de um salto é o seu horário menos o horário do salto anterior, lido de baixo para cima.
- O relógio de um servidor pode estar errado, então um atraso negativo ou longo diz tanto sobre o relógio quanto sobre a rede.
Endereços e alinhamento
From é o endereço do autor. Return-Path é para onde vão as devoluções, e é o endereço que o SPF verifica (RFC 5322, seções 3.6.2 e 3.6.7). O DMARC compara o domínio do From com o domínio que o SPF ou o DKIM verificou. No alinhamento relaxado, o padrão, os dois precisam apenas compartilhar um domínio organizacional; no alinhamento estrito, precisam ser o mesmo nome (RFC 7489, seções 3.1 e 3.1.1). Reply-To é para onde vão as respostas quando está definido (RFC 5322, seção 3.6.2).
Resultados de autenticação
Um servidor receptor registra as suas verificações em um cabeçalho Authentication-Results. A primeira palavra é o authserv-id desse servidor, e cada resultado é um método com um valor, como spf=pass, dkim=pass ou dmarc=pass (RFC 8601, seções 2.2 e 2.7). Received-SPF é o cabeçalho mais antigo que registra uma verificação de SPF (RFC 7208, seção 9.1).
Exemplo: uma mensagem por três servidores
Os cabeçalhos padrão mostram uma mensagem de client.example.net que passou por relay.example.net e mx.example.org antes de chegar a mail.example.net. Lidas de baixo para cima, as três linhas Received têm os horários 09:59:21, 10:00:03 e 10:02:14, então o segundo salto levou 42 segundos e o terceiro 2 min 11 s.
O cabeçalho Authentication-Results informa spf=pass, dkim=pass e dmarc=pass para example.net. As respostas vão para [email protected], outro domínio, que a página marca porque uma resposta que sai do domínio do remetente merece verificação.
| Medida | Valor |
|---|---|
| Linhas Received | 3 |
| Tempo do primeiro ao último salto | 2 min 53 s |
| SPF | pass (example.net) |
| Reply-To | As respostas vão para example.org, e não para example.net. Verifique se isso é intencional (RFC 5322, seção 3.6.2). |
Perguntas frequentes
Por que os saltos aparecem na ordem inversa das linhas Received?
Cada servidor coloca a sua linha Received no topo, então o salto mais recente vem primeiro nos cabeçalhos (RFC 5321, seção 4.4). A página as inverte, de modo que a primeira linha é o servidor de onde o e-mail saiu.
Posso confiar nas linhas Received?
Cada servidor escreve a sua própria linha, mas os nomes e endereços nela são o que aquele servidor informou, e o remetente pode acrescentar linhas próprias. As linhas do topo foram acrescentadas mais recentemente, pelos servidores mais próximos de você, e merecem mais atenção.
O que significa um atraso negativo?
Um salto com horário anterior ao do salto antes dele significa que os relógios de dois servidores não batem, ou que um fuso horário foi lido de forma errada. É sinal de erro de relógio, não de uma rede mais rápida.
O que é o Authentication-Results?
É um cabeçalho que um servidor receptor acrescenta para dizer o que verificou, como SPF, DKIM e DMARC, e o resultado de cada verificação (RFC 8601). A primeira palavra nomeia esse servidor, e só o cabeçalho do seu próprio servidor receptor deve ser confiável (seção 2.5).
Por que o domínio do Reply-To importa?
As respostas vão para o Reply-To quando ele está definido, e para o From caso contrário (RFC 5322, seção 3.6.2). Se ele indicar outro domínio, as respostas saem do domínio de onde a mensagem veio. Isso não é errado em si, mas vale a pena verificar.
Esta ferramenta envia os meus cabeçalhos para algum lugar?
Não. Os cabeçalhos são lidos no seu navegador. Nada é enviado nem guardado.
Fontes
- RFC 5322: Internet Message Format (em inglês)
- RFC 5321: Simple Mail Transfer Protocol, informações de rastreamento (em inglês)
- RFC 8601: Message Header Field for Indicating Message Authentication Status (em inglês)
- RFC 7208: Sender Policy Framework (SPF) (em inglês)
- RFC 7489: DMARC (em inglês)
Números e texto verificados pela última vez em terça-feira, 10 de novembro de 2026.