Agent Foskett Investigation • Email Headers • Backscatter Spam • Microsoft 365
The Bounce Was The First Clue
The message looked like an ordinary delivery failure.
A remote mail server claimed that an email from GEMXIT could not be delivered.
The sender address appeared to be mine.
There was only one problem.
I had never sent the original email.
Email Header Investigation
The bounce was genuine. The sender address in the original message was not.
Trace the real message path
Separate the bounce from the original email
Identify forged-envelope backscatter
The delivery failure looked convincing
The subject line and sender resembled a normal non-delivery report generated by a mail server.
Mailer-Daemon senderThe message came from the Mail Delivery System on
ns1.shamcenter.com, not from a human mailbox.Automated submissionThe
Auto-Submitted: auto-replied header confirmed that the server created the message automatically.Failed recipientThe report claimed that delivery to
jonathan@gemxit.com had failed.The authentication results passed
At first glance, SPF, DMARC and composite authentication appeared to validate the message.
- 1
- 2
- 3
- 4
- 5
spf=pass smtp.helo=ns1.shamcenter.com dkim=none dmarc=pass header.from=ns1.shamcenter.com compauth=pass reason=100 sender-ip=184.107.169.4
The pass results belonged to the bounce
Authentication validated the server that delivered the non-delivery report. It did not validate the original message that caused the report.
SPF checked shamcenter.comThe sending IP was authorised for the HELO identity used by the remote server.
DMARC checked the visible From domainThe delivery report used
ns1.shamcenter.com in its From address, so DMARC alignment applied to that domain.The original message was separate evidenceA legitimate bounce can be generated in response to a forged or malicious original message.
The empty Return-Path mattered
Delivery status notifications normally use a null reverse path so that another failure does not create an endless bounce loop.
- 1
- 2
- 3
- 4
- 5
Return-Path: <> Auto-Submitted: auto-replied From: Mail Delivery System Subject: Mail delivery failed: returning message to sender X-Failed-Recipients: jonathan@gemxit.com
The message was generated locally
The Received chain showed that Exim created the delivery report internally before sending it to Microsoft 365.
Generated by Exim
Received: from mailnull by ns1.shamcenter.com with local (Exim 4.99.4) showed local creation.Delivered from CanadaExchange Online recorded the connecting IP as
184.107.169.4 and the country as Canada.Accepted as ordinary inbound mailMicrosoft assigned SCL 1 and delivered the authenticated bounce to the inbox.
The reference pointed back to GEMXIT
The non-delivery report referenced an original Message-ID that claimed to belong to the GEMXIT domain.
- 1
- 2
- 3
References: <20260718032720.FA4659931608FCCC@gemxit.com>
The investigation changed direction
The headers did not show that Microsoft 365 had sent the original message. They showed only that another server believed GEMXIT was the sender.
No outbound Exchange hopThe available headers contained no Microsoft 365 outbound transport path for the original email.
The sender identity could be forgedSMTP allows an attacker to place an unrelated address in the envelope sender used for bounce handling.
The bounce was not proof of compromiseReceiving a non-delivery report does not prove that the referenced mailbox sent the original message.
Backscatter explained the evidence
Backscatter occurs when a mail system sends a delivery failure to an address that an attacker forged as the original sender.
1 — The attacker sends spamThe attacker submits a message to a remote mail system or compromised server.
2 — A legitimate address is forgedThe attacker uses
jonathan@gemxit.com as the return address without controlling the mailbox.3 — The remote server sends the bounceWhen delivery fails, the server returns the report to the forged address—the innocent third party.
The investigation timeline
A routine delivery failure became an SMTP identity investigation.
03:27 — Bounce receivedMicrosoft 365 accepted a delivery failure from
ns1.shamcenter.com.03:30 — Authentication reviewedSPF and DMARC passed, but only for the server that generated the bounce.
03:37 — Backscatter identifiedThe evidence supported a forged sender address rather than a compromised Microsoft 365 mailbox.
What administrators should verify
A bounce should be investigated using message trace and authentication evidence before concluding that an account was compromised.
Check outbound message traceConfirm whether Exchange Online recorded an outbound message matching the time, sender, recipient or Message-ID.
Review account activityLook for unusual sign-ins, inbox rules, OAuth consent, sent messages and authentication-method changes.
Review domain protectionConfirm SPF, DKIM and DMARC are correctly configured, while recognising that they cannot prevent every form of forged envelope sender.
Investigation findings
The evidence supported an unsolicited backscatter message rather than an email sent by the GEMXIT mailbox.
The bounce was authenticThe remote Exim server genuinely generated and delivered the non-delivery report.
The original identity was unverifiedThe headers did not establish that GEMXIT's Microsoft 365 tenant sent the original message.
Mailbox compromise was not indicatedBased on the available evidence, forged sender backscatter was the stronger explanation.
Related Agent Foskett investigations
Continue with email spoofing, authentication and message-header investigations.
The Disney Email Wasn't From DisneyInvestigate display-name trust, sender identity and the authentication evidence behind a familiar brand.
The Invoice Wasn't An Email. It Was A Calendar InviteSee how malicious content can arrive through a trusted collaboration workflow instead of ordinary email.
SenderFrom vs SenderMailFromUnderstand the visible sender, envelope sender and why the distinction matters during spoofing investigations.
AuthenticationDetails ExplainedRead authentication evidence without assuming that a single successful result validates the entire message story.
EmailEvents KQL GuideUse Microsoft Defender XDR telemetry to trace delivery, sender domains, threats and message actions.
Agent Foskett AcademyBuild practical Microsoft security investigation skills through structured lessons and real telemetry.
Final thought
The mail server was telling the truth. It was simply returning the message to the wrong person.
The bounce was realA genuine server had generated a genuine delivery failure.
The sender was the clueThe original return address had been accepted as data, not proven as identity.
The mailbox never sent itThe strongest explanation was backscatter created after someone else forged the GEMXIT address.
