Email being spoofed Exchange 2019

Question

Email being spoofed Exchange 2019

Susan Dodds 421

Exchange 2019. I have an email coming in that appears to be from ******@contoso.com. When you hit reply, the email address is now ******@phisherson.com.

In the email itself, you click the ******@contoso.com email address, it shows up as that user's email address.

I already have it as a rule to block contoso.com emails that originate outside of the organization to stop spoof emails and has worked up till now.

User@contoso doesn't have anything in their sent folder regarding this issue.

Is user@contoso compromised and someone using a SMTP software to spoof the email?

How do I block this?

Thanks

0 comments

1 answer

Your answer

Answer 1

Chris-D 1,180 Independent Advisor

Hi Susan,

Good day. Thank you for sharing the details of your concern.

As this is a user-to-user community forum, I do not have the ability to directly access or modify your account or service. However, I can provide guidance, recommend next steps, share applicable resources, and direct you to the appropriate support channels so the issue can be investigated further.

Based on the behavior described, the message may be using a spoofed From address with a different Reply-To address. This allows it to appear as though it came from ******@contoso.com, while replies are redirected to an address at phisherson.com.

This does not necessarily mean that the mailbox was compromised, as an external sender can forge the visible From address without accessing the account. The absence of the message from Sent Items is also consistent with spoofing, but an administrator will need to review the message headers and mail logs to confirm.

A personal blocked-sender list may block a specific address or domain, but organization-wide spoofing requires layered anti-spam and sender-verification controls managed by an Exchange or IT administrator.

For now, I recommend that you:

Do not reply to the suspicious message.
Do not select any links, open attachments, scan QR codes, or provide credentials or sensitive information.
To block the specific sender, you can right-click the email and select Block > Block Sender. You can also report the message as phishing. However, these actions apply only to your mailbox and may not prevent similar spoofed messages sent from different addresses. Organization-wide blocking must be configured by your IT or Exchange administrator.
Keep the original message available for investigation. Please avoid permanently deleting it until your IT or security team has reviewed it.
If you selected a link, opened an attachment, entered your credentials, or approved an unexpected MFA request, please notify your IT/security team immediately and tell them exactly what occurred.

Detailed guidance that you may find helpful:

To ensure that this issue is properly investigated and addressed, please reach out to your organization’s IT administrator. They will need to review the complete message headers and Exchange message tracking logs, determine why the existing anti-spoofing rule did not detect the message, and block or remove similar messages if necessary.

When contacting them, please include:

The original email attached as a .msg file
The subject and time received, including the time zone
The address shown in the From field
The address shown after selecting Reply
Whether you interacted with any link or attachment
Whether other users received similar messages

For your IT admin reference: Search message tracking logs | Microsoft Learn

Additionally, if needed, your IT team can open a support request with Microsoft Support through the support channel available under your organization’s Microsoft support agreement, such as the Microsoft Engage Center. A support engineer can work with your team to review the available logs, Exchange configuration, and other relevant diagnostic information, and provide further troubleshooting guidance or recommend appropriate next steps.

In case you do not know who is your IT admin, kindly refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support

I hope this information is helpful. Should you have any further questions or need additional assistance, please feel free to share them in the comment below. I'm very happy to help.

If the answer is helpful, please click 'Yes' and kindly upvote it.

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Susan Dodds 421 Reputation points

2026-08-25T17:51:35.5466667+00:00

Thank you for the reply.

From the headers, the first few hops are from outside servers and the last 2 hops supposedly originated from my email server. Is this a sign that the account is compromised?

X-MS-Exchange-Organization-AuthSource my server

X-MS-Exchange-Organization-AuthSource my server

X-MS-Exchange-Organization-AuthAs Anonymous
Chris-D 1,180 Reputation points Independent Advisor

2026-08-25T19:09:28.21+00:00
Hi Susan,

Thank you for providing the additional header information.

The last two hops showing your email servers do not, by themselves, indicate that the account was compromised. This can be normal for an inbound message: the external hops show the path before the message reached your organization, while the final internal hops show your Exchange servers processing and delivering it to the recipient’s mailbox.

The following value is particularly relevant:

X-MS-Exchange-Organization-AuthAs: Anonymous

