SPF answers exactly one question, and stating it precisely now will save you a great deal of confusion later:
The claim SPF makes
Is the host currently connected to me authorised to send mail using this domain in the SMTP envelope sender?
Every property of SPF follows from that sentence — including all of its limitations, which are not defects but the direct consequence of the question it was built to answer.
The mechanics, in one paragraph
The domain owner publishes a list of authorised hosts as a TXT record. When a receiving server takes a connection, it reads the domain from the envelope sender, looks up that domain’s SPF record, and checks whether the connecting IP is in the list. That is the whole protocol, specified in RFC 7208.
"v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"
Read that record as an inventory. It is a public statement that Cloudflare sends mail from their own ranges, from Google Workspace, from Mailchimp, from Mandrill, from Zendesk, from their status-page provider, and from Salesforce. Any organisation’s SPF record is a reasonably honest list of the mail platforms it uses.
What SPF does not do
Four things, and every one of them causes a recurring misunderstanding:
- It says nothing about the address the user sees. SPF checks the envelope sender. The
From:header is a different address, and SPF never looks at it. A message can pass SPF and still display any From address in the world. - It does not check the message. SPF authorises a host, not content. Once a host is authorised, it may send anything.
- It does not survive forwarding. When a message is forwarded, the forwarding server connects from its own IP, which is not in your record. SPF fails, correctly, for a message that is entirely legitimate.
- It does not tell receivers what to do. SPF produces a result. What a receiver does with a failure is entirely the receiver’s decision, and in practice a bare SPF failure rarely causes rejection on its own.
Why SPF is still worth deploying
Given all that, SPF on its own is a weak control. Its real value is as one of the two inputs to DMARC, which is the protocol that connects an authentication result to the address the reader actually sees. SPF is a component, not a solution, and organisations that deployed it in isolation and stopped generally did not get the protection they thought they had.
A consequence worth predicting now
SPF authorises hosts. If you authorise a shared platform’s sending infrastructure, you have authorised every IP that platform sends from — including the ones it uses for its other customers. On a large shared platform, an include can authorise tens of thousands of hosts, most of which have nothing to do with you.
That is not a reason to avoid include; it is unavoidable in practice. It is a reason to understand that SPF alone cannot distinguish your mail from another customer’s mail on the same platform, and to know that DKIM can.