Enabled Enhanced Filtering, but EOP still uses my on-prem IP as the source when checking SPF

[Steve Whitcher]

Last week, I enabled the Enhanced Filtering option in the Security Center, giving it 2 IP addresses that are the public addresses of my on-prem exchange server and spam filter.  My understanding is that it should ignore those IPs when determining the source of external mail, and use the next external hop up the chain as the source for mail filtering purposes.  

When I send a test message from an external address, I do see the header added by Enhanced Filtering, indicating that it detected the real source server:

X-MS-Exchange-SkipListedInternetSender: ip=[209.85.166.170];domain=mail-il1-f170.google.com

But the header showing the SPF check shows a failure, because it's using my on-prem IP instead of the IP listed in that SkipListedInternetSender header:

Received-SPF: Fail (protection.outlook.com: domain of OTHERDOMAIN.XYZ does not designate MYON.PREM.SERVER.IP as permitted sender)

Has anyone else here enabled Enhanced Filtering successfully?  Does EOP use the skiplist sender as the source IP for DKIM and SPF checks for you?

What would cause the behavior I'm seeing?  

[#2]

With the help of support, we finally figured out what the problem was. 

The enhanced filtering policy can be applied to specific users, or to the entire organization.  The UI recommends starting with a small group of users first.  I had entered the names of a handful of users here as a test group.  The trouble is, when the message passes through our on-prem exchange, it looks at the recipient's account and sends the email on to the cloud addressed their remote routing address instead of their email address.  When EOP looks at the messages, it's checking that remote routing address (e.g. username@domain.mail.onmicrosoft.com) against the list of users to apply enhanced filtering to, not finding a match, and thus enhanced filtering is not applied.  

The solution is to enter the remote routing address of each user in the exchange filtering policy instead of their name or email address.  Even though the UI does appear to lookup the user name from an email address entered, enhanced filtering doesn't check against all of that user's addresses to determine whether the policy applies. 

It's funny that this oddity only applies when in a testing configuration.  Had I configured the policy to apply to the entire organization, this would have never occurred.  Now that the solution has been applied and enhanced filtering is working as expected, I'll go ahead and enable it for the entire org and this weird behavior won't be relevant anymore.