SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. It's one of the three pillars of email authentication — alongside DKIM and DMARC — and is one of the first things receiving mail servers check when deciding whether to trust an incoming message.
When a mail server receives an email claiming to be from yourdomain.com, it looks up the SPF TXT record for that domain and checks whether the sending server's IP address is in the approved list. If the IP isn't listed, the message can fail SPF — which may cause it to be marked as spam, quarantined, or rejected outright, depending on the receiving server's policy and your DMARC settings.
A typical SPF record looks like this: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all. Breaking it down: v=spf1 declares the SPF version, include: authorizes a third-party sender (like Google Workspace or an email marketing platform), ip4:/ip6: authorize specific IP addresses directly, and the qualifier at the end (~all, -all, or ?all) tells receivers what to do with anything not explicitly listed — -all (hard fail) is the strictest and most secure.
SPF has a hard limit of 10 DNS lookups per check (RFC 7208). Every include:, a, mx, ptr, and exists mechanism counts toward that limit — and nested includes (an include that itself includes another domain) add up fast if you use several email tools (e.g. Google Workspace + a CRM + a marketing platform + a support helpdesk). Exceeding 10 lookups causes a permerror, which most receivers treat as an SPF failure. Flattening your SPF record (replacing includes with their resolved IP ranges) is the usual fix.
You can check your SPF record with any DNS lookup tool that queries TXT records, or use our Bulk SPF Record Checker to verify SPF across many domains at once — useful if you manage email for multiple clients or brands and want to catch missing or misconfigured records before they cause deliverability problems.