Entender os cabeçalhos de e-mail: o guia completo para ler e analisar cada campo

⚡TL;DR

• Os cabeçalhos de e-mail são um diário de bordo invisível que registra cada servidor percorrido, cada verificação de autenticação e cada decisão antispam
• Os cabeçalhos Received são lidos de baixo para cima: o hop mais antigo está embaixo, o mais recente em cima
• Authentication-Results resume os veredictos SPF, DKIM e DMARC em uma única linha; é o campo mais importante para diagnosticar um problema
• Os campos From, Return-Path e Reply-To podem apontar para três endereços diferentes, sinal potencial de spoofing
• Uma ferramenta de análise automatizada transforma dezenas de linhas técnicas em um diagnóstico legível em poucos segundos

Você recebe um e-mail suspeito. O remetente exibe o nome do seu banco, mas algo não parece certo. Ou então seus próprios e-mails chegam na caixa de spam dos seus clientes e você não entende por quê. Nos dois casos, a resposta está no mesmo lugar: os cabeçalhos do e-mail. Quando se sabe que 60 % das violações confirmadas envolvem uma ação humana (Verizon DBIR 2025) e que são necessários em média 207 dias para detectar um comprometimento por phishing (IBM 2025), saber ler um cabeçalho não é mais um luxo técnico.

Cada e-mail transporta um bloco de metadados invisíveis. Esse bloco contém o itinerário completo da mensagem (quais servidores foram percorridos, em qual ordem), os resultados das verificações de autenticação (SPF, DKIM, DMARC) e pistas sobre como os filtros antispam trataram a mensagem. É um diário de bordo completo, mas é preciso saber lê-lo.

Este guia ensina você a extrair esses cabeçalhos, entender cada campo, interpretar a cadeia de roteamento e diagnosticar os problemas mais frequentes. Seja você administrador de sistemas, responsável por marketing ou simplesmente curioso para saber se um e-mail é legítimo, nenhum conhecimento prévio é necessário: começamos do zero.

O que é um cabeçalho de e-mail e por que você deveria se importar?

A analogia do envelope postal

Quando você envia uma carta, o envelope traz o endereço do remetente, o do destinatário e os carimbos dos Correios. O conteúdo da carta está separado dessas informações de roteamento.

Um e-mail funciona da mesma maneira. O corpo da mensagem (o texto, as imagens, os anexos) está separado dos cabeçalhos que transportam os metadados. A diferença: os cabeçalhos de um e-mail contêm muito mais informações do que um envelope postal. Cada servidor que o processa adiciona suas próprias anotações, como um carimbo postal com data e hora.

Cabeçalhos visíveis vs cabeçalhos técnicos

Seu cliente de e-mail exibe alguns cabeçalhos de forma legível:

• De (From): o endereço do remetente
• Para (To): o endereço do destinatário
• Assunto (Subject): o assunto da mensagem
• Data (Date): o registro de data e hora do envio

Mas sob essa superfície, dezenas de cabeçalhos técnicos permanecem ocultos. Os mais importantes:

Cabeçalho	Função
Received	Rastreia o caminho da mensagem de servidor em servidor
Return-Path	Endereço de retorno (envelope SMTP)
Authentication-Results	Veredictos SPF, DKIM e DMARC
DKIM-Signature	Assinatura criptográfica da mensagem
Message-ID	Identificador único da mensagem
X-Spam-Score	Pontuação atribuída pelo filtro antispam

Quatro razões para ler os cabeçalhos

1. Diagnosticar um problema de entregabilidade. Seus e-mails chegam na caixa de spam? Os cabeçalhos da mensagem recebida dizem exatamente por quê: falha SPF, assinatura DKIM inválida, política DMARC não respeitada ou pontuação antispam muito alta.

2. Verificar a identidade de um remetente. Um e-mail diz vir do seu diretor financeiro? Compare o campo From com o Return-Path e verifique se o DKIM está assinado pelo domínio correto. Uma discrepância entre esses campos é um forte sinal de alerta.

3. Detectar spoofing e phishing. Os atacantes falsificam o campo From para se passar por um domínio legítimo. Os cabeçalhos de autenticação revelam se a mensagem foi realmente emitida pelo servidor autorizado. Um dmarc=fail combinado com um spf=fail em um e-mail que diz vir do seu banco é um indicador confiável de fraude. E o problema é enorme: 84,2 % dos ataques de phishing superam os controles DMARC (Egress 2024), seja porque o domínio não tem política DMARC, seja porque a política é permissiva demais (p=none).

4. Rastrear um problema de latência. Cada cabeçalho Received contém um registro de data e hora. Comparando os timestamps de cada hop, você identifica o servidor que introduz um atraso anormal na cadeia de roteamento.

Como extrair os cabeçalhos

Cada cliente de e-mail oculta os cabeçalhos técnicos por padrão. Veja como exibi-los.

Gmail (web)

1. Abra o e-mail em questão
2. Clique no menu de três pontos verticais (⋮) no canto superior direito da mensagem
3. Selecione "Mostrar original"
4. Uma nova janela exibe os cabeçalhos completos com um resumo SPF/DKIM/DMARC na parte superior

O Gmail oferece um botão "Copiar para a área de transferência" para recuperar a totalidade dos cabeçalhos. É o método mais rápido para colá-los em uma ferramenta de análise.

Outlook desktop (Windows/Mac)

1. Abra o e-mail em uma janela separada (clique duplo)
2. Vá em Arquivo > Propriedades
3. Os cabeçalhos aparecem no campo "Cabeçalhos de Internet" na parte inferior da janela

O campo é pequeno: selecione tudo (Ctrl+A) e depois copie (Ctrl+C) para trabalhar mais confortavelmente em um editor de texto.

Outlook web (OWA)

1. Abra o e-mail em questão
2. Clique no menu de três pontos (⋮) no canto superior direito
3. Selecione "Exibir" e depois "Exibir origem da mensagem"
4. Os cabeçalhos são exibidos em uma nova janela

Apple Mail (macOS)

