Free tool
Read a domain's SPF policy, follow every include behind it, and count what the whole thing costs against the ten DNS lookups the specification allows. That count is the answer — a record can be word-perfect and still fail at every receiver.
SPF is a list of the servers allowed to send mail for your domain, published as one TXT record at the domain itself. A receiving server takes the address the message arrived from and asks whether your record authorises it.
The list is rarely written out. In practice it is a set of include: terms, one per service you send through, each pointing at a record that provider maintains — so your policy is assembled at delivery time out of records you do not control.
Ten lookups sounds generous until you count what a normal business spends: a mailbox provider, a CRM, a helpdesk, an invoicing tool and a marketing platform is five includes, and several of those cost two or three lookups on their own because their records include further records.
Nothing warns you. The record still parses, the zone still looks right, and mail keeps flowing until the evaluation crosses ten — at which point every receiver that follows the specification returns permerror and treats your mail as unauthenticated. The meter above is that count, and the list under it shows which term spent it and which record it came from.
+all, ?all, a missing all, terms after it, and the deprecated ptr mechanism. SPF authorises a server; it says nothing about the message, and it does not survive most forwarding. It is one of the three inputs to DMARC, alongside DKIM, and a domain with only SPF is one forwarded newsletter away from a failure it will never hear about.
RFC 7208 allows an SPF evaluation ten DNS lookups in total. Every include, a, mx, ptr, exists and redirect costs one — including the ones inside your providers' records, which you did not write and cannot see. Over the limit a receiver returns permerror and SPF fails for every message, whether or not the sending server is listed.
Remove includes for services you no longer send from — there is usually at least one. Replace an include you control with the ip4 ranges behind it, which cost nothing. Move a service to its own subdomain with its own SPF record. Flattening a third party's include works and quietly breaks the day they change their ranges.
No. A name may carry exactly one v=spf1 record; two is a permanent error and receivers fail the check rather than picking one. If you send through several services, every include goes in the same record.
~all (softfail) is the safe default and what we recommend while you are not certain every sender is listed. -all (hardfail) tells receivers to reject anything else and is worth moving to once DMARC reports show nothing legitimate is failing. +all authorises the entire internet and is always a mistake.
Often not: a forwarder relays your message from its own servers, which your record does not list. That is exactly why DKIM exists and why DMARC accepts either — an SPF-only setup breaks on mailing lists and forwarding rules.