What Is SPF (Sender Policy Framework)?

SPF (Sender Policy Framework) is an email authentication standard in which a domain publishes a DNS TXT record listing the servers authorized to send mail on its behalf. The record starts with v=spf1 and combines mechanisms — ip4 and ip6 for addresses, include to reference another domain's list, a and mx — ending with an all qualifier that tells receivers how to treat everything else: -all (fail) or ~all (softfail). When a message arrives, the receiving server checks the sending IP against the SPF record of the domain in the envelope sender (Return-Path). SPF has known limits: evaluation allows at most 10 DNS lookups, forwarding breaks it because the forwarder's IP is not in the record, and it validates the envelope sender rather than the From address users see — which is why DKIM and DMARC complete the authentication picture. Google and Yahoo require SPF (with DKIM and DMARC for bulk senders) as a baseline for inbox delivery.

SPF (Sender Policy Framework) in Practice

A Google Workspace sender's record looks like: v=spf1 include:_spf.google.com ~all. That single include authorizes Google's sending infrastructure; additional services (a CRM, a support tool) each add their own include. The operational rules are strict. A domain must have exactly one SPF record — publishing two produces a permanent error that fails authentication outright. The 10-lookup limit is easy to breach as includes nest inside includes; when a record exceeds it, receivers return permerror and the record may as well not exist, so audit lookups and flatten or remove unused services. For cold email, every sending domain needs correct SPF from day one, before warmup begins. The common mistakes: multiple SPF records created by different tools' setup wizards, dead includes left behind from abandoned services eating the lookup budget, and assuming SPF alone means authenticated — without DKIM alignment and a DMARC policy, the From address a recipient actually reads is still unverified.