Enhanced Filtering for Connectors not working

[Jeremy Bradshaw]

Our mail flow is like this:

1. MX: on-premises Barracuda
2. Barracuda sends into Exchange on-premises.
3. Exchange on-premises sends to EXO via HCW-created "Outbound to Office 365" Send Connector.

We have listed our Barracuda IP (Skip-IP-#1), and our Exchange on-premises servers' outbound/external IP (Skip-IP-#2) into our Enhanced Filtering for Connectors "skip list".  However, we still get tons of incoming emails quarantined, CAT=PHISH, and when I check them in the quarantine (i.e., review their headers), I can see the SPF test is being done against our Exchange on-premises IP (Skip-IP-#2).  There are no signs of the two headers being added - X-MS-Exchange-ExternalOriginalInternetSender and X-MS-Exchange-SkipListedInternetSender - which I understand should be getting added if Enhanced Filtering is working (per this).

<removed no-longer-relevant text>

[#2]

This issue ended up being that Enhanced Filtering for Connectors was enabled via the Defender for Office 365 90-day Evaluation Mode, which puts it into Test Mode only. This can be seen by looking at the Inbound Connector itself in EXO PowerShell:

Get-InboundConnector <Connector of Choice> | fl Name, EF*

# Output:

Name              : # Removed for privacy.
EFTestMode        : False #<--: Right here.
EFSkipLastIP      : False
EFSkipIPs         : {1.2.3.4, 5.6.7.8}
EFSkipMailGateway : {}
EFUsers           : {}

[#3]

PS, even with Test Mode disabled, and for over a week, Enhanced Filtering for Connectors still intermittently doesn't skip our IP's. Still investigating with MS Support.

[#4]

@Jeremy Bradshaw  Can you send me your support ticket id so I can have a look?  Thanks!

[#5 · Accepted solution]

FYI in case this helps anyone else, the reason our Enhanced Filtering wasn't working / wasn't "skipping" our EFSkipIP's, is that our Inbound Connector's TlsSenderCertificateName was set to a fully-typed FQDN (derived from the last page ("Organization FQDN") in the HCW), meanwhile our Exchange servers' certificate didn't explicitly include that FQDN, as it was a wildcard cert.

We had two options to fix this:

1.  Change the TlsSenderCertificateName to be *.<domain>.<tld>

or

2. Replace our Exchange servers' certificate with one that explicitly includes the FQDN from the Inbound Connector's TlsSenderCertificateName.

We were able to spot the issue using the "Inbound Message Report" from the new EXO Admin Center, where we could see that our messages were coming in via "From the internet without a connector", rather than "Inbound via connector <our Inbound Connector's name>".  @Scott Landry deserves the credit as he essentially gave me the answer which I just had to go and confirm.