SPF answers a narrow question: is this connecting IP authorized to send mail for the SMTP identity being checked?
The policy lives in DNS as a TXT record.
example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.example.net -all"
What SPF actually authenticates
SPF normally evaluates the domain used by the SMTP envelope sender (MAIL FROM). That can be different from the From: address a person sees in their mail client.
That difference is important. A message can pass SPF for one domain while displaying another domain in the From header. DMARC adds the alignment check that connects authentication to the visible From domain.
Common mechanisms
ip4/ip6— authorize address ranges.include— evaluate another domain’s SPF policy.a— use addresses returned for a hostname.mx— use addresses of MX hosts.all— matches everything and is normally placed last.
Qualifiers such as -, ~, ? and + affect the result returned by a matching mechanism.
The DNS lookup limit
SPF is not an unlimited chain of includes. RFC 7208 limits DNS-query-causing terms during evaluation. Complex SaaS environments can exceed that limit and return permerror.
Do not solve this by blindly copying records or creating multiple SPF records at the same name. Inventory the real senders and simplify intentionally.
Forwarding
Traditional forwarding changes the connecting IP. That is why an otherwise legitimate forwarded message can fail SPF. DKIM, SRS and ARC address different parts of this problem.