This indicates that Exchange did not authenticate the message as being submitted by an internal user or mailbox. The AuthSource value identifies the Exchange server that processed or stamped the authentication information; it does not mean that the mailbox itself sent the message. Based on these headers, the message appears more consistent with external spoofing than with an authenticated submission from the account.

However, the headers alone cannot provide a definitive conclusion. To confirm the source, use the Message-ID and received time from the original message to search the Exchange message tracking logs:

Open the Exchange Management Shell.

Run the following command, replacing the example values with the relevant information:

Get-MessageTrackingLog -MessageId "<Message-ID>" -Start "MM/DD/YYYY HH:MM" -End "MM/DD/YYYY HH:MM" -ResultSize Unlimited | Format-List Timestamp,EventId,Source,Sender,Recipients,ClientIp,ServerHostname,ConnectorId,MessageId

Review the earliest RECEIVE event and check the ClientIp, ConnectorId, and sender information.

If the logs show that the message was received from an external IP through an anonymous inbound connector and then processed by your internal Exchange servers, this would be expected for an externally spoofed message and would not indicate that the mailbox was compromised. If the logs show that the message was submitted through an authenticated mailbox, SMTP client, application, or unexpected internal relay, further investigation would be required.

For your reference: Message tracking

I hope this clarifies the meaning of the header values. Please contact if you need anything else.
Susan Dodds 421 Reputation points

2026-08-25T19:18:50.46+00:00

For the first RECEIVE message, Client IP is my server's IP, connectorID is one of my connectors. sender is the user@contoso email address
Chris-D 1,180 Reputation points Independent Advisor

2026-08-25T19:45:08.3+00:00

Hi Susan,

Thank you for checking the message tracking results.

The Exchange server’s IP appearing in the first RECEIVE event does not necessarily mean that the user’s account submitted the message. In Exchange Server 2019, the Front End Transport service can receive an external SMTP connection and proxy the message to the Transport service. As a result, the Transport service’s RECEIVE event may show the Exchange server’s own IP and an internal connector rather than the original external source IP.

Similarly, the Sender value of ******@contoso.com represents the sender address presented during SMTP processing and does not, by itself, prove that the mailbox was authenticated or used to send the message. This should be considered together with the previously identified header:

X-MS-Exchange-Organization-AuthAs: Anonymous

That value remains more consistent with an unauthenticated submission than with a message authenticated by the user’s mailbox.

To identify the original connecting IP, please check the Front End Transport SMTP receive protocol logs for the same received time, Message-ID, sender, and recipient:

%ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

If the corresponding SMTP session shows an external IP connecting to the Frontend Receive Connector and presenting ******@contoso.com as the sender, this would be consistent with external spoofing. If the original connection came from an unexpected internal client, application, or relay or the logs show successful authentication with the user’s credentials further investigation would be required.

Reference: Receive connectors in Exchange Server

Susan Dodds 421

Unfortunately, the logs only seem to go back 5 hours ago, which isn't enough.

I redacted the receiving host just in case it's something of mine.

Also, for the send connector in the previous powershell output, I have anonymous users unchecked.

I only have this from my header output:

Hop	Submitting host	Receiving host	Time	Delay	Type⇒
1		redacted	8/25/2026 4:37:56 AM		ESMTP

1		redacted	8/25/2026 4:37:56 AM		ESMTP
--------	--------	--------	--------	--------	--------
1		redacted	8/25/2026 4:37:56 AM		ESMTP
2		redacted	Invalid Date		SMTP
3		my server

Susan Dodds 421 Reputation points

2026-08-25T20:16:02.6933333+00:00

I did find this under my SEND logs.

[Moderator note: Personal Identifiable Information removed]
Susan Dodds 421 Reputation points

2026-08-25T21:12:34.23+00:00

Moderator apparently redacted more on my posts.

The SEND log did show an outside IP address at one point when the email was supposedly from one contoso to another contoso.
Chris-D 1,180 Reputation points Independent Advisor

2026-08-25T21:54:30.1533333+00:00
Hi Susan,

Thank you for sharing the additional log entry. No worries, I was able to review the relevant information before the moderator applied the additional redactions. The log entry provides a clearer picture of how the message entered Exchange.

