On Exchange Server 2019, your main forensic tools for seeing what emails have been sent (including any spam that might have been relayed or sent by compromised accounts) are:

1. Message Tracking Logs

Exchange logs every message transaction to its message tracking logs. These are the fastest way to see who sent what, when, and to where.

PowerShell example - see all messages sent in the last day:

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-1) -EventId "SEND" | 
Select Timestamp, Sender, Recipients, MessageSubject, ClientHostname, ClientIP | 
Sort Timestamp

Key fields to watch for:

• Sender - account that sent the message
• Recipients - where it went
• ClientHostname / ClientIP - can identify if it came from OWA, EAS, SMTP, or another relay
• MessageSubject - quick way to spot spam patterns

2. Filtering by Suspected Sender

If you think a specific account is compromised:

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-2) -Sender "[email protected]" -EventId "SEND" |
Select Timestamp, Recipients, MessageSubject

3. Checking SMTP Receive Logs (Protocol Logs)

If you want to see SMTP conversations (including unauthenticated attempts):

1. Enable protocol logging if not already on:

Set-ReceiveConnector "Default Frontend <ServerName>" -ProtocolLoggingLevel Verbose

2. Logs are stored by default in:

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\ProtocolLog\SmtpReceive

These will show source IPs, HELO strings, and authentication status.

4. See Outbound Connector Activity

If you send outbound via a smart host or connector, check:

Get-SendConnector | fl Name,ProtocolLoggingLevel

Enable protocol logging to catch outbound conversations:

Set-SendConnector "Internet Send" -ProtocolLoggingLevel Verbose

Outbound logs are in:

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\ProtocolLog\SmtpSend

5. Look at Queue Viewer

If spam is still flowing:

• Open Exchange Toolbox Queue Viewer
• Check Active queues for abnormal recipients or volumes.

6. Suspicious Volume Detection

If you just want to find heavy senders:

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-1) -EventId "SEND" |
Group-Object Sender | Sort-Object Count -Descending | Select-Object Name, Count

This will show which senders pushed the most email.

7. Next Steps if Spam is Found

• Disable the suspected account immediately
• Force password change
• Check ClientIP in logs - if it's external and unexpected, block it at firewall
• Review Receive Connector permissions to ensure you're not an open relay

If you want, I can give you a one-liner that will show all external email sent from your Exchange 2019 server with subject lines and source IPs in the last 48 hours, which is usually the fastest way to catch spammers.

Do you want me to prepare that command?

If you want to see everything your SMTP service sent out - including relays, authenticated users, and automated systems - you can get it by looking only at the SEND events from the transport logs, without filtering by specific senders.

That way you'll catch:

• Authenticated mailbox sends
• Relay sends via receive connectors
• Any app or device using your Exchange SMTP service

One-liner for all outbound SMTP sends (last 48 hours)

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-2) -EventId "SEND" |
Select Timestamp, Source, Sender, {$_.Recipients -join ","}, ClientHostname, ClientIP, MessageSubject |
Sort Timestamp

Fields explained:

• Source - Should be SMTP for relay traffic
• Sender - Email address of sender (may be spoofed for relays)
• Recipients - All recipients of the message
• ClientHostname / ClientIP - Where it connected from
• MessageSubject - Easy way to see spam patterns

Narrow it to SMTP relay activity only

If you want only the messages that came in via SMTP (not MAPI, OWA, EAS, etc.):

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-2) -EventId "SEND" -Source "SMTP" |
Select Timestamp, Sender, {$_.Recipients -join ","}, ClientHostname, ClientIP, MessageSubject |
Sort Timestamp

If you need to see raw relay protocol details

1. Enable verbose protocol logging on your receive connectors:

Set-ReceiveConnector "Default Frontend <ServerName>" -ProtocolLoggingLevel Verbose
Set-ReceiveConnector "Relay Connector" -ProtocolLoggingLevel Verbose

2. Logs go here:

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\ProtocolLog\SmtpReceive

3. These will show the MAIL FROM, RCPT TO, authentication status, and HELO/EHLO - which is essential to catch non-authenticated relays.

If you like, I can give you a combined PowerShell search that pulls from both message tracking logs and protocol logs so you see exactly what your SMTP server sent (including HELOs, auth method, and IP) - that's the method I use when investigating open relay abuse.

Do you want me to prepare that?

