Sender Policy Framework (SPF) tells receiving mail servers which hosts are allowed to send email for your domain. Without it—or with a misconfigured record—your campaigns are more likely to fail authentication and land in spam.
What an SPF record looks like
SPF is published as a TXT record on your root domain:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -allv=spf1— required version taginclude:— delegates to another domain’s SPF (counts as DNS lookups)-all— fail all other senders (recommended for production)
Common mistakes
Too many DNS lookups
SPF allows a maximum of 10 DNS lookups (include, a, mx, redirect, etc.). Exceeding this causes a PermError and SPF fails.
Using +all
+all means “any server on the internet may send as you.” It effectively disables SPF protection.
Forgetting new sending tools
Every ESP, warm-up tool, or CRM that sends on your behalf needs to be in SPF—usually via an include: mechanism.
How to verify SPF
Use FeedPipeline’s free checker to pull live TXT records via public DNS and flag weak policies or lookup issues before you scale sending.
Quick checklist
- One SPF TXT record on the apex domain (not multiple conflicting records)
- All sending providers included
- End with
-allor~all(softfail) during testing only - Stay under 10 DNS lookups
SPF is only one piece of authentication—pair it with DKIM and DMARC for a complete setup.