How can I see what emails have been sent by Exchange server 2019 to investigate spamming?

---

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?

---

what about just by the smtp server including relays?

---

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?

---

Ok I have this from Spamhaus: 'The machine using this IP is infected with malware that is emitting spam, or is sharing a connection with an infected device.

As a result, this IP is listed in the eXploits Blocklist (XBL) and the CSS Blocklist (CSS)

Click on More Info to see if you can request a delisting from this blocklist. This will also display any further information we have relating to this listing.

Less Info
If this is a shared server, please call your hosting company or ISP!

Why was this IP listed?
167.98.18.58 has been classified as part of a proxy network. There is a type of malware using this IP that installs a proxy that can be used for nearly anything, including sending spam or stealing customer data. This should be of more concern than a Spamhaus listing, which is a symptom and not the problem.

The proxy is installed on a device - usually an Android mobile, firestick, smart doorbell, etc, but also iPads, and Windows computers - that is using your IP to send spam DIRECTLY to the internet via port 25: This is very often the result of third party "free" apps like VPNs, channel unlockers, streaming, etc being installed on someone's personal device, usually a phone.

Technical information:
Recent connections:

(IP, UTC timestamp, HELO value)

167.98.18.58 2025-08-06 14:30:00 ch1nam05-obe.outbound.protection.outlook.co

Items of note:

This issue is very likely to be caused by a personal device, such as a mobile phone, with residential proxy malware or a spambot installed on it. It is EXTREMELY rare for this to be the SMTP server at fault.
This is a simple explanation of how it can work.
Any devices with "free" VPNs, TV streaming, channel unlocking, or 3rd-party apps installed are the first things to check.

What should be done about it?
DYNAMIC IPs/MOBILE USERS

If you are NOT running a local mail server on this IP, please do the following:

Go to What Is My IP? and find out what your public IP is.
Call your ISP - the company that is providing your internet access via the IP you just looked up.
Find out from your ISP if the IP is dedicated or dynamic.
If it is dynamic, is it CG/NAT?
What are your outbound mail settings? Have your ISP verify your mail settings are correct:
SMTP server name
Outgoing SMTP port
Are you using SMTP authentication - yes/no?
Once you have this information, open a ticket.
Please provide your verified mail settings in this ticket. Our ability to help you depends on this information!

STATIC IP/LOCAL MAIL SERVER(S)

Do you have one or more local SMTP servers? The problem is NOT your mail server. It is never the mail server. It is always someone's mobile device (phone, laptop, tablet), or more rarely a computer, somewhere on the LAN. There can be more than one!

These are the recent HELOs we have seen. If they match your mail server's rDNS, do not dismiss this, and read on.

(IP, UTC timestamp, HELO value)

167.98.18.58 2025-08-06 14:30:00 ch1nam05-obe.outbound.protection.outlook.co

What to do:

Make sure port 25 access is limited to mail server access only / end-users should be using SMTP authentication on port 587 or 465
Guest networks need to be limited too!
Remote sending of email to servers via the Internet will still work if web-based, or configured properly to use port 587 using SMTP-AUTH.
Do you have clients or end users NAT'd to the same IP as your mailserver? If so, this is very likely to be the source of the problem.
Set up logging at the exit point and let it run for a few days to find anomalous port 25 traffic - these proxies do not necessarily fire every day.' but there is no evidence any device on the network has sent that much traffic today

---

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?

---

But they are reporting a outlook.com smtp ident and we don't use office365, especially from a server with our own IP address!

---

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?

---

But the router shows no sign of any SMTP traffic, and everyone is blocked from sending to port 25 anyway

---

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?

---

This is a dedicated fibe link - there is no shared IP range. Is there a way someone could spoof that IP to attack us?

---

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?

---