A client adds a new marketing platform. Nothing dramatic, just another tool to send newsletters. A few weeks later, invoices that used to land in the inbox start landing in spam, or bouncing outright. Nobody touched the website. Nobody changed a password. The only thing that happened is someone pasted a new line into a DNS record they didn't know they had.
That line is the SPF record, and it has a hard limit built into it. Exceed it, and the record stops working for every message the domain sends, not just the new tool's messages.
What SPF is doing in the first place
SPF, Sender Policy Framework, is a DNS record that lists which mail servers are allowed to send email as your domain. When someone emails you claiming to be billing@yourcompany.com, the receiving mail server checks your domain's SPF record to see if the server that sent the message is on the approved list. If it isn't, that's a signal the message might be forged.
The record itself is just a line of text, something like:
v=spf1 include:_spf.google.com include:mailchimp.com include:salesforce.com ~allEach include points to another organisation's own list of approved servers, because you're vouching for their infrastructure, not listing raw IP addresses yourself.
The limit nobody tells you about
RFC 7208, the technical specification that defines SPF, caps the number of DNS lookups a single SPF check is allowed to perform at ten. That includes your own include statements, and it also includes every lookup buried inside them. If you include Google Workspace, and Google's own SPF record includes three more domains, those three count against your total too, even though you never typed them.
Go over ten, and the check doesn't just ignore the extra entries. It returns what the spec calls a permanent error, a PermError. Most mailbox providers treat a PermError exactly the same as an outright SPF failure. Your legitimate mail server, the one that's been sending your invoices for years, gets treated as unauthorised, because the record meant to vouch for it broke before it got that far.
The limit exists on purpose. Without it, a single SPF record could force every mail server that checks it into an unbounded chain of DNS lookups, which is exactly the kind of thing attackers use to overload systems. RFC 7208 also caps something called void lookups, DNS queries that return nothing, at two. So there are two separate ways to trip this, not one.
Source: RFC 7208, section 4.6.4, IETF and Valimail's breakdown of the limit.
How a small business gets there without noticing
Ten sounds like a lot until you count what a normal company actually uses. A typical setup might look like this:
- Google Workspace or Microsoft 365 for staff email: 1 include, often pulling in more underneath it
- Mailchimp or another newsletter tool: 1 include
- A CRM like Salesforce or HubSpot: 1 include
- A helpdesk or support tool: 1 include
- An invoicing or accounting platform that emails on your behalf: 1 include
- A booking or scheduling tool: 1 include
- A transactional email service for password resets and receipts: 1 include
That's seven includes before you count what each of those services pulls in behind the scenes. Big providers frequently nest three or four lookups inside a single include. It's easy to be at nine or ten without anyone treating DNS as something that needed watching, because nobody was assigned to watch it. The record was set up once, years ago, by whoever built the original website, and every tool added since then just got pasted onto the end.
What this actually costs you
The failure mode is what makes this dangerous. It doesn't announce itself. There's no error message on your website, no warning in your inbox. Mail simply starts landing in spam, or gets silently dropped by some receiving servers and bounced by others, and the pattern looks inconsistent because different mail providers respond to a PermError slightly differently. An invoice that doesn't arrive looks like a client oversight. A proposal that lands in spam looks like bad luck. By the time anyone traces it back to DNS, real revenue has already been delayed or lost.
How to check where you stand
You don't need special software to see your own SPF record. Run this from a terminal or any online DNS lookup tool:
dig TXT yourdomain.com +shortLook for the line starting with v=spf1. Count the include: statements. If you're already at six or seven of your own, and any of those point to large providers, you're closer to the ceiling than you think, because you can't see what's nested inside someone else's include without looking it up separately.
The fix isn't to keep adding entries and hope. It's to flatten what you can, drop services you no longer use, and use a single provider's SPF record instead of stacking several where possible. That's a DNS change, and DNS changes on a live domain are worth getting checked before they go live, because a mistake here has the same silent failure mode as the problem you're trying to fix.
If you want to see where your own domain actually stands, run it through the checker on this site. It reads your SPF, DKIM and DMARC records the same way a receiving mail server does, and tells you in plain terms what's passing and what isn't.