SPF

SPF authenticates the envelope sender — the address used in the SMTP conversation — not the From line a recipient sees. A message can pass SPF while displaying any From address at all, which is why SPF alone was never sufficient and why DMARC exists to tie the two together.

It is still load-bearing. A domain with no SPF record, or one that fails, is filtered aggressively by every major provider regardless of what else is in place.

The lookup limit: an SPF record may trigger at most ten DNS lookups when it is evaluated. Every include: for a mail provider, a helpdesk, a marketing tool costs at least one, and exceeding ten makes the whole record permanently fail — not the eleventh entry, all of it. Records grow past the limit gradually, so this usually breaks a domain that worked for years.

The second is the all mechanism at the end. -all means anything not listed is unauthorised; ~all means treat it as suspicious. Publishing the softer version indefinitely leaves the record advisory, which is roughly the same as not having one for the purposes of a strict receiver.

Look at the resolved record rather than the one you think you published — CNAME chains and provider-managed records mean the two often differ. Count the lookups. Confirm every service that legitimately sends as your domain is represented, including the ones nobody remembers, and remove the ones that no longer do.

Then check it again after any change to your mail provider, helpdesk or CRM. SPF breakage is almost always a side effect of a change made somewhere else.

SalesShift checks SPF, DKIM, DMARC, MX and blocklist status per sending domain, fanning the lookups out in parallel. Every stored answer carries the time it was checked, cached results are labelled as cached, and when the checks cannot run the response says so rather than guessing a value.