Check an SPF record, count its DNS lookups the way a receiver does, and find the mechanism that pushes it over the limit.
SPF is a list, published in DNS, of the servers allowed to send mail using your domain. A receiver looks it up, compares it against the server actually delivering the message, and decides whether the sender is authorised. Without one, anybody can put your domain in the From line and nothing contradicts them.
The part that catches people out is the limit. RFC 7208 caps an evaluation at ten mechanisms that require a DNS lookup: include, a, mx, ptr, exists and redirect. ip4, ip6 and all cost nothing. Go over ten and the receiver does not simply ignore the extra entries. It abandons the whole evaluation and returns permerror, which most receivers treat as though you had published no SPF record at all.
That is why a record can stop working without anyone touching it. Your record might use six lookups, but the mechanisms inside somebody else's include count against your total too. A vendor adding one include of their own, months after you wrote your record, is enough to push you to eleven. Nothing warns you, the record still looks correct, and mail quietly loses its authentication. This checker walks the whole include tree and tells you which mechanism crossed the line, because a total on its own leaves you guessing.
~all means unlisted senders are treated with suspicion; -all means they fail outright. Start with ~all while you confirm the list of everything that legitimately sends as you, then move to -all. Never use +all: it tells every receiver that any server on the internet may send as your domain.
No. A receiver that finds more than one returns permerror and applies neither, so two correct records are worse than one. When a second vendor is onboarded, add an include to the existing record rather than publishing another.