1. Selecione o e-mail na lista
2. Na barra de menu, vá em Visualizar > Mensagem > Todos os cabeçalhos
3. Os cabeçalhos técnicos aparecem acima do corpo da mensagem

Para voltar à visualização normal: Visualizar > Mensagem > Cabeçalhos padrão.

Thunderbird

1. Selecione o e-mail
2. Menu Exibir > Código-fonte da mensagem (ou atalho Ctrl+U, Cmd+U no Mac)
3. O código-fonte completo se abre em uma nova janela, cabeçalhos incluídos

O Thunderbird também exibe um resumo dos cabeçalhos diretamente no painel de leitura se você ativar Exibir > Cabeçalhos > Todos.

Yahoo Mail

1. Abra o e-mail em questão
2. Clique no menu de três pontos (⋮) ao lado do botão Responder
3. Selecione "Exibir mensagem bruta"
4. Os cabeçalhos completos e o corpo da mensagem são exibidos em uma nova aba

ProtonMail

1. Abra o e-mail em questão
2. Clique no menu de três pontos (⋮) no canto superior direito da mensagem
3. Selecione "Exibir cabeçalhos"
4. O ProtonMail exibe os cabeçalhos em uma janela modal. Use o botão copiar para recuperar a totalidade

Nota: como o ProtonMail é um serviço criptografado do lado do cliente, os cabeçalhos visíveis são aqueles adicionados durante o trânsito SMTP. Os cabeçalhos internos da infraestrutura do ProtonMail permanecem limitados.

Dica prática

Qualquer que seja o método, copie a totalidade dos cabeçalhos e cole-os em uma ferramenta de análise de cabeçalhos. A ferramenta decompõe automaticamente cada campo, calcula os atrasos entre os hops e destaca os problemas de autenticação.

Copie TODO o conteúdo. Os cabeçalhos de um e-mail profissional costumam ter entre 50 e 200 linhas. Se você copiar apenas as primeiras linhas, perderá os hops Received mais antigos (que estão embaixo) e, muitas vezes, as informações mais reveladoras.

Erro frequente: não confunda "Exibir código-fonte" (que mostra a mensagem completa, cabeçalhos + corpo codificado) com "Exibir cabeçalhos" (apenas os metadados). Para um diagnóstico completo, o código-fonte inteiro é preferível: ele contém as assinaturas DKIM verificáveis.

Formato e estrutura dos cabeçalhos (RFC 5322)

O formato chave: valor

Cada cabeçalho segue um formato simples definido pela RFC 5322:

Nome-Do-Campo: valor do campo

O nome do campo não diferencia maiúsculas de minúsculas (From e from são idênticos), seguido de dois-pontos e depois o valor. Exemplos:

From: contact@captaindns.com
To: support@captaindns.com
Subject: DNS Monitoring Report - March 2026
Date: Sat, 29 Mar 2026 10:15:00 +0100
Message-ID: <20260329101500.abc123@mail.captaindns.com>

O folding (continuação em várias linhas)

Quando um valor é longo demais para caber em uma única linha, ele continua na linha seguinte com uma indentação (espaço ou tabulação). É o que se chama de folding. Exemplo com um cabeçalho Received:

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Essas três linhas formam um único cabeçalho Received. A regra: toda linha que começa com um espaço em branco é a continuação do cabeçalho anterior.

A ordem de leitura: de baixo para cima para os Received

Esta é a particularidade mais importante dos cabeçalhos de e-mail: os cabeçalhos Received são lidos de baixo para cima.

Cada servidor SMTP que processa a mensagem adiciona seu cabeçalho Received acima dos cabeçalhos existentes. O resultado: o primeiro hop (o servidor de origem) está embaixo, o último hop (o servidor de recepção) está em cima.

Os demais cabeçalhos (From, To, Subject, Date, Message-ID) são adicionados uma única vez pelo servidor de origem. Sua posição no bloco é fixa.

Os campos-chave explicados um por um

From

From: Marie Dupont <contact@captaindns.com>

Descrição: identifica o remetente exibido no cliente de e-mail. É o campo que o destinatário vê.

O que revela: o From é o cabeçalho mais visível, mas também o mais fácil de falsificar. Qualquer servidor SMTP pode enviar um e-mail com um From arbitrário. É precisamente por isso que SPF, DKIM e DMARC existem: verificar que o From corresponde realmente ao servidor que enviou a mensagem.

Atenção ao display name. O campo From contém dois elementos distintos: o nome exibido (display name) e o endereço real entre colchetes angulares. Em From: Marie Dupont <contact@captaindns.com>, seu cliente de e-mail exibe "Marie Dupont" em negrito e o endereço contact@captaindns.com em tamanho menor. O problema: o display name é um texto livre, sem nenhuma verificação. Um atacante pode escrever From: Diretor Financeiro <atacante@dominio-malicioso.com> e muitos clientes móveis exibem apenas o nome, não o endereço. Sempre verifique o endereço entre colchetes angulares, não o nome exibido.

To e Cc

To: support@captaindns.com
Cc: tech@captaindns.com

Descrição: To lista os destinatários principais. Cc (cópia carbono) lista os destinatários em cópia visível.

O que revela: se o seu endereço não aparece nem em To nem em Cc, a mensagem foi enviada para você em cópia oculta (Bcc) ou por meio de uma lista de distribuição. As campanhas de phishing em massa costumam usar um To genérico ou vazio.

Subject

Subject: =?utf-8?B?UmFwcG9ydCBkZSBtb25pdG9yaW5n?=

Descrição: o assunto da mensagem. Pode ser codificado em Base64 ou Quoted-Printable quando contém caracteres não ASCII (acentos, caracteres especiais).

O que revela: em sua forma decodificada, é o texto que você vê na sua caixa de entrada. A codificação bruta nos cabeçalhos é normal e não indica nenhum problema.

Date

Date: Sat, 29 Mar 2026 10:15:00 +0100

Descrição: registro de data e hora definido pelo cliente do remetente no momento do envio. O formato segue a RFC 5322: dia, data, hora e deslocamento UTC.

