SPF answers one question: is this server allowed to send mail for this domain? You publish a list of authorised senders as a DNS TXT record, and receiving servers check the sending IP against it.
A typical record looks like this:
v=spf1 include:amazonses.com include:_spf.google.com ~allEach include delegates to another domain’s SPF record — usually a provider
telling you which of their IPs to trust. The final mechanism says what to do
with everything else: ~all is a soft fail (accept but mark), -all is a hard
fail (reject).
The ten-lookup limit
This is the failure mode that bites in practice. SPF permits a maximum of ten
DNS lookups when evaluating a record, and every include, a, mx, and
redirect counts — including lookups nested inside the records you include.
Exceed ten and the result is permerror, which most receivers treat as a
failure. Since each provider you add typically costs one to three lookups, a
company using an ESP, a CRM, a helpdesk, and a payroll tool can quietly blow
through the limit and discover it months later.
Count your lookups when you add a provider, and remove include entries for
services you no longer use.
What SPF does not do
SPF authenticates the envelope sender (the return-path), not the From:
address the recipient sees. On its own it does nothing to stop someone putting
your brand in the visible From: header. That gap is why DKIM and, above all,
DMARC alignment exist.
SPF also breaks on forwarding: when a message is forwarded, the forwarding server is not in your SPF record, so the check fails. DKIM survives forwarding, which is one reason you want both.