Yeah, so, I may actually be the bane of your existence... as I've run a few tests at FIs and flagged the non-use of spf's as an issue... well, the issue was more that I could easily impersonate their internal staff, and get their employees to click/do pretty well anything I wanted on their systems. Hell, you could seriously f-up a FI's daily operations just by mass spamming their users with legit looking emails coming from internal sources -- so even barring the potential loss / compromise of your systems, the time-loss and reputational damage alone of that sort of thing is significant.

I understand that it's a PITA, but cmon.. many organisations have such crap filters that you can send an email to anyone of their employees, as the boss, saying "Click this link or else you're fired". At the very least, you should have that SPF record to stop people from impersonating your internal users... to your other internal users.

There are other ways to go about it, sure. But it basically all boils down to... "What approach you use to solve the problem is up to you. But if you stand up and say 'our setup is impervious to spoofed emails!', and someone comes along, tests your setup, and breaks it easily... then you need to find a new solution". Especially when you're talking about a FI, where staff potentially have access to enough information to steal the identity of literally thousands of people.

Besides, telling an IT professional to maintain an SPF record as part of ... you know.. being an IT professional in charge of email security... is an order of magnitude easier than trying to educate internal users enough to catch well crafted spear phishes. I mean, if you stumble across a site from one of your business partners, and they've let their ssl/tls cert lapse, you'd likely go "Oh man, you all kinda screwed the pooch there eh?", and that dept'd prolly get in some trouble. I reckon a similar line can apply to spfs.