O que revela: compare essa data com os timestamps dos cabeçalhos Received. Uma diferença de várias horas entre o Date e o primeiro Received pode indicar um e-mail enviado por um script mal configurado ou uma tentativa de manipulação temporal.

Return-Path

Return-Path: <bounces@mail.captaindns.com>

Descrição: o endereço para o qual as mensagens de retorno (bounces) são enviadas. É o endereço do envelope SMTP (MAIL FROM), adicionado pelo servidor de recepção final.

O que revela: o Return-Path pode ser diferente do From. Isso é normal quando um serviço de terceiros envia e-mails em seu nome. Por exemplo, um e-mail enviado pelo SendGrid mostrará Return-Path: <bounces+12345@em.sendgrid.net> mesmo que o From seja contact@captaindns.com. O mesmo vale para Mailgun (bounces@mailgun.org) ou Amazon SES (0123abcd@amazonses.com). Esses serviços gerenciam os retornos por meio de sua própria infraestrutura.

É anormal quando um e-mail diz vir de contact@captaindns.com mas tem um Return-Path para um domínio desconhecido que não tem nenhuma relação com um provedor de envio legítimo. O DMARC verifica o alinhamento entre o domínio do From e o domínio do Return-Path (ou do DKIM). Um desalinhamento sem DKIM válido provoca uma falha DMARC.

Reply-To

Reply-To: respostas@captaindns.com

Descrição: o endereço para o qual o cliente de e-mail enviará a resposta quando o destinatário clicar em "Responder". Opcional.

O que revela: um Reply-To diferente do From é comum para newsletters (envio a partir de um serviço de marketing, resposta para o suporte). É suspeito quando o Reply-To aponta para um domínio completamente diferente do From, típico dos golpes de fraude do CEO (Business Email Compromise).

Message-ID

Message-ID: <20260329101500.abc123@mail.captaindns.com>

Descrição: identificador único da mensagem, gerado pelo servidor de envio. O formato habitual é um timestamp ou um identificador aleatório seguido do nome de host do servidor, tudo entre colchetes angulares.

O que revela: o domínio no Message-ID indica qual servidor realmente criou a mensagem. Se um e-mail diz vir de captaindns.com mas tem um Message-ID contendo um domínio diferente, é um indício de falsificação. Também é um indicador valioso do serviço de envio real: um Message-ID em @amazonses.com revela um envio pelo Amazon SES, @smtpservice.net indica SendGrid, @mail.gmail.com indica Google Workspace. O Message-ID é um dos cabeçalhos mais difíceis de falsificar de forma convincente, pois é gerado automaticamente pelo servidor SMTP.

MIME-Version e Content-Type

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary123abc"

Descrição: MIME-Version indica que a mensagem usa o formato MIME (quase sempre 1.0). Content-Type descreve o formato do corpo: text/plain (texto simples), text/html (HTML), multipart/alternative (ambas as versões), multipart/mixed (com anexos).

O que revela: um e-mail que diz ser texto simples mas contém um Content-Type: multipart/mixed com um anexo executável é suspeito. O Content-Type ajuda a entender a estrutura real da mensagem.

Received

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Descrição: cada servidor SMTP que processa a mensagem adiciona um cabeçalho Received. É o rastro de roteamento da mensagem.

O que revela: o itinerário completo da mensagem, servidor por servidor. Os detalhes de cada hop (identidade do servidor, protocolo utilizado, timestamp) permitem verificar a legitimidade do roteamento. Seção dedicada mais adiante.

O protocolo indicado após with é um sinal de segurança importante. with ESMTPS significa que a conexão entre os dois servidores era criptografada via TLS: é o padrão esperado em 2026. with ESMTP (sem o S) significa que a mensagem transitou em texto claro, sem criptografia. Se você vir with ESMTP em um hop externo (entre duas organizações diferentes), é um problema: o conteúdo da mensagem, anexos incluídos, circulou legível por qualquer pessoa que intercepte o tráfego de rede. with ESMTPSA indica uma conexão autenticada e criptografada (tipicamente um cliente de e-mail que se conecta ao servidor SMTP com login/senha + TLS).

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=captaindns.com; s=s202603; t=1743238500;
    h=from:to:subject:date:message-id;
    bh=LjIq2t4u3qH0OwZ1E4fDn5t3nVz2Ay+KqR0kbD1XXXA=;
    b=dGVzdCBzaWduYXR1cmUgZXhhbXBsZQ==...

Descrição: assinatura criptográfica adicionada pelo servidor de envio. O servidor de recepção verifica essa assinatura por meio da chave pública publicada no DNS.

O que revela: as tags-chave são d= (domínio assinante), s= (seletor da chave), a= (algoritmo, rsa-sha256 é o padrão), h= (cabeçalhos cobertos pela assinatura), bh= (hash do corpo da mensagem) e b= (a própria assinatura). Se d=captaindns.com e Authentication-Results mostra dkim=pass, a mensagem está autenticada pelo domínio.

A tag bh= (body hash) é um resumo criptográfico do corpo da mensagem. O servidor de recepção recalcula esse hash e o compara com o valor no cabeçalho. Se o corpo foi modificado em trânsito (por uma lista de discussão que adiciona um rodapé, por exemplo), o hash não corresponde mais e o DKIM falha. A tag c= (canonicalization) define a tolerância a modificações menores: relaxed/relaxed é a mais permissiva (ignora espaços extras), simple/simple é rigorosa.

Authentication-Results

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject) header.from=captaindns.com

Descrição: resumo das verificações de autenticação realizadas pelo servidor de recepção. Um único cabeçalho que agrupa os veredictos SPF, DKIM e DMARC.

O que revela: é o campo mais importante para diagnosticar um problema de autenticação de e-mail. Seção dedicada mais adiante.

X-Mailer e User-Agent

X-Mailer: CaptainDNS Mailer 2.1

Descrição: identifica o software cliente utilizado para enviar a mensagem. Campo opcional e não padronizado.

O que revela: um e-mail profissional enviado por um X-Mailer incomum (um script Python básico, uma ferramenta de envio em massa) pode ser suspeito. É um indício complementar, nunca um critério decisivo.

