Como ler cabeçalhos de e-mail para resolver problemas de entrega

O cabeçalho de um e-mail é um registro escrito por cada servidor por onde a mensagem passou, com a entrada mais nova no topo. Para resolver problemas de entregabilidade, leia três coisas: a linha Authentication-Results que o seu próprio provedor de e-mail adicionou, a cadeia Received de baixo para cima para ver a rota e os atrasos, e os domínios de DKIM-Signature e Return-Path para conferir o alinhamento com o From.

Este post percorre linha por linha cabeçalhos reais e publicados. Se você está tentando descobrir por que uma mensagem específica caiu na pasta de spam do Gmail, comece pelo diagnóstico de spam no Gmail, que é mais curto, e volte aqui quando precisar entender o que uma linha significa.

Como obter o cabeçalho completo

Todos os principais clientes de e-mail mostram o cabeçalho bruto, normalmente numa opção chamada "Show original" (Mostrar original), "View source" (Ver código-fonte) ou "View message details" (Ver detalhes da mensagem).

• Gmail (web): abra a mensagem, clique em Mais ao lado de Responder e depois em Show original (Mostrar original). A página de ajuda do Google diz que o cabeçalho completo abre numa nova janela com um botão Copy to clipboard (Copiar para a área de transferência).
• Outlook e Apple Mail: os dois mostram o código-fonte na visualização da mensagem; o nome do menu muda conforme a versão, então procure "view message headers" na ajuda do seu cliente.

Copie sempre o cabeçalho do lado do destinatário. A cópia na sua pasta Enviados não passou pelos servidores de recebimento, então não tem as linhas Received deles nem o Authentication-Results do receptor, que são as linhas que importam.

A regra que torna os cabeçalhos legíveis

Cada servidor adiciona suas linhas no topo, então o cabeçalho se lê como uma pilha: o mais novo em cima, a origem embaixo.

Isso não é convenção, é o protocolo. A RFC 5321, seção 4.4 diz: "SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location." (Servidores SMTP DEVEM adicionar as linhas Received no início das mensagens; NÃO DEVEM mudar a ordem das linhas existentes nem inserir linhas Received em nenhum outro lugar.)

Duas consequências práticas:

1. Para seguir a rota, leia as linhas Received de baixo para cima.
2. As linhas perto do topo foram escritas pelo seu próprio provedor. As de baixo foram escritas por servidores que você nunca viu, e algumas podem ter sido escritas pelo remetente. A confiança diminui à medida que você desce.

Um cabeçalho real, comentado

O exemplo real mais limpo de um cabeçalho com vários saltos e resultados de autenticação está na própria especificação. Este é o Exemplo 5 da RFC 8601, Apêndice B.5, citado exatamente (a assinatura DKIM aparece cortada com ... no original):

Authentication-Results: example.com;
          dkim=pass (good signature) header.d=example.com
Received: from mail-router.example.com
              (mail-router.example.com [192.0.2.1])
          by auth-checker.example.com (8.11.6/8.11.6)
              with ESMTP id i7PK0sH7021929;
          Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
          t=1188964191; c=simple/simple; h=From:Date:To:Subject:
          Message-Id:Authentication-Results;
          bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
          b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
Authentication-Results: example.com;
          auth=pass (cram-md5) smtp.auth=sender@example.com;
          spf=fail smtp.mailfrom=example.com
Received: from dialup-1-2-3-4.example.net
              (dialup-1-2-3-4.example.net [192.0.2.200])
          by mail-router.example.com (8.11.6/8.11.6)
              with ESMTPA id g1G0r1kA003489;
          Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample

Leia a partir de baixo.

Ordem	Linha	O que ela diz
1	From, Date, Subject, Message-Id	Escritos pelo programa de e-mail do remetente. Todos são alegações, não fatos.
2	Received de baixo	mail-router.example.com aceitou a mensagem de um host de acesso discado em 192.0.2.200. ESMTPA significa que o remetente fez login com SMTP AUTH.
3	Authentication-Results de baixo	O roteador registrou que o SMTP AUTH passou e que o SPF falhou: a rede de acesso discado não estava listada no SPF de example.com.
4	DKIM-Signature	O roteador assinou a mensagem como d=example.com, seletor gatsby, e incluiu o Authentication-Results de baixo nos cabeçalhos assinados (h=).
5	Received de cima	auth-checker.example.com recebeu a mensagem do roteador em 192.0.2.1.
6	Authentication-Results de cima	O verificador conferiu a assinatura DKIM: pass.

