Your SPF record is silently failing

Your email works. Mail goes out, replies come back, nobody complains. So the last thing on your mind is the line of DNS that no one has looked at since you set up Google Workspace three years ago.

But SPF — the record that tells the world which servers are allowed to send mail as your domain — has a hard limit built into it, and a growing company trips over that limit without ever seeing an error. The mail keeps flowing right up until the day a large provider quietly decides it no longer trusts you.

That’s the quiet failure: not a bounce, not an outage, just a slow erosion of whether your mail reaches the inbox at all.

Why it stays invisible

A receiving server is allowed to make only ten DNS lookups when it checks your SPF record. That sounds generous until you count what spends them. Every include: in your record — your mail provider, your CRM, your invoicing tool, your e-signature service, your help desk — pulls in another record, and each of those can pull in more. Add a few services over a couple of years and you sail past ten without ever touching the record yourself.

When you go over, SPF doesn’t bounce your mail or raise a warning. It returns a result called permerror, and what each receiver does with that is up to them. Some ignore it. Some quietly lower your reputation. Some send you to spam. Because the behaviour depends on the receiver, there’s no clear pattern to point at — just a vague sense, months later, that your open rates have slipped, or that one important client “never seems to get” your emails.

There’s a second, quieter trap: the last word of the record. Most records end in ~all, a “softfail” that says if it wasn’t one of the servers I listed, treat it with suspicion, but deliver it anyway. That’s sensible while you’re setting things up. The trouble is that many records never move past it — so someone spoofing your domain gets a shrug rather than a closed door.

Find it yourself

You can see exactly where you stand in about ten minutes. Nothing to install.

1. Find your record. On a Mac or Linux machine, open Terminal and run dig +short txt yourdomain.com; on Windows, run nslookup -type=txt yourdomain.com. Look for the line beginning v=spf1. (If you’d rather not touch a command line, an online checker such as MxToolbox does the same job — search “SPF record lookup”.)
2. Count the lookups. Count every include:, a, mx, ptr and exists in the record — each is a DNS lookup, and the includes count everything they pull in, too. ip4:, ip6: and all don’t count. If the total is anywhere near ten you’re in danger; over ten and you’re already failing. The online checkers total this up for you and flag a permerror outright.
3. Check the last word. Note whether your record ends in ~all (softfail), -all (reject — the stricter, safer setting) or, worst of all, +all, which tells the world that anyone may send as you. If you find +all, remove it today.
4. See whether anyone’s acting on it. While you’re there, check for a DMARC record: dig +short txt _dmarc.yourdomain.com. If it says p=none, you’re only watching, not enforcing — which means you’ve no idea how much of your mail is already being treated as suspect.

The usual reaction to step 2 is mild surprise at how many includes have quietly accumulated.

The fix

Getting back inside the limit, and staying there, is straightforward once you decide it’s worth ten minutes a quarter.

Cut what you no longer send through. Go through the includes and remove any service you’ve stopped using. Old CRMs and abandoned trials are the usual culprits, and each one you remove buys back a lookup.

Consolidate — don’t “flatten” blindly. You’ll find tools that offer to “flatten” your record by swapping includes for raw IP addresses. It works, but those addresses belong to your providers and change without telling you, so a flattened record can break the moment a provider renumbers. If you flatten, use a service that keeps it updated for you; otherwise, prefer simply removing what you don’t need.

Keep it to a single record. A domain may have only one SPF record. If a setup guide ever had you add a second, merge them — two records is itself a failure.

Tighten the ending, carefully. Once you’re confident the record lists everything that legitimately sends for you, move from ~all to -all, so a spoofer meets a closed door rather than a shrug. Do this after you’ve read your DMARC reports, not before.

Look again on a schedule. Every new tool you connect can add a lookup, so a record that’s fine today drifts over time. A quarterly recheck is the difference between mail that lands and a slow, invisible slide into spam.

None of this needs a deliverability consultant. It needs someone to decide, once, that the line of DNS nobody owns is worth owning.

Keeping an eye on a lookup count by hand is exactly the sort of thing that falls off the edge of a busy week. DomainOps watches your SPF lookups, DKIM and DMARC continuously and warns you before you cross the limit — not months afterwards. But the check above costs nothing but ten minutes, so do that first, today, whether or not you ever automate it.