X-MS-Exchange-Organization-SCL

X-MS-Exchange-Organization-SCL: 1

Descrição: Spam Confidence Level atribuído pelo Microsoft Exchange. Escala de -1 (mensagem confiável) a 9 (spam certo). O limite padrão de quarentena é 5.

O que revela: se você usa Exchange ou Microsoft 365, essa pontuação diz diretamente como o filtro antispam da Microsoft avaliou a mensagem. Um SCL de 5 ou mais explica por que um e-mail foi classificado como lixo eletrônico.

Os cabeçalhos ARC

ARC-Seal: i=1; a=rsa-sha256; d=captaindns.com; s=arc202603; cv=none; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=captaindns.com; ...
ARC-Authentication-Results: i=1; mx.captaindns.com;
    spf=pass; dkim=pass; dmarc=pass

Descrição: ARC (Authenticated Received Chain) preserva os resultados de autenticação quando uma mensagem atravessa intermediários (listas de discussão, encaminhamentos automáticos). Três cabeçalhos trabalham juntos: ARC-Authentication-Results (resultados no ponto de passagem), ARC-Message-Signature (assinatura da mensagem nesse ponto) e ARC-Seal (selo da cadeia).

O que revela: quando um e-mail é encaminhado e SPF/DKIM falham por causa da modificação em trânsito, o ARC permite ao servidor final verificar que a autenticação era válida na origem. O campo cv= (chain validation) indica se a cadeia está intacta: none (primeiro hop), pass (cadeia válida) ou fail (cadeia quebrada). Para saber mais sobre o funcionamento do ARC, consulte nosso guia sobre Authenticated Received Chain.

Os cabeçalhos que revelam um serviço de terceiros

Quando uma empresa envia um e-mail por meio de um serviço de terceiros (plataforma de marketing, CRM, ferramenta transacional), os cabeçalhos conservam o rastro da infraestrutura real de envio. É uma ferramenta poderosa para identificar quem realmente envia um e-mail, mesmo que o From exiba um domínio corporativo.

Tabela de assinaturas por provedor

Provedor	Cabeçalhos reveladores	Return-Path típico	Message-ID / DKIM
SendGrid	X-SG-EID, X-SG-ID	@sendgrid.net ou @em.sendgrid.net	DKIM d=sendgrid.net (se não houver DKIM personalizado)
Amazon SES	X-SES-Outgoing	@amazonses.com	Message-ID: @amazonses.com, DKIM d=amazonses.com
Mailgun	X-Mailgun-Sid, X-Mailgun-Variables	@mailgun.org	DKIM d=mailgun.org
Google Workspace	Received: from mail-*.google.com	@*.google.com	Message-ID: @mail.gmail.com
Microsoft 365	X-MS-Exchange-Organization-*, X-MS-Has-Attach	@*.outlook.com	DKIM d=*.onmicrosoft.com
Brevo (ex-Sendinblue)	X-Mailin-EID, X-Mailin-*	@mail-sib.com	DKIM d=sendinblue.com ou personalizado
Postmark	X-PM-Message-Id	@pm.mtasv.net	DKIM d=pm.mtasv.net
Mailchimp	X-MC-User, X-Mailer: MailChimp Mailer	@mcsv.net ou @mail*.suw*.mcdlv.net	DKIM d=*.mcsv.net

Como usar essa tabela

Quando você analisa um e-mail suspeito, procure os cabeçalhos X-* não padrão e o domínio do Return-Path. Se um e-mail diz vir de contact@captaindns.com e os cabeçalhos contêm X-SG-EID com um Return-Path em @sendgrid.net, você sabe que o e-mail passou pelo SendGrid. Não é necessariamente suspeito: basta verificar se captaindns.com realmente usa o SendGrid como provedor de envio.

Por outro lado, se um e-mail diz vir do seu banco mas os cabeçalhos revelam um envio a partir de um pequeno provedor SMTP desconhecido, com um DKIM assinado por um domínio de terceiros sem relação, é um sinal de alerta.

Ler a cadeia Received (de baixo para cima)

A cadeia de cabeçalhos Received é a coluna vertebral do roteamento de e-mail. Cada servidor que toca a mensagem deixa seu rastro.

O princípio: cada servidor adiciona em cima

Imagine uma pilha de carimbos postais. A agência dos Correios de origem aplica o primeiro carimbo. Cada agência intermediária adiciona o seu por cima. A agência de destino fica no topo da pilha.

É exatamente o que acontece com os cabeçalhos Received: o servidor de recepção final adiciona seu cabeçalho no topo. O servidor de origem está na base. Para reconstruir o trajeto cronológico da mensagem, leia os cabeçalhos Received de baixo para cima.

Anatomia de um hop

Cada cabeçalho Received contém quatro informações-chave:

Elemento	Significado	Exemplo
from	Servidor que transmitiu a mensagem	mx-out.captaindns.com
by	Servidor que recebeu a mensagem	mx-in.captaindns.com
with	Protocolo utilizado	ESMTPS (SMTP criptografado TLS)
Timestamp	Data e hora de recepção	Sat, 29 Mar 2026 10:15:02 +0100

O protocolo with é revelador:

• ESMTPS: SMTP com TLS (criptografado, é o padrão esperado)
• ESMTP: SMTP sem TLS (sem criptografia, problema potencial)
• LMTP: protocolo de entrega local (último hop, normal)

Exemplo concreto com 4 hops

Aqui está uma cadeia Received realista para um e-mail recebido por captaindns.com, enviado por um colaborador externo pelo Gmail e filtrado pelo Mimecast. Os cabeçalhos são apresentados na ordem em que aparecem na mensagem bruta (do mais recente ao mais antigo):

(1) Received: from mx2.captaindns.com (10.0.0.5)
        by exchange.captaindns.com (10.0.0.10) with ESMTP;
        Fri, 29 Mar 2026 10:42:15 +0100

(2) Received: from gateway.mimecast.com (91.220.42.50)
        by mx2.captaindns.com with ESMTPS id A1B2C3D4;
        Fri, 29 Mar 2026 10:42:13 +0100

