SPF (Sender Policy Framework) is a DNS TXT record that declares which servers are allowed to send email for your domain. When a mailbox provider receives your message, it looks at the Return-Path domain and checks that the sending server is on your list. Not on the list? Your email starts the conversation as a suspect.
Why this one isn’t a debate
- It’s the first triage. SPF is among the earliest checks an inbox runs—failing it means fighting uphill before anyone even looks at your content.
- The big providers require it. Google, Yahoo, and Microsoft’s bulk sender requirements demand SPF and DKIM authentication outright. Even for low-volume senders, missing SPF is a red flag.
- DMARC depends on it. DMARC passes when SPF or DKIM passes and aligns. You want both in place so a single failure—like a forwarder breaking SPF—doesn’t sink the message.
- It costs one TXT record. There is no cheaper deliverability win.
What it looks like
v=spf1 include:_spf.google.com include:amazonses.com ~allv=spf1—the SPF versioninclude:…—origins allowed to send for your domain (your ESP, your workspace provider)~all—what receivers should do with everything else (softfail)
The gotchas
- One record per domain. Two SPF records is a permanent error, not “double coverage”. Merge the
include:entries into one record. - Ten DNS lookups, max. Every
include:costs lookups; blow past ten and SPF fails. Audit before adding another tool to the record. - Subdomains aren’t covered. A policy on
domain.comdoes not apply tomail.domain.com. Each sending subdomain needs its own record. - SPF alone isn’t authentication. It checks the Return-Path, not the From address the human sees, and it breaks on forwarding. Pair it with DKIM and DMARC.
If you send through an ESP like Resend, SPF for your sending domain is usually configured as part of domain setup—verify it’s in place rather than assuming.