Does this SPF record actually work?

This record costs exactly 10 DNS-querying terms, which is the limit RFC 7208 allows. It evaluates correctly today and there is nothing broken — but there is no headroom at all: one more include, or one vendor adding an include inside their own record, tips it over and SPF stops working entirely with no change on your side. The most expensive branches are _spf.salesforce.com at 2 lookups, sendgrid.net at 2 lookups — that is where pruning actually helps.

0 confirmed empty lookups, against a limit of 2 — but this count is a floor rather than a total. This record uses 1 term whose target is built from the sending IP address (exists:%{i}._spf.mta.salesforce.com), and that address is not known here, so whether those come back empty cannot be determined without one. They are counted against the lookup limit either way.

The record stays inside both of RFC 7208's limits, so receiving servers can evaluate it to a real answer rather than a permerror. That is a statement about whether SPF WORKS, not about how strict it is — the final all qualifier decides what happens to senders that are not listed, and the email authentication check covers that.