(3) Received: from mail-sor-f41.google.com (209.85.220.41)
        by gateway.mimecast.com with ESMTPS id E5F6G7H8;
        Fri, 29 Mar 2026 10:42:11 +0100

(4) Received: from [192.168.1.100] by smtp.gmail.com with ESMTPSA
        id I9J0K1L2; Fri, 29 Mar 2026 10:42:09 +0100

Leitura de baixo para cima (ordem cronológica):

1. Hop 4 (10:42:09, o mais antigo, embaixo): o remetente envia do seu PC (IP privado 192.168.1.100) pelo servidor SMTP do Gmail. O protocolo ESMTPSA confirma uma conexão autenticada e criptografada
2. Hop 3 (10:42:11): o Gmail transmite a mensagem ao gateway Mimecast. ESMTPS indica uma conexão TLS entre Google e Mimecast (filtro antispam/segurança do destinatário)
3. Hop 2 (10:42:13): o Mimecast, após análise da mensagem, a transmite ao servidor MX do captaindns.com. Conexão ESMTPS, criptografia mantida
4. Hop 1 (10:42:15, o mais recente, em cima): o MX interno transmite ao servidor Exchange final para entrega na caixa do destinatário. ESMTP sem TLS entre servidores internos, aceitável em uma rede privada

Tempo total de trânsito: 6 segundos. É normal. Acima de 30 segundos entre dois hops consecutivos, provavelmente há um problema de desempenho no servidor responsável pelo atraso.

Detectar anomalias na cadeia

Timestamps incoerentes. Um hop 3 datado antes do hop 2? É um relógio dessincronizado (frequente em servidores mal configurados) ou um cabeçalho Received injetado manualmente por um atacante. Verifique se o servidor em questão é legítimo.

Hops ausentes. A mensagem passa do seu servidor diretamente para um servidor desconhecido, sem passar pelo seu gateway? Um intermediário não autorizado pode ter retransmitido a mensagem, ou um servidor da cadeia não gera cabeçalhos Received (raro mas possível).

Servidores desconhecidos. Um nome de host ou um IP que você não reconhece na cadeia? Verifique o DNS reverso do IP. Um servidor legítimo tem um PTR coerente com seu nome de host. Um servidor comprometido ou um relay aberto geralmente tem um PTR genérico ou inexistente.

IPs privados no meio da cadeia. Endereços em 10.x.x.x ou 192.168.x.x são normais no primeiro hop (rede interna do remetente). São suspeitos se aparecem mais adiante na cadeia, pois sugerem um roteamento anormal.

Authentication-Results: SPF, DKIM, DMARC

O cabeçalho Authentication-Results é o painel de controle da segurança de e-mail. Ele resume em uma linha os resultados dos três protocolos de autenticação. É o primeiro cabeçalho a ser verificado quando você diagnostica um problema.

Estrutura do campo

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass (2048-bit key) header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject dis=none) header.from=captaindns.com

O primeiro elemento (mx.captaindns.com) identifica o servidor que realizou as verificações. Cada veredicto é separado por ponto e vírgula.

Campo	Resultado	Significado
spf=pass	✓	O servidor remetente está autorizado pelo registro SPF
dkim=pass	✓	A assinatura criptográfica é válida (seletor: s202603)
dmarc=pass	✓	SPF e DKIM estão alinhados com o domínio From (política: reject)

SPF: o servidor está autorizado?

O SPF (Sender Policy Framework) verifica se o endereço IP do servidor de envio está autorizado pelo registro DNS SPF do domínio.

Veredicto	Significado	Ação típica
pass	O IP está explicitamente autorizado	Aceito
fail	O IP está explicitamente proibido (-all)	Rejeitado ou spam
softfail	O IP não está autorizado mas não está explicitamente proibido (~all)	Aceito com desconfiança
neutral	O domínio não se pronuncia (?all)	Sem impacto
none	Nenhum registro SPF publicado	Nenhuma verificação possível
temperror	Erro DNS temporário	Nova tentativa posterior
permerror	Erro de sintaxe no registro SPF	Varia conforme o servidor

O detalhe entre parênteses (sender IP is 203.0.113.10) fornece o IP que foi verificado. O campo smtp.mailfrom indica o domínio do envelope SMTP.

DKIM: a mensagem é íntegra?

O DKIM verifica a assinatura criptográfica da mensagem. Se a assinatura é válida, o conteúdo não foi modificado em trânsito e o domínio assinante está autenticado.

Veredicto	Significado	Ação típica
pass	Assinatura válida	Autenticado
fail	Assinatura inválida (mensagem modificada ou chave incorreta)	Suspeito
none	Nenhuma assinatura DKIM presente	Nenhuma verificação possível
neutral	Assinatura presente mas não verificável	Sem impacto
temperror	Erro DNS temporário ao recuperar a chave	Nova tentativa
permerror	Erro no registro DKIM	Varia

Os detalhes importantes: header.d= indica o domínio assinante, header.s= indica o seletor utilizado. Essas informações permitem verificar qual domínio realmente assinou a mensagem e com qual chave.

DMARC: o alinhamento está correto?

O DMARC verifica que o domínio do From (visível pelo destinatário) está alinhado com os domínios autenticados por SPF e/ou DKIM. É a camada que impede o spoofing do campo From.

Veredicto	Significado	Ação típica
pass	Alinhamento SPF ou DKIM verificado	Aceito
fail	Nenhum alinhamento válido	Aplica a política p=
bestguesspass	Nenhuma política DMARC publicada, mas o servidor estima que a mensagem é legítima	Aceito
none	Nenhuma política DMARC publicada	Nenhuma ação

Os detalhes DMARC incluem:

• p=: a política publicada pelo domínio (none, quarantine, reject)
• dis=: a disposição realmente aplicada pelo servidor
• header.from=: o domínio do From verificado

Exemplo combinado: leitura completa

Aqui está um Authentication-Results problemático:

Authentication-Results: mx.captaindns.com;
    spf=softfail (sender IP is 198.51.100.42) smtp.mailfrom=notifications.captaindns.com;
    dkim=fail (signature verification failed) header.d=captaindns.com header.s=s202603;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Diagnóstico:

