A aplicação de email só mostra alguns campos do cabeçalho de uma mensagem: De, Para, Assunto e Data. O resto do bloco técnico fica oculto. É aí que estão o percurso da mensagem e o veredicto de autenticação.
O cabeçalho de um email (email header, em inglês) é a sequência de linhas «Nome: valor» colocada antes do corpo da mensagem. Indica quem enviou o email, por que servidores passou e se SPF, DKIM e DMARC foram validados. Para o ler, abra «Mostrar original» no Gmail ou «Ver detalhes da mensagem» no Outlook e leia as linhas Received de baixo para cima.
Ver o cabeçalho de um email no Gmail, Outlook, Apple Mail e Yahoo
Cada aplicação esconde o cabeçalho em bruto num menu diferente. Os caminhos seguintes baseiam-se na ajuda do Gmail e na documentação da Microsoft:
- Gmail: abra a mensagem, clique nos três pontos ao lado de Responder e depois em «Mostrar original». O botão «Copiar para a área de transferência» recolhe o cabeçalho completo. O Gmail resume também, no topo da janela, os resultados de SPF, DKIM e DMARC (Pass ou Fail).
- Outlook na Web e novo Outlook: abra a mensagem e escolha Mais ações > Ver > Ver detalhes da mensagem.
- Outlook clássico para Windows: faça duplo clique na mensagem para a abrir fora do painel de leitura e depois Ficheiro > Propriedades. O cabeçalho está na caixa «Cabeçalhos da Internet».
- Apple Mail: abra a mensagem e escolha Vista > Mensagem > Todos os cabeçalhos.
- Yahoo Mail: abra a mensagem, clique em Mais e depois em «Ver mensagem em bruto».
Cole o resultado num editor de texto, como o Notepad++ ou o TextEdit. Um cabeçalho lê-se mal numa janela estreita.
Um exemplo de cabeçalho de email anotado
Eis um cabeçalho reduzido ao essencial, com o domínio fictício example.com e endereços IP do intervalo de documentação 203.0.113.0/24. Uma mensagem real de 2026 tem muitas vezes mais linhas, nomeadamente os campos Delivered-To e DKIM-Signature.
Return-Path: <bounce+8f2a@bounce.example.com> Authentication-Results: mx.destinataire.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com Received: from smtp1.example.com (smtp1.example.com [203.0.113.25]) by mx.destinataire.example with ESMTPS; Tue, 3 Nov 2026 09:14:07 +0100 Received: from app.example.com (app.example.com [203.0.113.10]) by smtp1.example.com with ESMTP; Tue, 3 Nov 2026 09:14:02 +0100 From: Camille Martin <camille@example.com> Reply-To: <support@example.com> To: <lea@destinataire.example> Subject: Votre facture d'octobre Date: Tue, 3 Nov 2026 09:14:01 +0100 Message-ID: <20261103091401.8f2a@app.example.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8
A mensagem é redigida às 09:14:01 (campo Date) de 3 de novembro de 2026. O servidor smtp1.example.com recebe-a de app.example.com (203.0.113.10) às 09:14:02 e o mx.destinataire.example às 09:14:07. Passam 5 segundos entre os dois servidores e 6 desde a redação. Os 3 controlos de autenticação indicam «pass».
Ler os campos do cabeçalho, do mais visível ao mais técnico
Os 4 primeiros campos abaixo são legíveis na caixa de entrada. Os seguintes exigem a visualização completa.
- From: o endereço apresentado como remetente. É o próprio remetente que o escreve, pelo que, sozinho, não prova nada.
- To e Date: o destinatário declarado e a hora de redação, registada pela aplicação de email ou pelo servidor de submissão.
- Subject: a linha de assunto. Faz parte do cabeçalho e aparece na caixa de entrada, tal como From e Date. A sua redação é tema do guia sobre o objeto de email cativante. O texto de pré-visualização mostrado a seguir ao assunto não faz parte dele: veja o guia do pre-header.
- Return-Path: o endereço que recebe as devoluções. O servidor de destino copia-o do envelope SMTP (o comando MAIL FROM da RFC 5321). Num envio feito através de uma plataforma de emailing, aponta para um domínio de devoluções diferente do de From. É o funcionamento normal, descrito no artigo sobre o return path.
- Reply-To: o endereço que recebe a sua resposta. Sem este campo, a resposta segue para o From.
- Message-ID: o identificador único da mensagem, gerado no envio. O suporte técnico pede-o para localizar o email nos seus registos.
- MIME-Version e Content-Type: o formato do conteúdo (text/html ou multipart/alternative) e o seu conjunto de carateres.
- Os campos X-: acrescentados por filtros. O X-Spam-Status, por exemplo, traz a pontuação do SpamAssassin, explicada no guia sobre a pontuação SpamAssassin.
A sintaxe destes campos está definida na RFC 5322.
Ler as linhas Received de baixo para cima
Cada servidor SMTP que retransmite a mensagem acrescenta a sua linha Received acima das anteriores. A mais baixa corresponde por isso ao primeiro servidor e a mais alta ao último.
Uma linha contém o nome anunciado pelo emissor (from), o seu endereço IP entre parênteses retos, o servidor que recebe (by) e uma hora. Só merecem confiança as linhas acrescentadas pelo seu próprio fornecedor ou pelo servidor de destino: um remetente malicioso pode inventar as linhas mais baixas antes do envio.
O Received descreve o percurso. Não contém nenhum veredicto de SPF nem de DKIM.
Ler o Authentication-Results: SPF, DKIM e DMARC
O campo Authentication-Results (norma RFC 8601) é escrito pelo servidor de destino no momento da receção. A linha acrescentada pelo seu próprio servidor escapa assim ao remetente e é a mais fiável do cabeçalho. Desconfie das linhas com o mesmo nome colocadas mais abaixo, que um remetente pode ter inventado.
- spf=pass (RFC 7208): o IP que transmitiu a mensagem consta do registo DNS do domínio do envelope. O funcionamento está explicado no artigo sobre SPF.
- dkim=pass (RFC 6376): a assinatura criptográfica é válida. O valor header.d indica o domínio signatário. Veja também DKIM.
- dmarc=pass: o SPF ou o DKIM passa com um domínio alinhado com o do From (o mesmo domínio ou o mesmo domínio organizacional, no alinhamento relaxado da RFC 7489). A configuração consta do guia DMARC.
No SPF, os valores de falha são fail («-all» no registo DNS) e softfail («~all»). Uma avaliação SPF termina às 10 consultas DNS (RFC 7208): acima disso, o resultado é permerror. Os erros temporários (temperror) e permanentes (permerror) apontam para um problema de DNS ou de configuração. Depois de um reencaminhamento, o SPF falha muitas vezes porque o IP do relay não está autorizado. As linhas ARC (RFC 8617) guardam então o veredicto que cada intermediário que sela a mensagem constatou à chegada.
Detetar phishing ou usurpação de identidade no cabeçalho
Compare primeiro From, Return-Path e Reply-To. Um Return-Path diferente do From é banal em emailing. Já um Reply-To para um domínio sem relação com o remetente apresentado merece verificação.
Passe depois ao Authentication-Results. Um dmarc=fail numa mensagem que diz vir de um banco ou de uma transportadora indica usurpação (spoofing, em inglês). A ausência da linha mostra que o servidor de destino não registou veredicto: não tire daí nenhuma conclusão favorável. Veja por fim a linha Received mais baixa, a do primeiro servidor: o IP de origem de um «serviço de apoio ao cliente» alojado num fornecedor sem ligação à empresa confirma a suspeita.
Diagnosticar um atraso ou uma classificação como spam
Lança uma campanha, a ferramenta de emailing mostra «enviado» e o destinatário recebe a mensagem 60 minutos depois ou na pasta de spam. Peça-lhe o cabeçalho completo.
Num atraso, subtraia as horas de duas linhas Received consecutivas. Se os relógios estiverem sincronizados, o salto que concentra a diferença aponta para o servidor responsável: fila saturada ou limitação de débito no destino. Num problema de entregabilidade (mensagem classificada como spam), releia o Authentication-Results: um fail em qualquer um destes três controlos é a primeira pista. Procure também um campo X-Spam-Status com pontuação elevada. Desde 2024, as diretrizes da Google para remetentes pedem autenticação SPF ou DKIM em qualquer envio para uma conta Gmail pessoal. Acima de 5 000 mensagens por dia, SPF e DKIM passam a ser ambos obrigatórios, a que se junta um registo DMARC. Uma falha num destes controlos pesa muito na reputação de uma campanha.
Erros frequentes
- Procurar SPF e DKIM no Received. Estes veredictos estão no Authentication-Results.
- Ler os Received de cima para baixo e tomar o último servidor pela origem da mensagem.
- Fiar-se no From apresentado sem verificar o dmarc.
- Reencaminhar a mensagem em texto ao suporte técnico: o reencaminhamento reescreve o cabeçalho. Anexe-a em formato .eml.
Usar um analisador de cabeçalhos
Um analisador de cabeçalhos, como o da Google Admin Toolbox ou o MxToolbox, recebe o cabeçalho colado em texto simples. Reconstrói o percurso salto a salto e calcula o atraso de cada relay.
O analisador faz o trabalho pesado, mas não diz se o servidor que escreveu uma linha Received é de confiança. Essa avaliação cabe a si.
