How SPF works
A domain publishes a DNS TXT record listing the IP addresses and ranges authorized to send mail on its behalf, for example: v=spf1 include:_spf.google.com ~all. When a receiving server gets a message, it checks the sending server’s IP against the SPF record for the envelope sender’s domain. A mismatch can result in the message being marked as spam or rejected outright, depending on the qualifier.
SPF qualifiers matter
The character before all changes enforcement: -all (hard fail) tells receivers to reject non-matching mail, ~all (soft fail) asks them to mark it as suspicious but usually still accept it, and +all (pass everything) effectively disables SPF protection — a surprisingly common misconfiguration that defeats the purpose of publishing the record at all.
The 10-lookup limit
RFC 7208 caps SPF evaluation at 10 DNS lookups (each include, a, mx, ptr, or exists mechanism counts). Domains that stack many third-party senders (CRM, support desk, marketing platform, transactional email) via nested include statements can exceed this limit, causing the entire SPF check to fail with a PermError — silently breaking authentication for every sender on the domain.
SPF and email verification
Email verification tools check SPF, DKIM, and DMARC configuration as part of deliverability scoring, but SPF alone doesn’t confirm a specific mailbox exists — it only confirms whether a domain’s outbound mail is authenticated. A domain can have perfect SPF/DKIM/DMARC and still have individual addresses that bounce.