• SPF softfail: o IP 198.51.100.42 não está no registro SPF de notifications.captaindns.com. Talvez um novo servidor de envio ainda não declarado
• DKIM fail: a assinatura é inválida. Causas possíveis: chave DNS obsoleta, mensagem modificada em trânsito ou rotação de chave mal sincronizada
• DMARC fail: nem SPF nem DKIM passam com alinhamento. A política quarantine é aplicada: a mensagem é colocada em spam

Esse tipo de resultado sinaliza um problema de configuração do lado do remetente, não um ataque. A correção passa pela atualização do registro SPF e verificação da chave DKIM.

Os cabeçalhos antispam

Além de SPF/DKIM/DMARC, os filtros antispam adicionam seus próprios cabeçalhos para justificar suas decisões.

X-Spam-Score e X-Spam-Status

X-Spam-Status: No, score=-2.1 required=5.0
    tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_PASS
X-Spam-Score: -2.1

O SpamAssassin utiliza um sistema de pontuação cumulativa. Cada teste adiciona ou subtrai pontos. Uma pontuação acima do limite (geralmente 5.0) classifica a mensagem como spam.

Os testes comuns:

Teste	Pontuação típica	Significado
BAYES_00	-1.9	O conteúdo se parece com ham (não spam) segundo o filtro bayesiano
DKIM_VALID_AU	-0.1	DKIM válido e alinhado com o domínio autor
SPF_PASS	-0.0	SPF aprovado
HTML_MESSAGE	+0.0	A mensagem contém HTML (neutro)
URIBL_BLOCKED	+0.0	As listas de URL não puderam ser consultadas
BAYES_99	+3.5	O conteúdo se parece muito com spam
MISSING_MID	+0.5	Sem Message-ID (suspeito)

A pontuação SCL do Exchange

O cabeçalho X-MS-Exchange-Organization-SCL atribui uma pontuação de 0 a 9:

SCL	Classificação	Ação padrão
-1	Remetente confiável (lista de permissão)	Entrega direta
0-1	Não é spam	Caixa de entrada
2-4	Provavelmente não é spam	Caixa de entrada
5-6	Spam provável	Pasta de lixo eletrônico
7-9	Spam certo	Rejeição ou quarentena

Os cabeçalhos do Google

O Gmail não expõe uma pontuação antispam nos cabeçalhos brutos. No entanto, você encontrará:

• X-Google-DKIM-Signature: assinatura DKIM adicionada pelo Google além da do remetente
• X-Gm-Message-State: estado interno da mensagem na infraestrutura do Google (codificado, não interpretável)
• X-Google-Smtp-Source: identificador do servidor Google que processou a mensagem

A visualização "Mostrar original" do Gmail exibe um resumo SPF/DKIM/DMARC no topo da página, mais legível que os cabeçalhos brutos.

Como interpretar os veredictos

Quando um filtro antispam classifica uma mensagem como spam, procure primeiro o cabeçalho Authentication-Results. Se SPF, DKIM e DMARC estão todos em pass, o problema provavelmente vem do conteúdo (palavras-chave suspeitas, proporção texto/imagem, links encurtados). Se um dos três falha, corrija primeiro a autenticação antes de mexer no conteúdo.

Para entender como os atacantes exploram as falhas nos cabeçalhos para burlar os filtros, consulte nosso artigo sobre os sinais de alerta nos cabeçalhos de e-mail.

6 cenários práticos de diagnóstico

Cenário 1: meu e-mail chega na caixa de spam

Cabeçalhos a verificar: Authentication-Results, X-Spam-Score (ou SCL)

Método:

1. Peça ao destinatário que extraia os cabeçalhos da mensagem recebida na caixa de spam
2. Verifique Authentication-Results: se spf=fail ou dkim=fail, é a causa provável
3. Se SPF/DKIM/DMARC estão todos em pass, olhe a pontuação antispam. Um X-Spam-Score superior a 5.0 ou um SCL de 5+ indica uma filtragem baseada no conteúdo
4. Verifique a reputação do seu IP de envio com uma ferramenta de verificação de listas negras

Exemplo concreto: aqui está o cabeçalho que explica por que um e-mail legítimo termina na caixa de spam.

Authentication-Results: mx.destinatario.com;
    spf=pass smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Aqui, SPF e DKIM passam, mas o DMARC falha. A causa provável: o domínio SPF (mail.captaindns.com) não está alinhado com o domínio From (captaindns.com) e o DMARC exige alinhamento rigoroso (aspf=s). A disposição dis=quarantine confirma que a mensagem foi enviada para a caixa de spam.

Correção rápida: publique ou corrija seu registro SPF, verifique sua assinatura DKIM e implante uma política DMARC no mínimo em p=none para começar a receber relatórios.

Cenário 2: esse e-mail realmente veio do meu diretor?

Cabeçalhos a verificar: From, Return-Path, DKIM-Signature, Authentication-Results

Exemplo concreto: um e-mail que parece vir do seu CEO mas que é uma fraude do CEO.

From: Jean-Marc Duval - CEO <jm.duval@captaindns.com>
Return-Path: <jmduval.ceo@gmail.com>
Reply-To: jmduval.urgent@protonmail.com
Authentication-Results: mx.captaindns.com;
    spf=pass smtp.mailfrom=gmail.com;
    dkim=pass header.d=gmail.com;
    dmarc=fail header.from=captaindns.com

O display name mostra "Jean-Marc Duval - CEO" e o endereço From mostra captaindns.com. Mas o Return-Path aponta para uma conta Gmail, o Reply-To para ProtonMail, e o DMARC falha porque o DKIM está assinado por gmail.com, não por captaindns.com. É uma fraude do CEO clássica.

Método:

1. Compare o From com o Return-Path. Se apontam para domínios diferentes sem razão legítima (nenhum serviço de envio de terceiros conhecido), é um sinal de alerta
2. Verifique Authentication-Results: um dmarc=fail em um e-mail que diz vir do domínio da sua empresa confirma uma falsificação
3. Examine o DKIM-Signature: o d= deveria corresponder ao domínio da sua empresa
4. Olhe o Reply-To: se aponta para um domínio externo (gmail.com, protonmail.com), é uma fraude do CEO clássica

