SPF (Sender Policy Framework)

SPF (Sender Policy Framework) is a DNS TXT record that tells receiving mail servers which IP addresses and third-party services are authorized to send email on behalf of your domain. When a cold email hits an inbox provider, that provider checks your SPF record before anything else. If the sending server is not listed, the message is almost always flagged as suspicious and routed to spam — or bounced outright.

A typical SPF record looks like v=spf1 include:_spf.google.com include:sendgrid.net -all. That line says: “Google Workspace and SendGrid are allowed to send mail for this domain; anyone else should be rejected.” The -all at the end (“hard fail”) is the strict version; ~all (“soft fail”) is more forgiving and commonly used when a team is still sorting out its sending infrastructure.

Two things break SPF for cold outbound teams. First, adding a new sending tool — a new cold email platform, a new warmup service, a new CRM — without updating SPF to include it. The tool sends, the SPF check fails, and the campaign lands in spam even though the copy is fine. Second, exceeding the 10-lookup limit: SPF allows only 10 DNS lookups per record, and teams who stack too many include: statements silently break their own setup. Clean SPF records are short, intentional, and reviewed whenever the tool stack changes.

When the term matters

SPF matters any time you change your sending setup: new domain, new mail provider, new third-party tool. It is the first DNS record inbox providers verify, and the easiest one to get wrong. If a cold email campaign is landing in spam and open rates have collapsed, the SPF record is the first thing to check — often the fix is a single line of DNS.

Related concepts

SPF works alongside DKIM and DMARC as the three pillars of email authentication. Together they determine whether your domain is trusted enough to land in primary inboxes.