Right - what Spamhaus are describing here is not necessarily your Exchange 2019 server pushing spam. They're saying something on the same public IP (167.98.18.58) - maybe even behind NAT with your mail server - opened a direct raw TCP connection to port 25 on the internet, bypassing your normal SMTP server entirely.

That's why your message tracking logs might look clean - this traffic never hit Exchange at all.

Why you might not see it in Exchange logs

• A compromised phone, Firestick, IoT gadget, laptop, or PC can open a direct SMTP session to a remote host on port 25, without authentication or relaying through your Exchange server.
• If you're behind a NAT, Spamhaus only sees the public IP - which is shared between your Exchange server and any other LAN device.
• If outbound port 25 is not blocked at your firewall, any LAN device can do this.

What you should do now

1. Check if your public IP is shared

If this server is on a hosted environment, a CGNAT, or an ISP dynamic IP pool, the spam could be from another customer. If it's your own dedicated IP - then it's inside your network.

2. Log ALL outbound port 25 connections at the firewall

Since the malicious traffic never touches Exchange, you have to catch it at the network edge.

Example on a firewall with logging:

• Create a temporary permit rule for outbound TCP 25, log source IP and bytes sent.
• Place it above the existing outbound SMTP rule.
• Let it run for 24-48 hours.

This will quickly show which internal IP is opening direct SMTP sessions.

3. If you can, block port 25 for everything except Exchange

That's the simplest fix and industry best practice:

• Force all mail clients to use SMTP-AUTH on port 587 or 465.
• Leave port 25 open only for the Exchange server's outbound traffic.

4. Cross-check Exchange itself

Even though Spamhaus think it's "never the SMTP server", still check Exchange:

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-2) -EventId SEND |
Select Timestamp, Sender, {$_.Recipients -join ","}, ClientHostname, ClientIP | Sort Timestamp

If this is clean, you know it's not your mail server generating the spam.

5. If you find the rogue device

• Remove any "free VPN" or shady apps
• Scan with multiple AV/anti-malware tools
• Reimage if you can't guarantee it's clean

If you want, I can give you a PowerShell script for your firewall/router logs that will isolate every internal IP attempting port 25 connections to the internet, so you can spot it even if the traffic is small bursts.

That would be the quickest way to prove whether this is inside your LAN or outside your control.

Do you want me to prep that?

Yeah - that's the interesting tell here.

Spamhaus are saying they saw this on port 25:

HELO ch1nam05-obe.outbound.protection.outlook.com

That means the malware (or device) didn't just randomly open SMTP - it deliberately pretended to be a Microsoft 365 outbound server in its HELO/EHLO greeting.

Two possibilities:

1. It's not your network at all

• If your IP is shared (ISP NAT, hosting provider, carrier-grade NAT, etc.), then the offending device could be somewhere else entirely.
• Spamhaus only sees the public IP, so if it's dynamic or part of a shared pool, they'll attribute someone else's junk to you.

2. It's a device on your LAN running proxy malware

• Many residential proxy botnets use Microsoft 365-looking EHLO strings to blend in with normal mail traffic.
• The malware is likely tunnelling through your public IP, even though you don't use O365.
• That would mean your firewall is letting some device send on port 25 directly.

Why the "O365" string doesn't mean it's Microsoft

Spambots and proxy malware often use:

• Forged HELO/EHLO values to mimic major cloud mailers (O365, Gmail, Amazon SES).
• Sometimes they literally copy Microsoft's EHLO strings to evade blocklists.

This string is just text sent by the connecting device - there's no verification that it's actually Outlook.com.

How to prove whether it's you or not

1. Confirm if your IP is dedicated

curl ifconfig.me
# Compare with your known static IP

Ask your ISP: "Is 167.98.18.58 dedicated to us, or is it part of a NAT/shared block?"

2. Log all outbound TCP/25 at the firewall Even if the traffic is tiny, the source LAN IP will show you:

• If it's your Exchange box - you'll see it here.
• If it's a random workstation/IoT device - that's your culprit.
• If nothing internal ever hits TCP/25 - then it's not you.

3. Block TCP/25 for everything except Exchange If you're not already doing this, it's the simplest preventative measure. Port 587 stays open for clients; only the Exchange server gets 25.

4. Check Exchange tracking logs just to be sure

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddDays(-2) -EventId SEND |
Select Timestamp, Sender, {$_.Recipients -join ","}, ClientHostname, ClientIP | Sort Timestamp