Regra de ouro: se From diz uma coisa e Authentication-Results diz outra, confie nos resultados de autenticação. Apenas 4 % dos domínios aplicam uma política DMARC p=reject (Valimail 2025), o que deixa a porta aberta para esse tipo de falsificação na grande maioria dos domínios.

Cenário 3: há quanto tempo meu e-mail está em trânsito?

Cabeçalhos a verificar: os timestamps de cada cabeçalho Received

Método:

1. Liste todos os cabeçalhos Received de baixo para cima
2. Anote o timestamp de cada hop
3. Calcule o atraso entre cada par de hops consecutivos
4. O hop com o maior atraso é o gargalo

Limites indicativos:

• Menos de 5 segundos entre dois hops: normal
• 5 a 30 segundos: aceitável para um servidor com carga
• Mais de 30 segundos: problema de greylisting, fila saturada ou DNS lento
• Mais de 5 minutos: o servidor provavelmente colocou a mensagem em fila e tentou novamente

Cenário 4: meu DKIM está assinado corretamente?

Cabeçalhos a verificar: DKIM-Signature, Authentication-Results

Método:

1. Localize o cabeçalho DKIM-Signature na mensagem bruta
2. Verifique se d= corresponde ao seu domínio de envio
3. Anote o seletor s= e verifique se o registro DNS correspondente está publicado
4. Olhe o veredicto DKIM em Authentication-Results: dkim=pass confirma que tudo funciona

Causas frequentes de falha DKIM:

• Chave DNS excluída ou mal publicada
• Rotação de chave sem atualização do servidor de envio
• Modificação da mensagem em trânsito (por uma lista de discussão ou uma ferramenta de reescrita de URL)
• Cabeçalho h= que não cobre todos os cabeçalhos modificados

Cenário 5: esse link é phishing?

Cabeçalhos a verificar: From, Reply-To, Return-Path, Authentication-Results, ARC-*

Método:

1. Verifique o From: o domínio é exatamente o esperado? Cuidado com os homóglifos (captaindns.com vs captaindnss.com vs captaindns.co)
2. Compare com o Return-Path: um domínio completamente diferente é suspeito
3. Verifique Authentication-Results: spf=fail + dkim=fail + dmarc=fail em um e-mail supostamente legítimo é um sinal forte de phishing
4. Se a mensagem foi encaminhada, verifique os cabeçalhos ARC-Authentication-Results para ver se a autenticação era válida no ponto de origem
5. Um Reply-To para um domínio gratuito (gmail.com, yahoo.com) em um e-mail corporativo é um clássico do phishing

Para aprofundar as técnicas de spoofing durante o roteamento de e-mail, leia nossa análise sobre o spoofing pelo roteamento de e-mail e o alerta da Microsoft.

Cenário 6: um fornecedor diz ter enviado um e-mail que nunca recebi

Cabeçalhos a verificar: os timestamps Received, Authentication-Results

Contexto: seu fornecedor afirma ter enviado uma fatura em 15 de março. Você nunca a recebeu. Quem tem razão?

Método:

1. Peça ao fornecedor que envie os cabeçalhos completos da mensagem original (não um encaminhamento, mas os cabeçalhos da mensagem enviada)
2. Verifique o primeiro Received (embaixo): ele contém o timestamp do envio inicial. Se o timestamp corresponde a 15 de março, a mensagem foi efetivamente enviada ao servidor SMTP
3. Siga a cadeia Received hop por hop. Se o último hop mostra uma entrega ao seu servidor MX, a mensagem foi recebida pela sua infraestrutura e o problema está na filtragem
4. Se a cadeia para antes do seu MX, verifique Authentication-Results: um spf=fail ou dmarc=fail pode ter provocado uma rejeição silenciosa pelo seu servidor

Dica: os timestamps dos cabeçalhos Received constituem uma prova técnica com marca temporal do trânsito da mensagem. Em caso de disputa, eles documentam objetivamente se o e-mail foi enviado, quando e até onde chegou na cadeia de roteamento.

Plano de ação: 5 passos para dominar os cabeçalhos

Você já tem os conhecimentos teóricos. Veja como colocá-los em prática.

Passo 1: extrair e analisar um primeiro e-mail

Escolha um e-mail que você mesmo enviou (ou um e-mail de teste). Extraia os cabeçalhos com o método adequado ao seu cliente de e-mail. Cole-os na ferramenta de análise de cabeçalhos e compare o resultado automático com sua leitura manual.

Passo 2: verificar sua autenticação

Envie um e-mail do seu domínio para um endereço Gmail. Abra os cabeçalhos e verifique se SPF, DKIM e DMARC mostram todos pass. Se um dos três falha, identifique e corrija a causa antes de passar ao próximo passo.

Passo 3: aprender a detectar anomalias

Treine com e-mails legítimos para calibrar seu senso de normalidade. Quando você sabe como é um e-mail "saudável", as anomalias em um e-mail suspeito se tornam evidentes: servidores desconhecidos na cadeia Received, domínios que não coincidem entre From e Return-Path, assinaturas DKIM inválidas.

Passo 4: automatizar a vigilância

Não verifique os cabeçalhos manualmente para cada e-mail. Configure o DMARC com rua= para receber relatórios agregados diários. Esses relatórios alertam você automaticamente quando os e-mails falham na autenticação para o seu domínio.

Passo 5: documentar seus fluxos de envio

Liste todos os serviços que enviam e-mails em seu nome (CRM, ferramenta de marketing, ticketing, faturamento). Para cada um, verifique se SPF e DKIM estão configurados corretamente. Um fluxo de envio esquecido é a causa mais frequente de falhas DMARC inesperadas.

Mantenha um documento compartilhado com sua equipe que liste cada serviço, o IP ou domínio de envio, o seletor DKIM utilizado e a data da última verificação. Esse referencial evitará que você procure a causa de uma falha DMARC durante horas quando um colega adicionar uma nova ferramenta de envio sem avisar a equipe técnica.