The AUTHSRC=Anonymous value indicates that the original SMTP connection was not authenticated as an internal user or mailbox. The Inbound Proxy Internal Send Connector entry represents the Front End Transport service proxying the message internally to the Transport service; it does not indicate that the mailbox itself submitted the message.

This also explains why the earlier message tracking result showed the Exchange server’s own IP address and an internal connector: that result represented the internal proxy stage rather than the original external connection.

Based on the information available, the message appears more consistent with an external sender presenting a spoofed sender address than with the mailbox being authenticated and used to send it. However, this finding applies specifically to this message and does not independently confirm the overall security status of the account.

Confirming the account’s overall security would require a broader review of the relevant logs, account activity, and Exchange configuration. If you would like this additional level of validation, you may consider opening a support request with Microsoft Support through the support channel available under your organization’s Microsoft support agreement, such as the Microsoft Engage Center. Once the request is submitted, a support engineer can work with you to review the available logs, Exchange configuration, and other relevant diagnostic information to help validate the message path and determine whether any further action is required.

For detailed guidance on how to open a support ticket, please refer to Open a new Support request - Microsoft Engage Center

I hope this helps move the case forward. If there is anything else I can help with, feel free to reach out.
Susan Dodds 421 Reputation points

2026-08-25T22:41:16.64+00:00

If it helps, the "from" is from the phisher but the "sender" is supposedly the contoso email in the email header.
Chris-D 1,180 Reputation points Independent Advisor

2026-08-25T22:57:44.84+00:00

Hi Susan,

Thank you for clarifying the distinction between the From and Sender fields.

Although the Sender field can legitimately identify an account or system transmitting a message on behalf of another address, an external sending system can also construct this header. Therefore, the presence of a Contoso address in the Sender field does not prove that the corresponding mailbox was authenticated or used to submit the message.

In this case, the previously identified AUTHSRC=Anonymous value and the external origin shown in the proxy log remain consistent with an unauthenticated external submission. The available information therefore suggests that the external sender inserted the Contoso address into the Sender header.

This may also explain why the existing rule did not detect the message if it was checking the From field rather than the separate Sender field. However, any rule targeting the Sender field should be tested carefully because this field can also be used legitimately in send-on-behalf and mailing-list scenarios.

If you decide to contact Microsoft Support, please include the sanitized message headers, the relevant message tracking and protocol log entries, the current transport rule conditions and exceptions, and the received date and time, including the time zone. This information can help the support engineer review the message path and determine why the existing rule did not detect the message.

Wishing you a smooth resolution. If you receive any updates or have additional questions, please feel free to share them here. I’ll be happy to help where possible.
Susan Dodds 421 Reputation points

2026-08-26T19:45:09.21+00:00

I ended up changing the password on the mentioned account but pparently a different mailbox is allegedly sending out emails too now.

Is there a way to track down what's behind this?
Chris-D 1,180 Reputation points Independent Advisor

2026-08-26T21:01:01.7466667+00:00
Hi Susan,

Thank you for the update.

The fact that another mailbox now appears to be sending similar messages does not necessarily mean that the second mailbox has also been compromised. An external sender can spoof multiple addresses within the same domain without knowing the corresponding account passwords. Therefore, changing the first account’s password would not prevent this type of external spoofing.

I recommend treating the new message as a separate sample and correlating its Message-ID and timestamp with the message tracking and SMTP protocol logs. Check the original remote endpoint, Receive Connector, authentication status, and whether the tracking results contain a Mailbox Transport SUBMIT event for the alleged sender.

If the new message again shows an external origin with AUTHSRC=Anonymous, this would be consistent with another spoofed sender address. If the logs show an authenticated submission, a Mailbox Transport SUBMIT event, or an unexpected internal application or relay, the corresponding account or system should be investigated further.

You can use the session ID to correlate the protocol-log entries and trace the complete SMTP conversation. For detailed guidance, please refer to: Analyze Exchange Server protocol logs.

I hope these steps help clarify the next course of action. For a comprehensive investigation, please use the support channel provided under your organization’s Microsoft support agreement. If your organization has access to the Microsoft Engage Center, you can open a support request there.

X-MS-Exchange-Organization-AuthSource	my server
X-MS-Exchange-Organization-AuthSource	my server
X-MS-Exchange-Organization-AuthAs		Anonymous