A explicação da própria RFC bate com isso: o usuário era legítimo (autenticou com senha), o SPF falhou porque a rede de acesso discado não estava autorizada, e o DKIM passou porque o roteador assinou com uma chave que example.com publica.

Essa é a principal lição do exemplo, e ela vale diretamente para a entregabilidade de hoje: uma falha de SPF sozinha não significa que o e-mail é ilegítimo, e o DKIM é o que sobrevive ao trajeto.

Medindo atrasos pela cadeia Received

Cada linha Received termina com um carimbo de data e hora, então a diferença entre linhas consecutivas é quanto tempo cada salto levou.

A RFC 5321 pede que os servidores usem fusos explícitos como -0800, o que permite comparar entre fusos horários. Escrevemos um script curto para isso e o rodamos no exemplo da RFC acima. O script completo está abaixo.

import sys, re
from email import message_from_string
from email.utils import parsedate_to_datetime
msg = message_from_string(open(sys.argv[1]).read())
hops = msg.get_all("Received") or []
prev = None
for i, h in enumerate(reversed(hops), 1):
    h = " ".join(h.split())
    stamp = h.rsplit(";", 1)[-1].strip()
    try:
        when = parsedate_to_datetime(stamp)
    except Exception:
        when = None
    m = re.search(r"from (\S+).*?by (\S+)", h)
    gap = f"+{(when - prev).total_seconds():.0f}s" if when and prev else "-"
    print(f"hop {i}: {m.group(1) if m else '?'} -> {m.group(2) if m else '?'}  {stamp}  {gap}")
    prev = when or prev

Saída, executada em 1º de outubro de 2026 (python3 hops.py header.txt):

hop 1: dialup-1-2-3-4.example.net -> mail-router.example.com  Fri, Feb 15 2002 17:19:07 -0800  -
hop 2: mail-router.example.com -> auth-checker.example.com  Fri, Feb 15 2002 17:19:22 -0800  +15s

O salto entre os dois servidores levou 15 segundos. O intervalo maior está entre o cabeçalho Date, 16:54:30, e a primeira linha Received, 17:19:07: cerca de 25 minutos antes de qualquer servidor ver a mensagem. O Date é definido pelo software do remetente, então um intervalo ali aponta para o lado do remetente (uma caixa de saída na fila, um envio agendado ou um relógio errado), não para algum relay.

Se você prefere não rodar código, a ferramenta Messageheader do Google faz a mesma conta: cole um cabeçalho e ela identifica atrasos de entrega e a origem aproximada.

Lendo o Authentication-Results do jeito certo

O Authentication-Results registra cada verificação como método=resultado, seguido da identidade que foi verificada. É a linha mais útil do cabeçalho e a mais mal interpretada.

O formato, segundo a RFC 8601, é:

Authentication-Results: <authserv-id>; <method>=<result> [reason] <ptype>.<property>=<value>

• authserv-id é quem fez a verificação, por exemplo mx.google.com.
• method=result é a verificação e o resultado: spf=pass, dkim=fail, dmarc=pass.
• ptype.property diz qual identidade foi verificada: smtp.mailfrom (o remetente do envelope), header.d ou header.i (o domínio que assina com DKIM), header.from (o domínio visível no From).
• Tudo o que está entre parênteses é um comentário em texto livre, e cada receptor escreve de um jeito.

Os resultados possíveis que a RFC define para SPF são none, pass, fail, softfail, neutral, temperror, permerror e policy; o DKIM usa none, pass, fail, policy, neutral, temperror e permerror.

Confie só no que o seu provedor escreveu

A RFC 8601 deixa claro que esse cabeçalho só deve ser levado em conta quando vem de um servidor dentro do seu próprio limite administrativo, e que um servidor em conformidade deve apagar cópias que dizem vir dele mas chegam de fora. Na prática: use o Authentication-Results mais alto cujo authserv-id seja o seu próprio provedor. Qualquer cópia mais abaixo foi escrita por outra pessoa, possivelmente o remetente.

Um exemplo real do Gmail, conferido no DNS

