SPF Records Explained: What They Are and How to Set One Up
An SPF (Sender Policy Framework) record is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. When a receiving server gets a message claiming to be from you, it checks this list. If the sending server isn't on it, that's a signal the message may be spoofed.
Last updated: August 29, 2026
How SPF actually works
SPF lives in a single TXT record at your domain's root, starting with v=spf1. After that comes a list of mechanisms: ip4/ip6 for specific IP ranges, a and mx to trust whatever your domain's own A/MX records point to, and include to pull in another domain's SPF record (this is how you authorize a third-party sender like a marketing platform or helpdesk tool). The record ends with a catch-all, usually ~all or -all, which tells the receiver what to do with anything not matched above.
The 10-lookup limit
RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include, a, mx, ptr, and exists mechanism counts, and an include can itself trigger more lookups inside the domain it points to, so a handful of third-party services (email marketing, a helpdesk, a CRM, an SMTP relay) can quietly stack past the limit. Go over it and the record evaluates to permerror, which many receivers treat as a fail. This is the single most common way a technically 'correct' SPF record ends up not working.
How to set one up
- List every service that sends mail as your domain. Your own mail server, plus anything third-party (marketing, transactional, helpdesk, CRM).
- Find each service's SPF include or IP range from their documentation.
- Combine them into one record. A domain can only have one SPF-type TXT record. Two separate
v=spf1records is invalid, not additive. - Pick a catch-all qualifier.
~all(soft fail) is the safer starting point; move to-all(hard fail) once you're confident the list is complete. - Publish the TXT record at your domain's apex (not a subdomain, unless that subdomain sends mail independently).
- Validate it. Confirm the syntax parses and the lookup count is under 10.
Common mistakes
- Publishing more than one SPF TXT record instead of merging them into one.
- Forgetting that a sending subdomain needs its own SPF record. It doesn't inherit the parent domain's.
- Using
+all(allow anyone) by mistake, which makes SPF meaningless. - Adding a new bulk-mail vendor's
includewithout checking whether it pushes the lookup count over 10.
Add mechanisms one at a time with a live 10-lookup meter, and run a real recursive DNS validation pass that follows every include chain.
Frequently asked questions
What's the difference between ~all and -all?
Both are catch-alls for anything not explicitly matched. ~all (soft fail) tells receivers to accept the message but flag it as suspicious; -all (hard fail) tells them to reject it outright. Most domains start with ~all while confirming their SPF record is complete, then move to -all.
Can I have two SPF records?
No. Only one v=spf1 TXT record is valid per domain, having two is a spec violation and typically evaluates as a permanent error, not as "check both." If you need to authorize multiple senders, merge them into a single record.
Does SPF alone stop someone from spoofing my domain?
Not by itself. SPF checks the technical envelope sender, which most email clients never show the recipient. The visible "From" address is what DMARC checks, in alignment with SPF and/or DKIM. SPF is a necessary building block, but DMARC is what actually tells receivers what to do about a message that fails.
Why does my domain still get spoofed even though SPF is set up?
Usually because there's no DMARC policy telling receivers to act on an SPF failure, or the visible "From" domain doesn't align with the domain SPF actually checked. SPF, DKIM, and DMARC are meant to work together, not individually.