SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are allowed to send email using your domain. It starts with “v=spf1”, followed by mechanisms such as include:_spf.google.com for Google Workspace or the include your email platform gives you, and ends with a qualifier such as “~all” (soft fail anything else) or “-all” (fail anything else).
When a message arrives, the receiving server checks the domain in the envelope sender, also called the Return-Path or MAIL FROM, and looks up that domain’s SPF record to see whether the sending IP is permitted. Note that this is not the visible From address. For SPF to help with DMARC, the Return-Path domain must align with the From domain, which is why custom return-path domains exist.
There are a few well-known pitfalls. A domain may have only one SPF record; adding a second one for a new service breaks both, so you must merge them into one. SPF evaluation is limited to 10 DNS lookups, and each include can use several, so businesses with many services can exceed the limit and fail without realising. Ending with “+all” lets anyone send as you and defeats the purpose.
SPF also breaks on forwarding, because the forwarding server isn’t on your list. That is one reason DKIM, which survives forwarding, matters, and why DMARC accepts either one. Treat SPF as one layer of authentication, keep it tidy, and review it whenever you add or remove a service that sends email for you.
A Mumbai law firm’s SPF record reads “v=spf1 include:_spf.google.com include:spf.platform.example ~all”. When it adds a billing tool, the developer creates a second SPF record. Invoices start failing SPF until the two records are merged into one.
MailNesto checks your domain’s SPF record live during setup, and its DNS lookup tool warns when a domain has more than one SPF record, needs more than 10 lookups or ends in +all.