FAQ

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

Um cabeçalho de e-mail é uma linha de metadados no formato "Nome: Valor" que acompanha cada mensagem. Os cabeçalhos contêm as informações de roteamento (servidores percorridos), os resultados de autenticação (SPF, DKIM, DMARC), a identidade do remetente e do destinatário, e anotações adicionadas pelos filtros antispam. O corpo da mensagem (texto, imagens, anexos) está separado dos cabeçalhos por uma linha em branco.

Como ver os cabeçalhos no Gmail?

Abra o e-mail em questão, clique no menu de três pontos verticais no canto superior direito da mensagem e selecione "Mostrar original". O Gmail abre uma nova página com os cabeçalhos completos e um resumo dos resultados SPF, DKIM e DMARC na parte superior. Você pode copiar a totalidade dos cabeçalhos com o botão "Copiar para a área de transferência".

Por que os cabeçalhos Received são lidos de baixo para cima?

Cada servidor SMTP que processa um e-mail adiciona seu cabeçalho Received acima dos cabeçalhos existentes. O primeiro servidor (origem) fica portanto embaixo e o último servidor (recepção) fica em cima. Para reconstruir o trajeto cronológico da mensagem, é preciso ler os cabeçalhos Received de baixo para cima. É um mecanismo definido pela RFC 5321.

O que significa spf=softfail em Authentication-Results?

Um veredicto spf=softfail significa que o endereço IP do servidor de envio não está explicitamente autorizado pelo registro SPF do domínio, mas também não está explicitamente proibido. Corresponde ao mecanismo ~all (til) no registro SPF. O servidor de recepção geralmente aceita a mensagem mas a trata com desconfiança. É frequentemente sinal de um servidor de envio esquecido na configuração SPF.

Como detectar um e-mail falsificado pelos cabeçalhos?

Compare três elementos: o campo From (endereço exibido), o Return-Path (endereço de retorno) e o domínio em DKIM-Signature (d=). Se o From mostra um domínio legítimo mas o Return-Path aponta para um domínio diferente e Authentication-Results mostra dmarc=fail, a mensagem provavelmente foi falsificada. Um SPF fail combinado com um DKIM fail confirma que o servidor de envio não está autorizado pelo domínio exibido.

Os cabeçalhos podem ser falsificados?

Alguns cabeçalhos podem ser falsificados pelo remetente: From, Reply-To, Subject e até mesmo alguns cabeçalhos Received. Em contrapartida, os cabeçalhos adicionados pelo servidor de recepção (Authentication-Results, Received do servidor final, X-Spam-Score) são confiáveis porque são gerados pela sua própria infraestrutura. É por isso que sempre se deve basear nos resultados de autenticação do servidor de recepção, não nos cabeçalhos definidos pelo remetente.

Qual é a diferença entre From e Return-Path?

O From é o endereço exibido no cliente de e-mail, definido pelo remetente no corpo dos cabeçalhos da mensagem. O Return-Path é o endereço do envelope SMTP (MAIL FROM), utilizado para as notificações de retorno. Eles podem legitimamente diferir quando um serviço de terceiros envia e-mails em seu nome. O DMARC verifica o alinhamento entre esses dois endereços: se os domínios são diferentes demais sem razão válida, a mensagem pode falhar na verificação DMARC.

Como automatizar a análise de cabeçalhos?

Cole seus cabeçalhos brutos em uma ferramenta de análise como a do CaptainDNS. A ferramenta decompõe cada campo, calcula os atrasos entre os hops Received, verifica os resultados de autenticação e destaca as anomalias. Para uma vigilância contínua, configure o DMARC com um endereço rua= para receber relatórios agregados diários sobre a autenticação de todos os e-mails enviados do seu domínio.

Glossário

• Cabeçalho de e-mail (header): linha de metadados no formato "Nome: Valor" que acompanha cada mensagem, contendo as informações de roteamento, autenticação e processamento.
• Received: cabeçalho adicionado por cada servidor SMTP percorrido, formando o rastro de roteamento da mensagem. Lê-se de baixo para cima para reconstruir a ordem cronológica.
• Return-Path: endereço do envelope SMTP (MAIL FROM) para o qual as mensagens de retorno são enviadas. Adicionado pelo servidor de recepção final.
• Authentication-Results: cabeçalho adicionado pelo servidor de recepção que resume os veredictos das verificações SPF, DKIM e DMARC.
• SPF (Sender Policy Framework): protocolo que verifica se o endereço IP do servidor de envio está autorizado pelo DNS do domínio remetente (RFC 7208).
• DKIM (DomainKeys Identified Mail): protocolo de autenticação por assinatura criptográfica que verifica a integridade e a origem de uma mensagem (RFC 6376).
• DMARC (Domain-based Message Authentication, Reporting and Conformance): protocolo que verifica o alinhamento do domínio From com os domínios autenticados por SPF e DKIM (RFC 7489).
• ARC (Authenticated Received Chain): mecanismo que preserva os resultados de autenticação quando uma mensagem atravessa intermediários como as listas de discussão.
• Folding: técnica de continuação de um cabeçalho em várias linhas, identificada por uma indentação (espaço ou tabulação) no início da linha seguinte.
• SCL (Spam Confidence Level): pontuação de spam atribuída pelo Microsoft Exchange, de -1 (confiável) a 9 (spam certo).
• Hop: passagem de uma mensagem de um servidor SMTP para outro na cadeia de roteamento. Cada hop é documentado por um cabeçalho Received.
• ESMTPS: Extended SMTP com TLS, indicando uma transmissão criptografada entre dois servidores.

Fontes

• RFC 5322 - Internet Message Format
• RFC 7601 - Message Header Field for Indicating Message Authentication Status
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Google Support - Ver os cabeçalhos completos da mensagem
• Verizon 2025 Data Breach Investigations Report (DBIR)
• IBM Cost of a Data Breach Report 2025
• Egress Email Security Risk Report 2024
• Valimail Email Authentication Report 2025