When working out what action to take on the various SPF verdicts, bear in mind that the Office 365 groupies are currently churning out epic numbers of PERMERRORs for valid domains they're converting. As that's mostly seagull conslutancy, there's no-one with any technical clue at the sender domain to fix things if you point the error out to them. The other unholy terror of SPF validation is the forgotten back office workflow system automatically churning out trivial things like invoices, process notifications, payslips and the like. Still, manually resending all that traffic (because you won't be the only one dropping it) will give all those suddenly-more-productive office staff something to do.
Most emphatically test with a log action before going live with a drop or quarantine action. I introduced SPF here one sender group at a time, starting with the lowest SBRS ranges. Even if you only act on hard FAIL verdicts, you'll still want an Incoming Mail Policy for folk with SPF errors that they simply can't correct.
Before getting into all of that, it's worth checking what your analysis team actually wanted. Remember that publishing SPF to authenticate your outgoing mail and doing SPF validation to check your incoming mail are two different things, and you don't have to do both though in this day and age the first is definitely recommended. The article Raed recommended focusses entirely on the second, as that's where an ESA fits into the process.