A Valimail publicou este cabeçalho de uma mensagem recebida no Gmail (fonte):

Authentication-Results: mx.google.com;
       dkim=pass header.i=@valimail.com header.s=google2048 header.b=Z8L6tjHb;
       spf=pass (google.com: domain of [redacted]@valimail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=[redacted]@valimail.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=valimail.com

Cada afirmação nele pode ser conferida no seu próprio terminal. Fizemos isso em 1º de outubro de 2026:

O cabeçalho diz	Comando	O que o DNS retornou
Seletor DKIM google2048 em valimail.com	dig +short TXT google2048._domainkey.valimail.com	Um registro de chave começando com "v=DKIM1; k=rsa; p=MIIBIjAN..."
Política DMARC p=REJECT	dig +short TXT _dmarc.valimail.com	"v=DMARC1; p=reject; rua=..."
Enviado de 209.85.220.41	dig +short -x 209.85.220.41	mail-sor-f41.google.com.

Ou seja, o seletor citado em s= existe, a política que o Gmail informou bate com o registro publicado, e o IP de envio é da infraestrutura de saída do próprio Google. Vale criar o hábito dessa conferência: o cabeçalho diz o que o receptor concluiu, e o DNS diz se essa conclusão ainda vale hoje. O nosso verificador de DKIM e o verificador de DMARC fazem as mesmas consultas sem terminal.

Alinhamento: a verificação que você faz no olho

O DMARC compara o domínio de header.from com os domínios que passaram no SPF e no DKIM. Pelo menos um precisa corresponder à organização do domínio do From.

No exemplo do Gmail os três são valimail.com, então o DMARC passa por qualquer uma das verificações. A falha comum, por outro lado, fica assim:

Identidade	Domínio	Resultado
smtp.mailfrom (Return-Path)	bounces.sendingplatform.example	spf=pass
header.d (DKIM)	sendingplatform.example	dkim=pass
header.from	yourcompany.example	dmarc=fail

Dois pass e um fail, porque nada do que passou pertence ao domínio do From. A especificação atual do DMARC (RFC 9989, maio de 2026, que substitui a RFC 7489) só exige um pass alinhado, e a correção habitual é ativar o DKIM personalizado para o seu próprio domínio na plataforma de envio.

Return-Path: para onde vão os bounces

O Return-Path é o remetente do envelope, adicionado na entrega final, e é o endereço para onde os bounces são enviados. Também é a identidade que o SPF verifica.

A RFC 5321 diz que o servidor que entrega a mensagem o insere na entrega final, preservando o endereço do comando MAIL FROM, e que seu objetivo principal é dizer para onde vão os avisos de não entrega. Ele costuma ser diferente do From, principalmente com uma plataforma de envio que cuida dos seus bounces. Isso é normal. Mas se ele aponta para um lugar que você não controla, os bounces que você precisa ver estão indo para outro lugar, e isso importa para manter uma lista limpa.

O que os cabeçalhos não conseguem dizer

Os cabeçalhos mostram a autenticação e a rota, não por que um filtro escolheu Spam. O Gmail não escreve a pontuação de reputação no cabeçalho.

Se tudo no cabeçalho passa e a mensagem ainda cai em Spam, a resposta está nos dados de reputação, não no cabeçalho. No Gmail, isso significa o Postmaster Tools. Para a ordem de investigação dessas causas, veja o diagnóstico do Gmail.

Um checklist para qualquer cabeçalho

1. Copie o cabeçalho da cópia do destinatário, nunca de Enviados.
2. Encontre o Authentication-Results mais alto escrito pelo seu provedor. Ignore os outros.
3. Confira os resultados de spf, dkim e dmarc. Anote o domínio ao lado de cada um.
4. Compare esses domínios com header.from. Pelo menos um pass precisa estar alinhado.
5. Consulte no DNS o seletor DKIM (s=) e o registro DMARC para confirmar que ainda existem.
6. Leia as linhas Received de baixo para cima. Anote o primeiro IP que o seu provedor registrou e qualquer salto com um intervalo longo.
7. Compare o Date com o horário do primeiro Received para separar atraso do lado do remetente de atraso nos relays.

Para rodar a parte de DNS deste checklist no seu próprio domínio de uma vez, use a auditoria de entregabilidade gratuita.