Por trás do SMTP: como analisei um incidente real de spam, headers e reputação de e-mail

Se você já passou pelo aperto de ver mensagens importantes sumindo sem explicação ou a caixa de entrada virando um depósito de lixo eletrônico, sabe bem a dor de cabeça que isso dá. E-mail parece algo simples na tela do celular, mas por trás da interface gráfica existe uma engrenagem cheia de armadilhas.

Recentemente peguei na bancada um caso prático que ilustra com clareza cristalina como um e-mail malicioso se comporta de verdade. Resolvi dissecar todo o processo, desde a leitura crua dos cabeçalhos (headers) até os critérios de reputação e os cuidados com privacidade necessários ao inspecionar esse tipo de tráfego.

O problema: um cabeçalho suspeito na mesa#

O ponto de partida foi uma mensagem que disparou alertas automáticos e ficou retida no gateway de borda. Quem olha apenas para o cliente de e-mail comum enxerga somente o remetente aparente e um assunto chamativo. Para enxergar a realidade, o único caminho confiável é puxar o cabeçalho bruto da mensagem.

Para manter a segurança e a privacidade da operação, anonimizei os domínios, contas e endereços IP, mantendo a estrutura e todos os dados técnicos intactos:

X-Envelope-From: <remetente@empresa-origem.com.br>
X-Envelope-To: <destinatario1@provedor-destino.com>, <destinatario2@provedor-destino.com>
X-Quarantine-ID: <Bz-HojMJtkqM>
X-Spam-Flag: YES
X-Spam-Score: 73.031
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=73.031 tag=3 tag2=30 kill=50 tests=[BAYES_50,
CRXBLTRCP, LOCAL_BANNED_SNDR, LOTTO_SPAM_REF_4, MISSING_MID,
RCVD_IN_SBL_XBL, RCVD_IN_SIP2, SPF_PASS, TORECIP, US_DOLLARS_3]
Received: from mail-gw.provedor.com.br ([198.51.100.57])
by localhost (mail-gw.provedor.com.br [198.51.100.57]) (smtp-out, port 10024)
with ESMTP id Bz-HojMJtkqM; Tue, 8 Jul 2025 06:59:00 -0300 (BRT)
Received: from srv-node01.provedor.com.br (srv-node01.provedor.com.br [203.0.113.21])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail-gw.provedor.com.br (SMTP-Out) with ESMTPS id A6BC596F08B6;
Tue, 8 Jul 2025 06:58:59 -0300 (BRT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=empresa-origem.com.br; s=default; h=Reply-To:Date:From:To:Subject:
Content-Description:Content-Transfer-Encoding:MIME-Version:Content-Type:
Sender:Message-ID:Cc:Content-ID:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=EsaxfwkskIk7LYeYvR4xb8cVS0cpOTiZ/2nNJ6qmHio=; b=K4i6qQdwYdpm50JzBTY82XGnKz...
Received: from [192.0.2.70] (port=2394 helo=[192.0.2.212])
by srv-node01.provedor.com.br with esmtpa (Exim 4.98.2)
(envelope-from <remetente@empresa-origem.com.br>)
id 1uZ56J-00000001uXm-06b1;
Tue, 08 Jul 2025 06:58:57 -0300
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Description: Mail message body
Subject: DONATION
To: Recipients <remetente@empresa-origem.com.br>
From: remetente@empresa-origem.com.br
Date: Tue, 08 Jul 2025 10:58:39 +0100
Reply-To: golpista@consultor-externo.com
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - srv-node01.provedor.com.br
X-AntiAbuse: Original Domain - provedor-destino.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - empresa-origem.com.br
X-Get-Message-Sender-Via: srv-node01.provedor.com.br: none
X-Authenticated-Sender: srv-node01.provedor.com.br:

Dissecando o cabeçalho: onde as máscaras caem#

O cabeçalho funciona exatamente como o passaporte de uma viagem internacional: cada carimbo registra por onde o pacote passou, quem manipulou a conexão e quais testes foram aplicados.

1. Métricas de spam fora da curva#

Logo nas primeiras linhas, o motor de filtragem deixou evidente que a mensagem era tóxica:

• X-Spam-Flag: YES: Marcado sumariamente como lixo eletrônico.
• X-Spam-Score: 73.031: Em filtros convencionais (como SpamAssassin ou Rspamd), notas acima de 5 ou 6 já acendem a luz amarela; 15 a 30 costuma mandar a mensagem direto para o lixo ou quarentena, e 50 é o descarte imediato (kill). Uma nota de 73 pontos é uma aberração matemática.
• X-Spam-Level: ******...: Uma sequência maciça de asteriscos representando o estouro da pontuação.
• tests=[...]: Aqui está a receita do desastre:
• RCVD_IN_SBL_XBL e RCVD_IN_SIP2: Os IPs envolvidos já constavam em listas públicas de bloqueio de spam e botnets (Spamhaus SBL/XBL).
• LOCAL_BANNED_SNDR: O endereço ou bloco já havia sido bloqueado nas listas locais de proteção.
• LOTTO_SPAM_REF_4 e US_DOLLARS_3: Gatilhos heurísticos disparados por termos de prêmios falsos e valores monetários no corpo da mensagem.
• MISSING_MID: A ausência de um Message-ID formal gerado por clientes legítimos de e-mail (como Thunderbird, Outlook ou webmails padrão).
• SPF_PASS: Preste muita atenção aqui. O teste de SPF deu positivo (PASS). Esse é um dos maiores equívocos de quem avalia e-mails: achar que SPF válido é sinônimo de mensagem limpa. O SPF apenas atesta que o IP emissor tem autorização do dono do domínio para enviar mensagens por ele. Quando uma conta tem a senha vazada, o invasor dispara mensagens autenticadas de dentro da própria infraestrutura autorizada.

2. A trilha do rastreamento (Received)#

Os campos Received contam a história real da rota e devem ser lidos de baixo para cima (da origem até o destino final):

1. A Injeção Inicial:

Received: from [192.0.2.70] ... by srv-node01.provedor.com.br with esmtpa (Exim 4.98.2) O protocolo esmtpa indica que o cliente conectou autenticado usando login e senha em uma porta SMTP de envio, disparando o envio pelo MTA Exim.

1. O Repasse Interno:

A mensagem seguiu do nó srv-node01 para o gateway mail-gw.provedor.com.br na porta interna 10024, onde rodam os filtros de varredura profunda e antispam.

1. A Retenção Local:

O serviço local capturou a mensagem na saída, calculou o score astronômico e gravou o identificador único de quarentena: X-Quarantine-ID: <Bz-HojMJtkqM>.

3. A inconsistência crítica de remetente x resposta#

O remetente declarado no campo visual era:

From: remetente@empresa-origem.com.br
To: Recipients <remetente@empresa-origem.com.br>
Subject: DONATION

O truque sujo de engenharia social estava no campo de retorno:

Reply-To: golpista@consultor-externo.com

Se a pessoa que recebe o e-mail clica em responder por engano ou curiosidade, a resposta não vai para a empresa legítima que assinou o e-mail: ela vai direto para a caixa do golpista em outro domínio. Esse descompasso entre From e Reply-To é um dos sinais mais claros de fraude direcionada.

Os três pilares da classificação de e-mails#

Para entender por que um e-mail chega na caixa de entrada, cai no spam ou é rejeitado na porta, é preciso observar três pilares fundamentais que qualquer servidor sério avalia:

Pilar 1: Formatação e conteúdo da mensagem#

• MIME e Encodings: O padrão MIME estabelece a estrutura da mensagem (texto puro, HTML ou multipart). Mensagens que misturam codificações malformadas, tags quebradas, excesso de fontes chamativas ou codificações artificiais em base64 chamam a atenção imediata dos analisadores bayesianos.
• Heurística Textual: Assuntos apelativos em caixa alta como DONATION, promessas de ganhos fáceis e pedidos urgentes ativam regras de pontuação automática instantaneamente.

Pilar 2: Reputação do remetente (domínio e IP)#

• Tempo de Registro do Domínio: Domínios registrados há poucos dias não têm histórico de entrega. Provedores grandes tratam qualquer volume vindo de domínios recém-criados com desconfiança dobrada.
• Listas Negras (RBLs):
• RBL de Domínio: Bloqueia a reputação do nome em si. Quando um domínio queima o histórico, sair dessas listas costuma ser um processo lento e desgastante.
• RBL de IP: Se o IP do servidor cair em uma lista de bloqueio, todos os e-mails que saem por aquela máquina sofrem bloqueios em cadeia.
• DNS Reverso (PTR): O IP que conecta precisa apontar de volta para o nome do servidor, e esse nome precisa apontar de volta para o mesmo IP. Sem essa correspondência bidirecional, a maior parte dos servidores de destino rejeita a conexão logo no comando HELO.

Pilar 3: Validação técnica e DNS#

• SPF: Lista os endereços IP que têm permissão legal de enviar mensagens em nome daquele domínio.
• DKIM: Assina digitalmente os cabeçalhos e o corpo da mensagem (bh= e b=); se alguém adulterar o texto no meio do caminho, a assinatura não confere.
• DMARC: A regra que amarra tudo. Define se mensagens sem alinhamento devem ser toleradas (p=none), isoladas (p=quarantine) ou barradas sumariamente (p=reject).
• Atenção ao Registro MX: O registro MX deve apontar para um nome com entrada A direta (IP), nunca para um CNAME. Apontar MX para CNAME desrespeita as normas da RFC e causa falhas intermitentes em provedores como Google, Microsoft e Yahoo.

Detecção prática e postura ética com a LGPD#

Quando surge uma reclamação de e-mail preso ou suspeita de invasão, a reação impulsiva de muita gente é tentar abrir o texto da mensagem. Essa abordagem é perigosa e desnecessária.

A regra de ouro é: a análise técnica deve se esgotar no cabeçalho antes de qualquer inspeção de conteúdo.

Pelos metadados (avaliando o X-Spam-Status, comparando Reply-To contra o From, checando os nós de passagem no Received e conferindo os testes de RBL), é possível solucionar quase 100% dos casos sem precisar ler uma linha sequer da conversa privada de ninguém.

A inspeção do corpo só faz sentido em situações extremas de auditoria técnica autorizada, respeitando três preceitos claros:

1. Finalidade Estrita: A verificação existe única e exclusivamente para conter abuso, neutralizar ameaças e manter o serviço funcionando.
2. Conformidade com a LGPD: Comunicações eletrônicas contêm dados pessoais protegidos por lei. Vazamento ou manuseio negligente de correspondência gera passivos sérios.
3. Mínimo Necessário: Colete apenas a evidência suficiente para o diagnóstico. Se o cabeçalho já registrou score 73, presença em listas de botnets e discrepância evidente no Reply-To, a investigação técnica já atingiu seu veredito com precisão.

O filtro final: o que fica de lição no dia a dia#

Analisar um cabeçalho de e-mail não exige mágica, mas exige método. A lição mais valiosa desse incidente é que uma chave verde de SPF não é passe livre de inocência. Criminosos virtuais adoram usar contas com credenciais fracas ou vazadas justamente para pegar carona na reputação de domínios autênticos.

Se você cuida da sua própria infraestrutura ou quer proteger a comunicação da sua empresa, mantenha sempre duas boas práticas no radar:

• Monitore o fluxo de saída: Fique de olho no volume de envios e nas filas de mensagens. Um salto repentino de conexões em portas autenticadas geralmente denuncia uma conta comprometida antes que o servidor queime nas listas de RBL.
• Desconfie de incongruências simples: Se o endereço que assina o e-mail não bate com o endereço que recebe a resposta, desconfie na hora. Olhar os cabeçalhos com calma evita cair em golpes elaborados e poupa horas de estresse tentando limpar a reputação de um domínio manchado.

Veja também

E-mail O buraco negro do Exim, falhas de alinhamento DMARC e como recuperar a reputação de IP

E-mail Adequando o servidor às exigências do Google e yahoo: SPF, DKIM e DMARC na prática

Infraestrutura Gmail rejeitando e-mails do DirectAdmin: como autenticar o hostname com SPF e DKIM

Este post está licenciado sob CC BY-NC.