Behind SMTP: how i analyzed a real-world email spam, header, and reputation incident

If you have ever dealt with critical messages vanishing without a trace or an inbox suddenly flooded with unsolicited junk, you know how frustrating email delivery issues can be. On a phone or laptop screen, email looks simple. Under the surface, however, the SMTP protocol operates on a chain of trust that can easily be abused.

I recently inspected an incident on the bench that provides a clear, textbook demonstration of how malicious messages behave. I decided to document the entire breakdown, from raw header inspection to sender reputation checks and the privacy safeguards needed when reviewing suspicious traffic.

The incident: a flagged header on the table#

The starting point was a message intercepted and quarantined at the border gateway. An ordinary email client only exposes the apparent sender and an attention-grabbing subject line. To understand what is truly happening under the hood, the only reliable path is inspecting the raw message header.

To preserve privacy and security, all real domains, mailboxes, and IP addresses have been sanitized while preserving the exact technical structure and scoring attributes:

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:

Dissecting the header: where the façade crumbles#

Think of an email header as an international travel passport: each stamp marks an exact node, the software handling the connection, and the security rules executed along the journey.

1. Astronomical spam scores#

Right from the opening lines, the filtering engine confirmed that the payload was toxic:

• X-Spam-Flag: YES: Immediately classified as junk.
• X-Spam-Score: 73.031: Standard antispam engines (like SpamAssassin or Rspamd) raise yellow flags at scores above 5 or 6; 15 to 30 triggers quarantine, and 50 represents an automatic drop (kill). A score of 73 is an absolute disaster.
• X-Spam-Level: ******...: An uninterrupted line of asterisks illustrating the score overflow.
• tests=[...]: The diagnostic blueprint of the abuse:
• RCVD_IN_SBL_XBL and RCVD_IN_SIP2: Originating or intermediary IPs were already listed on public botnet and spam blacklists (Spamhaus SBL/XBL).
• LOCAL_BANNED_SNDR: The sender domain or address had already been blocked locally.
• LOTTO_SPAM_REF_4 and US_DOLLARS_3: Heuristic triggers indicating financial scams (the classic "donation" lure).
• MISSING_MID: Total absence of a RFC-compliant Message-ID header generated by standard email clients (Thunderbird, Outlook, or webmail software).
• SPF_PASS: Notice this carefully. The SPF evaluation returned PASS. One of the biggest misconceptions in email security is believing that a valid SPF pass proves a message is benign. SPF only proves that the sending server is authorized by the domain owner. When an account has its password compromised, the attacker sends authenticated spam from inside the authorized infrastructure.

2. The trace route (Received chain)#

The Received headers document the physical transmission trail and must always be read from bottom to top (from origin to final destination):

1. Initial Submission:

Received: from [192.0.2.70] ... by srv-node01.provedor.com.br with esmtpa (Exim 4.98.2) The esmtpa token indicates that an external client connected using valid authentication credentials over an SMTP submission port to dispatch the message through Exim.

1. Internal Relay:

The message traveled from node srv-node01 to gateway mail-gw.provedor.com.br on internal port 10024, where deep scanning and antispam daemons operate.

1. Quarantine Interception:

The outbound security layer calculated the high score and assigned the quarantine identifier: X-Quarantine-ID: <Bz-HojMJtkqM>.

3. The critical sender mismatch#

The visual headers displayed:

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

The social engineering hook was hidden in plain sight inside the reply header:

Reply-To: golpista@consultor-externo.com

If the recipient hits "Reply", their response bypasses the authorized organization entirely and heads straight into the fraudster's mailbox on a completely different domain. This discrepancy between From and Reply-To is a primary hallmark of targeted deception.

The three pillars of email deliverability#

To understand why an email reaches the inbox, gets flagged as spam, or is rejected outright at the connection stage, we must evaluate three foundational pillars:

Pillar 1: Message formatting and content#

• MIME and Encodings: The MIME standard defines whether a message travels as plain text, HTML, or multipart. Broken markup, malformed quoted-printable blocks, excessive formatting, and obfuscated base64 payloads quickly trigger bayesian filters.
• Text Heuristics: Capitalized subject lines like DONATION, urgency cues, and promises of easy money trigger automated score penalties immediately.

Pillar 2: Sender reputation (domain and IP)#

• Domain Age: Freshly registered domains lack established delivery history. Major mailbox providers treat high sending volumes from newly created domains with heightened suspicion.
• Real-time Blackhole Lists (RBLs):
• Domain RBLs: Taint the reputation of the specific domain name. Delisting a burned domain is often a lengthy, manual ordeal.
• IP RBLs: If a server IP lands on a reputable blacklist, all domains sharing that IP face immediate delivery disruptions.
• Reverse DNS (PTR): The sending IP must resolve to a valid hostname, and that hostname must resolve forward back to the exact same IP. Without clean bidirectional alignment, most receiving servers terminate the connection at the HELO/EHLO prompt.

Pillar 3: Technical validation and DNS#

• SPF: Explicitly identifies which IP addresses are authorized to dispatch emails on behalf of the domain.
• DKIM: Cryptographically signs the message headers and body (bh= and b=), guaranteeing that content has not been tampered with in transit.
• DMARC: The governance policy that ties SPF and DKIM together. It specifies whether unaligned messages should be monitored (p=none), isolated (p=quarantine), or rejected at the boundary (p=reject).
• The Golden MX Rule: The MX record must point to an A record directly, never to a CNAME. Pointing MX to CNAME violates RFC specifications and causes intermittent delivery failures across major providers like Google and Microsoft.

Practical detection and privacy ethics#

When investigating delivery complaints or abuse reports, the intuitive impulse might be opening the body of the message. That approach is both risky and unnecessary.

The golden rule of email investigation: technical analysis should be exhausted within the headers before inspecting message content.

By examining metadata (reviewing X-Spam-Status, checking Reply-To against From, auditing the relay hops in Received, and verifying RBL tags), the vast majority of incidents can be diagnosed with zero intrusion into private communications.

Message body inspection should remain an exceptional last resort, governed by three core principles:

1. Strict Technical Purpose: Content inspection is justified solely to verify false positives, isolate malicious payloads, and protect infrastructure integrity.
2. Regulatory and Privacy Compliance: Communications in transit carry confidential data. Careless handling or unnecessary exposure creates serious legal liability.
3. Data Minimization: Gather only the technical evidence required for the diagnostic verdict. If the header already revealed an off-the-charts score, botnet blacklist flags, and an anomalous Reply-To, the investigation is already complete.

The operational takeaway#

Auditing an email header does not require guesswork, but it does require a disciplined methodology. The single most important lesson from this case is that a green SPF pass is never a clean bill of health. Attackers deliberately use compromised credentials on legitimate accounts to ride on the back of established domain reputation.

Whether managing self-hosted infrastructure or keeping business communication secure, two operational habits make all the difference:

• Watch outbound traffic patterns: Monitor sending volume and outbound queues. A sudden spike in authenticated connections often pinpoints an account takeover long before the IP ends up on an RBL.
• Scrutinize basic header mismatches: When the address signing the message does not match the mailbox expecting the reply, treat it with caution immediately. Reading headers methodically prevents falling victim to social engineering and saves countless hours of cleanup down the road.

See also

Infrastructure Gmail rejecting DirectAdmin system emails: authenticating server hostnames with SPF and DKIM

Email The Exim black hole, DMARC alignment failures, and restoring IP reputation

Email Meeting Google and yahoo email authentication requirements: practical SPF, DKIM, and DMARC guide

This post is licensed under CC BY-NC.