Actually allow the SPF record hard fail and NDR backscatter hard fail to actually initiate a hard fail.
We received a blatant phishing attempt which should have been classified as spam as the headers easily showed that the message itself did not originate from the legitimate sender. After sending the headers to Microsoft Engineers they stated that sometimes the message will still come through even though the SPF record hard fail flag was enabled in EOP.
If you are going to call something a hard fail, it should act as if it were a hard fail, blocking the message entirely.
We highly recommend using DKIM and DMARC in addition to just SPF. That said, this may be best worked via a support ticket so individual messages can be analyzed. As mentioned, it is completely possible that the issue is because of a whitelist or rule.
Al Douglas commented
An SPF Hard Fail will be marked as high confidence spam (SCL 9) if the advanced spam option "SPF hard fail" is enabled (https://technet.microsoft.com/en-us/library/jj200750(v=exchg.150).aspx) unless the sender is whitelisted in some way. I would suggest enabling this option, unless the email is marked with an SCL-1 then it is bypassing the content filter due to a configured allow list/ETR, and this should be identified and investigated
Antonio Edward commented
Information about DKIM and DMARC:
How to set up DKIM:
How to set up DMARC:
TXT SPF Records explained:
TXT record explained at:
SPF explained in more detail:
Mario P. commented
This is how you setup DKIM:
Matt Griffiths commented
We have had a similar issue, and found it was because SPF was being overridden by a transport rule whitelisting the sender address (ourselves in this case).