Authorizing your own mail for SPF:
Inferring from other sites that use O365, your SPF policy should have this element included:
"include:spf.protection.outlook.com"
This will authorize
outlook.com to send your mail, and protect you from risk of message rejection by other organizations.
Testing SPF on incoming mail:
If a desired sender domain uses O365 and has not done this, you need to configure an exception for that domain (or disable SPF checking completely.) I have never been satisfied with the exception mechanisms in SmarterMail, which is why I use Declude. But SPF policy errors are common, and SPF FAIL is more likely to indicate a configuration error than a fraudulent impersonation. As a result, I have found blocking based on SPF FAIL to cause unacceptable problems, so turning it off is an option.
I find the actual value of SPF testing is to combine a desired domain with SPF PASS to permit whitelisting. The domain name tells me that it is a preferred sender and the SPF PASS tells me that the preferred sender has not be impersonated, therefore the whitelisting action is safe. I could not find a way to do that with SmarterMail spam filtering by itself, or in a bunch of other commercial solutions, in though some were very expensive.
I have recently begun using Declude to test for non-existent SMTP domains, and that seems to be a pretty reliable indicator of spam. But I don't think SmarterMail provides a way to detect that.
Miscellaneous on O365 server names
SPF uses a forward-confirmed HELO name when the SMTP address is null. The HELO name is irrelevant for SPF otherwise. My data shows that Office365 HELO names do not forward confirm to the IP address, but the Reverse DNS lookup of the IP address will forward-confirm back to the