Ler cabeçalhos: de onde veio este email?

Módulo 1: Como funciona o email · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Depois desta lição, saberá abrir os cabeçalhos de um email, ler as linhas Received pela ordem correta e perceber, a partir do Authentication-Results, se o SPF, o DKIM e o DMARC estavam corretos.

Conceitos-chave: cabeçalhos (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, cabeçalhos X, origem ou mensagem original

O que normalmente não vê

O seu programa de correio eletrónico mostra apenas algumas linhas de uma mensagem: remetente, assunto, data, destinatários. Na realidade, cada mensagem tem dezenas de cabeçalhos (headers) no início, antes do texto. São acrescentados pelo programa do remetente e por cada servidor que a mensagem atravessa pelo caminho. Em conjunto, formam o relato da viagem da mensagem.

Quem sabe ler cabeçalhos consegue responder sozinho a muitas perguntas: este email é mesmo do meu banco? Porque é que só chegou passadas duas horas? Porque é que foi parar ao spam? O meu próprio DKIM está correto? Muitos exercícios desta formação pedem-lhe para analisar cabeçalhos. Nesta lição, vai aprender como fazê-lo.

Abrir os cabeçalhos

Cada programa tem um botão diferente para isso:

Num telemóvel, isto normalmente não é possível. Nesse caso, reencaminhe a mensagem para si próprio como anexo, ou abra-a na webmail.

Um exemplo

O João recebe um email da Ana. É assim que se apresentam os cabeçalhos mais importantes (abreviados):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Linhas Received: de baixo para cima

Cada servidor que encaminha a mensagem coloca uma linha Received: no topo. A mais antiga fica, portanto, em baixo, e a mais recente em cima. Leia-as de baixo para cima para seguir a viagem:

1. Linha mais abaixo: o portátil da Ana (IP 198.51.100.77, a sua ligação doméstica) entrega a mensagem a out.hosting.example, com ESMTPSA (o A significa authenticated: ela autenticou-se) e TLS 1.3. Às 10:15:04.
2. Linha do meio: out.hosting.example (192.0.2.25) entrega a mensagem a mx1.mailprovider.example, o MX de example.net. Às 10:15:07.
3. Linha mais acima: o servidor de correio coloca a mensagem internamente na caixa de correio do João (LMTP). Às 10:15:09.

Uma linha Received tem sempre a forma from <quem a ofereceu> by <quem a recebeu> with <protocolo>; <hora>. Entre parênteses, a seguir a from, aparece o que o servidor recetor viu efetivamente: o nome real (PTR) e o endereço IP real. Essa parte é fiável na medida em que confia nesse servidor recetor. O que o próprio remetente indicou (helo=) não é verificável.

Dois truques práticos:

• Procurar atrasos: compare as horas. Se houver um intervalo de duas horas entre duas linhas, a mensagem esteve esse tempo todo numa fila de espera nesse ponto. Tenha atenção aos fusos horários (+0100, +0000).
• Encontrar o verdadeiro servidor de origem: procure a linha Received mais acima que tenha sido escrita por um servidor do próprio destinatário e veja o que consta aí a seguir a from. Tudo o que está abaixo disso foi escrito pelo lado que enviou e, em teoria, pode ser forjado. No exemplo, 192.0.2.25 é o servidor que entregou a mensagem junto do destinatário; é sobre ele que são avaliados o SPF e a reputação.

Os endereços

Um truque conhecido de burlões: um From que parece ser do seu banco, com um Reply-To para um endereço totalmente diferente. Em caso de dúvida, verifique sempre o domínio em From e em Return-Path, e o Authentication-Results.

Authentication-Results: o veredito do destinatário

O servidor recetor coloca em Authentication-Results (RFC 8601) o resultado das suas verificações:

• spf=pass smtp.mailfrom=example.com: o IP do servidor que fez a entrega consta do registo SPF do domínio indicado em Return-Path.
• dkim=pass header.d=example.com header.s=x: a assinatura DKIM do domínio example.com, com a chave (selector) x, está correta.
• dmarc=pass header.from=example.com: o domínio em From está alinhado com um SPF ou DKIM aprovado, pelo que o DMARC foi aprovado.

Outros resultados que pode ver: fail (não está correto), softfail (o SPF termina em ~all e o IP não consta do registo), neutral, none (sem registo), temperror (erro temporário de DNS) e permerror (registo com defeito, por exemplo dois registos SPF). O que estes significam exatamente e como os corrigir está explicado no módulo 4.

Atenção: confie apenas no Authentication-Results do servidor do próprio destinatário (o nome no início, aqui mx1.mailprovider.example). Uma mensagem falsificada pode incluir o seu próprio Authentication-Results, inventado. Os bons servidores removem-no, mas nem todos o fazem.

DKIM-Signature: a assinatura

O cabeçalho DKIM-Signature é a própria assinatura. Há dois campos de que precisará com frequência:

• d= o domínio que assina (aqui example.com);
• s= o selector, o nome da chave (aqui x).

Com isso, encontra a chave pública no DNS: x._domainkey.example.com. Em exercícios e na resolução de problemas, terá frequentemente de procurar exatamente estes dois valores. Uma mensagem pode ter várias assinaturas DKIM, por exemplo uma do seu domínio e outra do serviço de envio. Na lição 4.3, aprofundaremos este tema.

Por vezes também vê ARC-Seal, ARC-Message-Signature e ARC-Authentication-Results. O ARC (RFC 8617) é uma forma de os intermediários, como uma lista de distribuição ou um servidor de reencaminhamento, registarem quais foram as verificações antes de alterarem a mensagem. Não precisa de saber interpretá-los para já.

Cabeçalhos X

Os cabeçalhos que começam por X- não são normalizados. Os filtros antispam colocam neles a sua pontuação, como X-Spam-Status: No, score=1.2 ou X-Spam-Flag: YES. Isso ajuda a perceber porque é que algo foi parar ao spam. Variam consoante o fornecedor.

Resumo

• Os cabeçalhos são o relato da viagem de uma mensagem. Abra-os com "mostrar original", "código-fonte da mensagem" ou algo semelhante.
• Leia as linhas Received de baixo para cima. A linha que o servidor do destinatário escreveu indica qual o IP que fez a entrega.
• Return-Path é o remetente de envelope (SPF), From é o remetente visível (DMARC), Reply-To indica para onde vão as respostas.
• Authentication-Results dá o veredito sobre SPF, DKIM e DMARC; confie apenas no que vem do servidor recetor.
• Em DKIM-Signature constam d= (domínio) e s= (selector); juntos, indicam o local da chave: s._domainkey.d.

Quiz

Exercício

Exercício Z1.5: Analisar os cabeçalhos. Envie-se a si próprio um email a partir de outro endereço (por exemplo, do seu endereço de trabalho para o seu endereço pessoal, ou vice-versa), abra os cabeçalhos e cole-os no formulário. Se não tiver um segundo endereço, utilize o ficheiro de exemplo kopregels-1.txt fornecido com o exercício. Em seguida, preencha você próprio: o endereço IP do servidor que entregou a mensagem junto do destinatário, o domínio no Return-Path, o domínio e o selector da assinatura DKIM, e o resultado do SPF, do DKIM e do DMARC. O programa analisa os mesmos cabeçalhos, procura a chave DKIM em tempo real e coloca o seu resultado ao lado do seu. Os seus cabeçalhos não são guardados.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; noutros fornecedores, o funcionamento é semelhante.

• Verificar se um e-mail chegou com o rastreio de e-mail (Email Tracking) no DirectAdmin
• Manual DirectAdmin 9.3: Rastreamento de e-mails: onde ficou o meu e-mail?
• Este email é mesmo da WebOké? Como reconhecer phishing e utilizar o código de promoção
• Curso gratuito de DNS 4.4: DKIM: a assinatura por baixo do seu e-mail
• RFC 5322 (estrutura de uma mensagem), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)