Analyzing message header

Brass Contributor

We are in hybrid deployment and all mailboxes are in Exchange online. Our mx record is pointing to our 3rd part spam filter, then sent to our on premise server which again sends to Exchange online. In short it looks like this:


Sender - 3rd part spam filter - Exchange on-premise - Exchange online.



When I analyze message header I see the following in Authentication-Results (1st line of the header):


spf=none (sender IP is;; dkim=none (message not signed) header.d=none;; dmarc=none action=none;; dkim=none (message not signed) header.d=none;

Sender IP ( is our On premise exchange server external address. is the domain that sent the message is our exchange online domain.


Is this by design that our On-premise exchange server will be seen as sender?

If so, then it means if someone is spoofing our domain it will be bypassed since sender ip is in our SPF record?


We are getting more than enough spoofing emails that are directed to our CEO and FInance director and adding SPF record doesn't seem to help.


I know DKIM and DMARC should help better against spoofing, but currently we cannot implement them, since our MX record does not point to EOP.




6 Replies
It's by design, indeed, to have the IP of your on-premises server seen as the sender IP. EOP is looking at the connecting IP when evaluating SPF and the connecting IP in this case is the IP of your on-premises server.

The fact that enough emails where your domain is spoofed are reaching your users means that the 3rd party spam filter is not doing the best job or is not configured correctly. Those spoofed emails should be stopped/marked as spam there, at the 3rd party spam filter level. It's also important if your SPF record ends in ~all (soft fail) or -all (hard fail). Many anti spam solutions won't mark as spam an email for which the SPF check soft failed.

In this configuration, Sender - 3rd part spam filter - Exchange on-premise - Exchange online, you are not using the full capabilities of Exchange Online Protection. Ideally, the MX record should point to EOP.

Thanks Victor,


i still think its bad that EXO/EOP is failing on this SPF check on connecting IP and not also checking X-Origin-IP header (which should be IP of mail server sending out mail).

What if customer do not use 3rd party spam filter but still want mail to go through on-premise server(for benefits like better messagetrace) ?

That EOP blindly accepts all message arriving on-premise server is not of best security imo :)

The X-Originating-IP header doesn't contain the IP address of the original sending server, but the IP of the PC were Outlook or OWA was used to compose and send that email. EOP has no way of evaluating the IP of the initial sending server.


Exhange Online has much improved message tracking capabilities compared to Exchange on-premises.

think you are mixing between X-origin-IP and X-Orginating-IP. Last one is IP of end user.

Messagetrace in EXO is NOT better than On-premise. In EXO you can only trace message 1 week back for real time view. If you need older than 7 days, you have to wait 2-4 hours before the results are sent to your inbox.


X-Origin-IP is a custom header probably stamped by your 3rd party spam filtering solution. If you have it, then you can use it to create a transport rule in EXO to block emails where your domain is spoofed. Something like:


If the message...
sender's address domain portion belongs to any of these domains: ''
Do the following...
Set the spam confidence level (SCL) to '5'
Except if...
'X-Origin-IP' header contains ''your IPs''
Regarding the message trace, you are right, there are some things that take longer to achieve in EXO, but on the other side it's so quick and easy to see what exactly happened to an email sent recently.

THanks Vistor,


but i have done multiple test and even from my on-premise server at home. X-Origin-IP is IP of mail server and X-Originating IP is end user IP.

Not every mail server has these stamps. G-mail will stamp with their IPV6 in X-origin-IP.