we ran into something similar a few weeks ago with a client's multifunction printers. same deal, SPF passing but EOP flagging everything as HSPM with that IPV:NLI marker.

my guess is you're right that microsoft tightened something on the EOP side. the fact that it's showing NLI means your connector IP isn't being recognized as a trusted sender even though it should be via the inbound connector config. worth double checking that the connector is scoped correctly and that the source IP hasn't changed (some firewalls rotate outbound IPs if you're behind a NAT pool).

short term fix that worked for us was creating a transport rule to bypass spam filtering for messages matching that connector's IP range. longer term, moving to authenticated SMTP submission or an external relay like you're already planning with SMTP2GO is probably the right call. microsoft has been slowly making unauthenticated relay harder to use for a while now, and i wouldn't be surprised if this is another step in that direction. we started using Suped a while back and it made it way easier to catch stuff like this early through the reporting side, since you can see authentication failures across clients before they turn into tickets.