If your Exchange logs are clean and your firewall shows no non-Exchange port 25 traffic, you can push back to Spamhaus that it's not your network.

If you want, I can give you a quick firewall rule strategy that will log - in real time - every single TCP/25 attempt to the internet and tie it to a local MAC address, so you can instantly see if it's your LAN or someone else on your ISP's block.

That would let you tell Spamhaus definitively "this wasn't us".

Do you want me to make that?

Then that points very strongly to this being outside your network entirely - either:

1. Your public IP is not truly dedicated - it's in a shared block (CGNAT, dynamic broadband pool, cloud provider IP range) and Spamhaus saw someone else's traffic from the same address before it got reassigned to you.
2. Spamhaus data is stale - their "recent connections" may be from hours/days before you got the IP, but their listing process hasn't aged out yet.
3. Misattribution - they matched your IP to the connection but the traffic actually originated from elsewhere (e.g., a VPN exit node, proxy network, or transit provider that briefly used your IP).

Why the "router shows no SMTP" matters

If your firewall/router has logging on all TCP/25 attempts and you're blocking everything except Exchange - and that's showing nothing - then there's simply no live source on your LAN that could be making those connections. That means Spamhaus's report is either historical or someone else's problem.

Steps to take now

1. Confirm IP assignment date Ask your ISP when 167.98.18.58 was allocated to you. If it was after Spamhaus's "recent connection" time, you've got proof it wasn't you.

2. Point Spamhaus to your firewall logs Tell them:

   • Port 25 is blocked for all hosts except Exchange
   • Your Exchange tracking logs are clean
   • Firewall logs show zero outbound TCP/25 in the period reported
   • IP may have been reassigned

3. Request delisting If they need reassurance, give them the ISP's statement confirming the IP allocation date. Spamhaus will often remove the listing if you can prove a reassignment.

If you want, I can draft you a short but convincing technical response to Spamhaus that makes it clear the listing is a stale/misattributed hit, so you can get the block removed without them asking for endless "malware scan" proof.

Do you want me to write that?

Yes - absolutely. What Spamhaus is describing could be the result of IP spoofing or abuse via a proxy network, and it would look, from their side, exactly as if your IP made the connection - even if no packet ever left your network.

How someone could make it look like your IP is sending spam

1. IP Spoofing on TCP is hard, but not impossible

• On the open internet, true TCP spoofing (with a full handshake) is rare, because the attacker has to see your inbound responses to complete the connection.
• However, if they are on-path (e.g., a compromised router at your ISP or upstream provider), they can initiate and complete SMTP handshakes that appear to come from your IP.
• This would not hit your router at all, so you'd never see it.

2. Proxy Botnets

• Residential proxy malware networks hijack other people's devices and sell access to their public IP addresses.
• An attacker rents an infected device somewhere else that happens to be on your network block - or worse, on your exact IP if they've found a way to tunnel through.
• This makes it look like the SMTP session is coming directly from you.
• The EHLO string they're using (ch1nam05-obe.outbound.protection.outlook.com) is classic disguise to make spam appear to be O365 traffic.

3. BGP Hijacking / Route Leaks

• In more extreme cases, a bad actor announces a more-specific BGP route for your IP (or subnet), captures the traffic, sends their spam, then drops the route.
• To you, nothing changes locally - your router never sees the SMTP sessions.
• Spamhaus just sees your IP in their logs.

4. Upstream Compromise

• If an upstream router/firewall is compromised, an attacker could originate traffic from your IP directly on that router.
• Again, you'd never see it internally, because it doesn't traverse your LAN.

How to check if this is spoofing / upstream abuse

1. Ask your ISP for NetFlow/SFlow records for the timeframe Spamhaus reports.

   • If they see no TCP/25 from your link, it's upstream spoofing.

2. Look at your public IP's ARIN/RIPE abuse history

   • If this IP has been in a lot of blacklists recently, it might be a known target for spoofing.

3. Set up packet capture at your border

   • Even a few days of capture on TCP/25 can prove there's no outbound traffic.

4. Ask your ISP if they support BCP38

   • This is anti-spoofing filtering that stops packets from leaving their network with forged source IPs.
   • If they don't, spoofing from outside is much easier.

If you want, I can give you a test method to confirm whether someone can spoof your IP right now, which involves sending crafted packets from outside and seeing if they arrive "from you" at a test SMTP listener.

That would let us rule in or out live IP spoofing as the cause.

Do you want me to prepare that test plan?