A few observations, John...
From Wikipedia, SPF article...
https://en.wikipedia.org/wiki/Sender_Policy_FrameworkFAIL and forwarding[edit]
SPF breaks plain message forwarding. When a domain publishes an SPF FAIL policy, legitimate messages sent to receivers forwarding their mail to third parties may be rejected and/or bounced if all of the following occur:
The forwarder does not rewrite the Return-Path, unlike mailing lists.
The next hop does not whitelist the forwarder.
This hop checks SPF.
This is a necessary and obvious feature of SPF – checks behind the "border" MTA (MX) of the receiver cannot work directly.
Publishers of SPF FAIL policies must accept the risk of their legitimate emails being rejected or bounced. They should test (e.g., with a SOFTFAIL policy) until they are satisfied with the results. See below for a list of alternatives to plain message forwarding.
I'm probably asking for trouble here, paraphrasing the issue myself I've already linked to what is probably a much better article. But I'll risk it....
...When a server domain passes mail between servers within its own domain, it would either not bother checking SPF, or it would whitelist its own servers, that explains why the various outlook servers shuffled things around before delivery. The problem arises when mail arises at a node that
does check SPF, and finds that the sending IP address is not authorised to generate mail on behalf of the sender's domain.
As an example, since I use Google Apps, and my own DNS SPF records authorise various Google's IP addresses to generate mail from my domain, with a 'soft fail' for unauthorised IPs. This works perfectly of course, for mail sent using IMAP upload to Google for my domain. But I also occasionally generate email directly to my own addresses, from my own home within Linux shell scripts, in which case the originating IP is my own ISP-assigned IP address. These messages correctly fail SPF and are, by default, delivered to my spam folder. I could add my own IP as an SPF authorised sender but I have not done so, it's an incentive to check my spam once in a while.
When I refer to 'forwarding' I am not talking about opening a mail client and forwarding a message. That would work, because the recipient would see a message forwarded by 7lm, ie it was sent by 7lm, and would find that came from Google, and so it passes SPF.
The forwarding scenario that I don't like is... Some registrars/hosts that I have used in the past offer a transparent forwarding service, whereby mail arriving at the domain is forwarded to some other address, the intention being that mail appears exactly as if it had been addressed to that new address in the first place. This is, effectively, sender 'spoofing', which is what, by my understanding, SPF is intended to stop. If the final receiving server then performs an SPF check, it will think that mail was sent by the IP of the forwarding host. We can't assume that the forwarding host's IP was authorised by the sender and so, if the sender has configured his DNS for SPF, SPF will fail.